36

With ASP.NET Core 1.0 release one can run on either .NET Core or the full .NET Framework per the documentation here. I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?

I understand the difference between the full .NET Framework and .NET Core. However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6? I thought the idea was a 1-2 punch with ASP.NET Core atop of .NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc. Without .NET Core I don't believe anything on that list is still valid, so what is the use case for the full .NET framework + ASP.NET Core? What does ASP.NET Core on it's own still provide to me without .NET Core?

saluce
  • 13,035
  • 3
  • 50
  • 67
atconway
  • 20,624
  • 30
  • 159
  • 229
  • Refer this - http://stackoverflow.com/questions/37684508/difference-between-asp-net-core-net-core-and-asp-net-core-net-framework – Sanket Oct 05 '16 at 06:16
  • This post speaks almost **exactly** to this question: http://odetocode.com/blogs/scott/archive/2016/10/11/asp-net-core-and-the-enterprise-part-1ndashframeworks.aspx – atconway Oct 14 '16 at 02:13
  • Explanation on Microsoft site: https://learn.microsoft.com/en-us/dotnet/articles/standard/choosing-core-framework-server – Der_Meister May 23 '17 at 10:13

5 Answers5

34

.NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc.. Without .NET Core I don't believe anything on that list is still valid

The only benefit you don't have if you choose the full .NET framework over .NET Core is being cross platform. All the other benefits of deployment, modularization, docker, performance, etc... are still valid.

