I've created a new ASP.NET 5 project and I faced with something that I didn't understand well about how the new ASP.NET works.
In my references there are DNX 4.5.1 and DNX Core 5.0. When I install a new package from Nu-Get, some packages install successfully in both and some tell me they aren't supported by DNX Core 5.0.
Can I use many versions of DNX for supporting my packages or I must bound the things with DNX Core 5.0 to enjoy the advantages of ASP.NET 5, like cross-platform and others?
ASP.NET 5 projects are multi-targeted, which means you can compile for multiple platforms simultaneously. In your case .NET 4.5.1 targets ASP.NET 5 on the full .NET runtime (4.5.1) and .NET Core (5.0). When you compile your project, ASP.NET 5 actually creates output for both of these targets so - assuming you get the code to compile for both platforms - the application can run on either of them. It's possible to run additional targets to your projects.
When you actually run your application though, you have to pick a specific version of the .NET runtime you want to run under. In Visual Studio there's a drop down in the project settings where you can select that runtime that actually executes. When you use command line publish you also specify which platform to publish to with a parameter (if omitted it uses the active DNX runtime I believe).
As to the differences - .NET Core is a trimmed down version of the full .NET runtime, that is cross-platform and can run on Windows and other platforms like Linux and OSX. Because it has to run on other platforms a lot of the platform specific Windows features are not supported in this runtime, and as the platform is still evolving some APIs are simply not implemented yet in .NET Core. This is the reason you are likely to see many compile errors when you target .NET Core with existing code/libraries. In order to run on .NET core existing .NET code typically needs at least some minor adjustments to account for the smaller API footprint and potentially serious redesign to work around missing functionality.
If you need to use existing code and depend on assemblies/NuGet packages that are based on previous versions of .NET you have to stick with the full .NET version. You can still take advantage of the new ASP.NET 5 features and eco-system, as well as getting the benefit of the full .NET runtime and full API surface you are used to from previous .NET versions. The downside is that the runtime is Windows only and has a bigger resource footprint.
.NET Core is a new runtime and you should treat it as such. Migrating to this platform is likely not a trivial task. The benefits of this platform is a much leaner footprint and that it can run across multiple OS platforms.
It's likely that it'll take some time for the full potential of .NET Core to come to fruition as Microsoft expands the feature set and cross-platform compatibility but we won't really know what this will look like since it is still in Beta (well RC but it's really a beta with major changes still coming in RC2).
Related
I am struggling to understand how all these frameworks interact and depend on each other: .NET Core, .NET Framework, ASP.NET Core, MVC, etc.
This discussion leads me to believe that my MVC app uses ASP.NET Core and .NET Framework, but not .NET Core. If that's true, can I run the MVC app without the .NET Core runtime? If not, why is this app still dependent on the .NET Core runtime?
What I tried
I created a new project in Visual Studio 2017 as follows:
ASP.NET Core Web Application
MVC
.NET Framework
ASP.NET Core 2.1
I published the app as follows:
dotnet publish --self-contained false (to prevent the runtime from being included)
Deploy new ec2 instance with windows server 2019
Install minimal set of dependencies (IIS, .NET Framework, Rewrite Module)
Deploy the published app to IIS
The app did not work at this point. I got a 500.19 with error code 0x8007000d. I got it working by installing the Hosting Bundle. I manually removed a few things that were installed with the hosting bundle, and found that "Microsoft .NET Core 2.1.28 - Windows Server Hosting" is required. I don't know exactly what that is, but it smells to me like the .NET Core runtime is somehow involved here.
Update
When I install the Hosting Bundle, I see a few important things get installed:
C:\Program Files\dotnet\dotnet.exe
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All\
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\
When I uninstall the .NET Core Runtime, I am left with just the following:
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All\
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\
The app still works at this point. I assume what remains is the ASP.NET Core Runtime, which is different than the .NET Core Runtime. I am just looking to confirm that this app is only dependent on the ASP.NET Core Runtime and .NET Framework, and not at all dependent on .NET Core.
We have a system that has CPU, memory, disk, network card, IO devices, etc. We need a software to manage these resources for us and let us use this system. That software is the kernel. (say Linux)
Now that we can control the hardware we need abstraction on top of it for daily usage for users. We need shell, windowing system, different kind of services and daemons. We call this whole package the Operating System. (say Ubuntu)
Now that we can happily use our computer, we want to write our own applications for our problems or maybe for other's problems. The OS provides us with a programming language and a library of functions and system calls that we can use to create software, just like the OS itself is using them. (say C and glibc)
Suddenly we realize that our software is not portable to other Operating Systems and it has a lot of complex boilerplate codes. So we create a new programming language and provide a new set of library functions but this time way easier to read and understand. (say C# and .NET 5 SDK)
But we have a problem. Our OS does not understand this new language. So we need a layer between our language and the OS. This piece of software must read our program and somehow translate it for the OS. This program is the Runtime. (say .NET 5 Runtime)
OK, let's review. We create an app with C# and .NET. this results in a program that is in the IL language. OS does not understand IL language, therefore we need the .NET runtime to read our IL app and translate it for the OS. But how do we set this up?
We have two options:
We install the .NET runtime on every system that needs to run our app; this way our app becomes portable but it needs the runtime to work.
We include the runtime code inside our app; this way our app does not need the runtime but it won't be portable anymore and since it carries the runtime it will be larger.
Now to clear a few of your confusions:
What is the difference between .NET Framework and .NET Core?
.NET Framework only runs on Windows and has more libraries to use.
.NET Core is cross-platform and has fewer libraries to use but is very fast. It now goes with the name .NET 5 and those extra Windows-only libraries have been added to it.
What is the difference between .NET SDK and Runtime?
SDK provides you with the tools you need to build an app with (SDK includes the Runtime as well).
Runtime is lighter and just runs your app.
What is the difference between .NET Core Runtime and ASP.NET Core Runtime?
.NET Core runtime (.NET 5 runtime now) can only run your console apps and is lighter.
ASP.NET Core runtime can run your web apps.
There are also runtimes for GUI apps capable of running WinForms and WPF apps (Windows-only).
What is MVC?
Model-View-Controller is a design pattern and it is not related to a specific language or framework.
I'm trying to add a full framework class library as a project reference to asp.net core 2.0 MVC project and getting the below error.
Project XYZ is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0).
Project XYZ supports: net462 (.NETFramework,Version=v4.6.2)
I have updated to the most recent version of Visual studio i.e, 15.3.5.
Is it even possible to reference 4.6.2 libraries in core 2.0 projects?
The first thing that you can try is to compile the library you want to consume as netstandard2.0.
Theoretically (according to the .net standard documentation), this will make it compatible with projects using net461 and later as well as netcoreapp2.0 and later.
In practice, sometimes you will end up with a problem with one of your dependencies that don't provide the same library version across different compilation targets.
In such cases you may simply need to add the .net core 2.0 as a target framework for the XYZ library.
The xml tag listing the targets is <TargetFrameworks> in the XYZ.csproj file and is not handled by the Gui of the project's properties.
So I would give a try at editing the XYZ.csproj by hand and add or replace what's listed as <TargetFrameworks> with netcoreapp2.0.
If you are adding it as additional target you need to separate them with ';' as in
<TargetFrameworks>net462;netstandard2.0;netcoreapp2.0</TargetFrameworks>
More details about this in this Microsoft doc.
Please keep in mind that this will trigger multiple compilations and will slow your build consequently...
It should be. Microsoft announced a ".NET Framework Compatibility Mode" with the release of .NET Standard 2.0. However, they didn't go into great detail about how it works exactly, or what to troubleshoot if it doesn't. Additionally, they only specific talk about it in relationship to Nuget packages, so it's possible there's some role Nuget is playing in the process, as well. Unfortunately, I've been unable to find any additional information about this feature outside of the announcement post.
That said, Microsoft's explicit recommendation is to not rely on the fact that your .NET Framework library may just happen to work in .NET Core; instead, you should be actively porting .NET Framework libraries you control to .NET Standard. I'd say you're likely going to spend more time trying to figure out why it doesn't "just work" than you would porting your code, so that it will definitely work, and be future-proof to boot.
The following solution worked for me.
Deleted bin and obj folders from all the projects in the solution, rebuild and if it still doesn't work try changing browser from debug options. for eg. If you already have chrome as default browser in Visual studio, switch to Edge or Firefox.
I am trying to generate Well formatted Excel files from .Net Core and found ClosedXML library which runs only on .Net 4.61
I already tested the following libraries which work on .Net Core
OpenXML - Too many codes for a simple task and difficult for me to use
SyncFusion - Public / Government Organisation cannot use for free.
I changed the target to Net461, do the dotnet restore and all my codes are still running as usual and I could generate the Excel file with ClosedXML too.
What I would like to know is, is it a good approach? This is not a one-off small project and I am likely to maintain this website for another 3-4 years at least.
Is there any potential to lose the new functionalities and not able to use new Libraries from .Net Core in the future?
Or should I create another separate website running on Net461 and call that URL from my .Net Core app? So, I don't need to worry about losing new .Net Core functionalities in the future.
There is obviously no way to know the future, but the biggest thing you get with .Net Core over the full framework is the ability to run the app cross platform. So if cross platform isn't a concern, then going with the full framwork shouldn't be an issue. There is no question that the full framework will be fully supported for the 3-4 year time horizon you mentioned, in fact I think most developers would feel comfortable using the full framework even for a project with a much longer time horizon.
With regard to missing out on new .Net Core features, many of the features can be accessed even from libraries compiled for the full framework. For example I use the new encryption libraries found in Microsoft.AspNetCore.Cryptography (that are part of .Net Core) from my full framework class library. The net .Net Core libraries are just Nuget packages and as such can be referenced from non .Net Core projects.
I Was just reading this post: http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
It left me a bit confused since the first picture in the article seems to imply that .NET desktop apps and ASP.NET don't share the same framework implementation. I was always under the impression that it was. Any ideas?
They use the same .NET framework.
But they don't have to. And this is the way the .NET ecosystem is evolving right now - ways to avoid using the full (ever growing) .NET framework for everything.
As a bonus, the new .NET Framework Core is open-sourced. This is not entirely posssible with the whole .NET framework, since it includes a whole lot of licenses and proprietary technologies.
Given all that, it's now possible to deploy very light-weight web applications using ASP.NET, not even having to use IIS (thanks to OWIN). You only have to include the packages you need - instead of having a single monolithic runtime and BCL, there's hundreds of NuGet packages you choose to use (or not).
You will have to better define "the same framework implementation", as they (full .NET Framework and .NET Core) are built from the same code base with different configuration, and also host your web applications in a slightly different way.
The most important getaway of that article should be "ASP.NET 5 can run on both .NET Framework 4.6 and .NET Core 5". You get different benefits from each runtimes,
.NET 4.6 gives you best compatibility against previous .NET runtimes.
.NET Core 5 gives you flexibility on running multiple customized DNX side by side, and portability to Linux and OS X.
Unfortunately Microsoft decides to limit desktop apps to .NET 4.6, but Mono guys have demonstrated possibility to run some (such as WinForms apps) on .NET Core,
https://github.com/akoeplinger/mono-winforms-netcore
I've seen videos introducing ASP.NET vNext and been keeping up with the recent announcement blog posts, but detailed information on what's been stripped from the full framework appears slim. Here's what I think I know so far:
It's much smaller (11MB vs >200MB): http://davidzych.com/2014/05/24/getting-started-with-asp-net-vnext/
Strong naming is gone: http://jeremydmiller.com/2014/06/09/final-thoughts-on-nuget/
It's dumped System.Web
It includes a merged MVC and WebAPI (however I don't believe this is part of the framework itself but rather dependencies that can be specified)
Dependencies are completely managed through project.json, to the extent that the base
Are we basically looking at a framework that basically includes nothing more than what's in mscorlib in the full framework, with all else delivered via package management? And if this is the case, why would one need to target the framework specifically, as described here? http://blogs.msdn.com/b/webdev/archive/2014/06/17/dependency-injection-in-asp-net-vnext.aspx
The reason they specifically target NET45 in the link you supplied is because AutoFac is built for and has a dependency on .NET 4.5. Without NET45 the code wouldn't compile.
My assumption is that once vNext gets closer and closer to release the Autofac (and StructureMap, and Castle Windsor, and ...) will release a version that targets the cloud optimized framework to remove the dependency.
As far as I understand, .Net Framework is the fully framework we know and love with all the Windows implementations and lots of code we don't normally use, like they explain in some videos an XML parser.
In .NET Core they removed all the unneeded implementations/dependecies and only left the basic ones. which also enables cross platform (not yet), so in the future one could think as the only framework : CORE Framework, and run on any device. Their february community standup give a lots of information and insight on their objectives and goals.
I see this as a transition, when some features are available only on the full Framework while in the futures one might expect to see all features available for .NET Core.
From a Microsoft perspective, if they want to release lets say Entity Framework for mobile (EF7 is aiming at that) they must get rid of all the windows implementations, on EF and it's dependencies (Framework). So they created a non-windows dependency on the framework, which also helps the multiple framework install and remove some problems with updating the framework by having them mostly isolated from the system, lying in the application. New problems will come like multiple copies of the same framework on one machine per application, that's why they are working on something called Smart Sharing.
This post may help you and give you some insight specially this part :
The structure of .NET Core is comprised of two major components which
add to and extend the capabilities of the .NET Framework as follows:
Runtime:
Built on the same codebase as the .Net Framework CLR. Includes the
same GC and JIT (RyuJIT) Does not include features like Application
Domains or Code Access Security. The runtime is delivered on NuGet
(Microsoft.CoreCLR package)
Base class libraries:
Are the same code as the .Net Framework class libraries but do not
contain dependencies so have a smaller footprint. Available on NuGet
(System.* package)
and I guess you already read Introducing .NET Core from Microsoft.
Regarding your concern about specifying a specific framework is because right now, not everything works on Core CLR so you must choose which one to use, or you can target both and use different implementations.
As of right now, CORE only runs on Windows; the mono framework doesn't have a SQLLite provider for entity framework but it does on Core, so you can use an InMemory or Azure EF provider for example, and choose depending on the enviroment your application is running.
As Scott Gu says on the community standup, they envision a future where there's no mono framework or full framework, there's just Core, but that will take time if it ever happens.
I can't find an original source other than a comment by David Fowler (I believe) on a presentation from NDC, but CoreCLR used by the K Runtime is actually a reincarnation of the CLR used by Silverlight 2. It was used because it's small and designed to be cross platform. There is some additional information here: https://stackoverflow.com/a/25720160/113225