We actually run our ASP.NET Core web app on the full framework and now we enjoy the benefits of having Dependency Injection as a 1st class citizen, having NuGet built in, having an lean HTTP request pipeline which makes our performance better, open sourced (so all the issues can be solved by a short visit to GitHub), modularity (still have to come across something we couldn't customize to our own needs after almost a year now), and so on. And we know we don't need to deploy on any other OS than Windows, so we can still have all the benefits of the full framework.

Update from Tseng

Well, you can still target full .NET Framework under Linux for example. There you need mono 4.6 installed there. There are some limitations as not all classes are implemented in mono, but a majority is and around the corner case (i.e. encryption) you have to work around

Update from atconway

It's also worth noting at the time VB.NET is not supported by .NET Core if that's a requirement.

Danny van der Kraan
  • 5,344
  • 6
  • 31
  • 41
  • Well, you can still target full .NET Framework under Linux for example. There you need mono 4.6 installed there. There are some limitations as not all classes are implemented in mono, but a majority is and around the corner case (i.e. encryption) you have to work around – Tseng Oct 06 '16 at 18:03
  • It's also worth noting at the time `VB.NET` is not supported by `.NET Core` if that's a requirement. – atconway Oct 12 '16 at 04:18
  • 1
    Updated with both your comments – Danny van der Kraan Oct 12 '16 at 06:07
  • Choice of an underlying framework also depends on what you are making. The assumption in the answer as I understand is, you are making an application and not a library. If you are developing a library then the answer changes a bit as that point you need to decide first hand what TFM's you need to target aka the .NET standard. At that point your library can then target .Net Core or the full .Net framework alike depending on what api's your library need. – Muqeet Khan Feb 06 '17 at 17:35
  • @Danny van der Kraan: I couldn't get a multi target project to compile. After creating a new ASP.NET Core 2.0 Aurelia SPA project and changing to net461;netcoreapp2.0, nothing works anymore. I am getting errors like "The type or namespace name 'AspNetCore' does not exist in the namespace 'Microsoft' ..." ... !??! – IngoB Nov 01 '17 at 18:56
  • @IngoB With what TargetFrameworks is the new project created? – Danny van der Kraan Nov 06 '17 at 10:26
  • @DannyvanderKraan: I don't understand your question. I created an ASP.NET Core 2.0 project and then changed the csproj to target both .NET 4.6.1 and .NET Core 2.0. After saving the csproj, both frameworks got referenced. From my understanding the project should compile as .NET Core 2.0 is still one of the targets. – IngoB Nov 06 '17 at 21:40
  • Some support for VB.NET is there in 2.0 https://learn.microsoft.com/en-us/dotnet/core/tutorials/vb-with-visual-studio – pulsejet Feb 04 '18 at 14:41
  • Side-by-side versions of .NET Core, so that ASP.NET Core apps can target different versions on same system globally or even local to app are also a benefit lost targeting full framework. – Ben Hall May 09 '18 at 11:47
  • Something to note, going forward, [it appears](https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-3.0?view=aspnetcore-3.0#aspnet-core-30-only-runs-on-net-core-30) that future versions of ASP.NET Core will _not_ support running on .Net Framework. – bdw Sep 30 '19 at 15:51
7

However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6?

If I use ASP.NET 4.6 instead of ASP.NET Core 1, then I won't be able to use ASP.NET Core MVC. None of the features on that documentation page would be made available to me! I would have to build an MVC5 application. Boooo!

I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?

I'm assuming that another way to ask this would be: "why would you take the red path when you can take the brown path?"

enter image description here

One argument for doing it this way is deployment. If you've got a bunch of existing Windows servers with IIS on them, you're going to need to install additional software on each of them and set them up to run Core applications. IIS just becomes a reverse proxy for your .NET Core app.

However, if these apps were built on the .Net Framework instead, you wouldn't have to do this. You could still use web deploy (for example) to move them onto the servers. Maybe you've got some other existing IIS configuration settings that you don't want to migrate.

Using ASP.NET Core 1.0 targeting the .Net Framework, you can get the benefit of the new features in ASP.NET Core MVC without having to change your existing infrastructure.

Will Ray
  • 10,621
  • 3
  • 46
  • 61
  • 5
    This is not correct. If you develop ASP.NET Core web application on .NET Framework, you have to update IIS configs. The output assembly is .exe, not .dll. The only need to use the 'red path' is when some required NuGet packages are not ported to .NET Core. – Der_Meister May 23 '17 at 10:10
7

One important benefit of using Full .NET framework with Asp.Net core is availability of mature libraries and frameworks that are developed mainly to target previous version of .NET.

But by passing of time and implementing more and more libraries to target .NET core and developing more features for .NET core itself this benefit may fade out.

farid bekran
  • 2,684
  • 2
  • 16
  • 29
4

Having to leverage legacy technologies like OLE DB that will never be implemented in NET Core System.Data is another reason.

Alan B
  • 4,086
  • 24
  • 33
1

One thing to consider is that it can be a migration path. Say, for example, you have an existing ASP.NET 4.6 application that you intend to migrate to .NET Core. You want to take advantage of ASP.NET Core features like TagHelpers, Dependency Injection, etc., but you aren't ready or able to use .NET Core framework. So, you develop the ASP.NET Core application, targeting just the .NET full framework. Then, you take the next step and multi-target, going for both .NET full framework and .NET Core framework. This gives you the flexibility to easily deploy to IIS with the full framework or cross-platform with the core framework. From there, you can decide if you want to eliminate the full framework or not.

saluce
  • 13,035
  • 3
  • 50
  • 67
  • 1
    Is this really true? I thought that the only difference when targeting the full .NET Framework is that you can reference some .NET Framework assemblies that haven't been ported to .NET Core yet. Regarding the deployment and IIS, it shouldn't make any difference, if you want the new version of ASP.NET, you still need to change basically everything related to how stuff is built, deployed and ran, regardless of what is the target. – Tom Pažourek Oct 11 '17 at 21:00
  • 1
    @TomPažourek The idea here is that you are building a new .NET Core application, but your libraries are not Core-compatible. You can develop the ASP.NET Core application and use the full .NET Framework, but you are still limited to windows because those assemblies will only work on Windows. If .NET Core doesn't have a comparable assembly from the full framework, you either need to find a workaround (using compiler directives and alternate libraries) or disable that feature for the cross-platform deployment. The target still have to be compatible with where the application is being deployed. – saluce Oct 12 '17 at 22:00