I have a .net Core 2.2 project. This is created using a Webapplication (Model View Controller) template. I can add my .Net Framework 4.7.1 projects into this core project, it compiles, run - and is deployed on my test servers.
1) Then I read about 2.2 End of Life, and I tried to migrate this to 3.1, and I cannot reference .Net Framework 4.7.1 in 3.1 framework. I don't know what is my next step here.
2)I read that I can convert my dll's to .Net Standard and reference - but, how can I do this?
3)These 4.7.1 dll's are shared by .Net Framework projects and core projects, so if I change this to .Net Standard - will my .Net Framework applications work?
4) Also - should I migrate my 2.2 Core projects to 3.0 because of the EOL? Is that mandatory? How will EOL affect audits if I don't migrate?
First, 2.2 is EOL, because 2.1 is the LTS release. You can downgrade to 2.1 if you don't want to jump to 3.x yet, and you'll still have a year or two of support there, I think.
However, 3.x takes the first step towards the new vision of one .NET (.NET 5 for all workflows), so the sooner you can get there, the better. 3.1, specifically, is the LTS release for 3.x, so stick there if you don't want to be forced to upgrade again for a while.
.NET Core 3.x implements .NET Standard 2.1, which is why you can no longer target .NET Framework with that (no version of .NET Framework implements .NET Standard 2.1 and never will). However, .NET Standard 2.0 is supported by both .NET Core (2.x and 3.x) and .NET Framework 4.6.1+. As a result, if you need to share a library between all these targets, you should target .NET Standard 2.0.
As far as converting your existing libraries go, you simply change the target framework to .NET Standard 2.0. That's literally it. Once you do that, some functionality in the library may fail (anything that requires .NET Framework, i.e. Windows-specific APIs). At that point, you either need to rewrite those parts of the library to use .NET Standard-compatible APIs, or use compiler directives to sub-in alternate implementations for .NET Standard 2.0/.NET Core, at which point, you'd have to multi-target the library (i.e. .NET Framework and .NET Standard 2.0 or even specifically .NET Core). When compiling, DLLs will be generated for each specific target, allowing you to seamless reference the same library from projects targeting any of the library targets.
If you're doing anything with ASP.NET Core components in your libraries, you should factor that code out into separate libraries and target .NET Core 3.1 directly there. There's no point in targeting .NET Standard 2.1, as that code will only ever be applicable to .NET Core, anyways. You should also work in the opposite direction. In other words, if there's anything that's only applicable to .NET Framework projects (Web Forms, etc.), then factor that out into separate libraries that will only target .NET Framework. That will allow you to migrate the remaining parts of the library more easily to .NET Standard 2.0.
Related
I done created an application in .net framework 4.6.1 which works perfectly in localhost. But in the server(Windows server 2012), we have .net framework 4.5.
Should we upgrade it to framework 4.7 or will it work in the current framework?
It depends on whether you use any new features introduced in .NET 4.5.1 or later or not.
To ensure compatibility, you should either
upgrade your target system to (at least) 4.6.1 or
reduce the "Target Framework" setting of your project to (at most) 4.5:
Option 1 would ensure that all features that you use in development are available on the target system.
Option 2 would ensure that you get a compile-time error if you use features which are unavailable in .NET 4.5.
The .NET Framework 4.5 and later versions are backward-compatible with apps that were built with earlier versions of the .NET Framework. In other words, apps and components built with previous versions will work without modification on the .NET Framework 4.5 and later versions. However, by default, apps run on the version of the common language runtime for which they were developed, so you may have to provide a configuration file to enable your app to run on the .NET Framework 4.5 or later versions.
In practice, this compatibility can be broken by seemingly inconsequential changes in the .NET Framework and changes in programming techniques. For example, performance improvements in the .NET Framework 4.5 can expose a race condition that did not occur on earlier versions. Similarly, using a hard-coded path to .NET Framework assemblies, performing an equality comparison with a particular version of the .NET Framework, and getting the value of a private field by using reflection are not backward-compatible practices.
In addition, each version of the .NET Framework includes bug fixes and security-related changes that can affect the compatibility of some apps and components.
So i would suggest you to upgrade it to framework 4.7.
For more details please check:
https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility
I have followings projects:
.NET Core 2.0 Web Application
.NET Standard 2.0 Class library &
.NET Framework 4.5 Class Library.
I add reference of .net framework class library to asp.net core web api project. and it seems it works very well.
I am wondering why it's possible to add reference of .NET Framework class library project to ASP.NET Core Web API or MVC?
It's not supposed to allow adding only Standard or Core libraries references to Core projects?
Is this core Web project with .NET Framework class libraries references still cross platform?
UPDATE
According to Phiter comment:
"If you import a .net framework library to your project it'll no longer be cross platform, but you can do it freely if you want to. They allow it because you might want to use .net core and still be on windows."
So if this is a reason, if I want to bind my project to .NET Framework and remain on windows why I use Core Web Project from the first place?
I thought we use core projects for cross platform ability and if not, the .Net framework is not a better option?
UPDATE
mason comment:
"Nothing funny: ASP.NET Core project doesn't have to run on .NET Core. It can also be run on .NET Framework.
Just because it's called 'Core' doesn't mean they're related. They could have called it ASP.NET FancyPants and had it run on .NET Core and .NET Framework and you wouldn't be as confused. Microsoft just sucks at naming things."
UPDATE (November 12, 2018)
A first look at changes coming in ASP.NET Core 3.0 - Fully leveraging .NET Core
As announced on the .NET Blog earlier this month, .NET Framework will get fewer of the newer platform and language features that come to .NET Core moving forward, due to the in-place update nature of .NET Framework and the desire to limit changes there that might break existing applications. To ensure ASP.NET Core can fully leverage the improvements coming to .NET Core moving forward, ASP.NET Core will only run on .NET Core starting from 3.0. Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.
Customers utilizing ASP.NET Core on .NET Framework today can continue to do so in a fully supported fashion using the 2.1 LTS release. Support and servicing for 2.1 will continue until at least August 21, 2021 (3 years after its declaration as an LTS release) in accordance with the .NET Core support policy.
This was just added as part of .NET Standard/Core 2.0. As long as the .NET Framework dll only references things in the .NET Standard, it will use type forwarding to the .NET Core implementations.
I do not know what made Microsoft allow referencing .net framework class library into .net core project but as a programmer, I am happy with this allowance.
You see allowing .net core application to reference .net framework libraries is useful in case you want to start with windows and are planning to go cross platform in the future.
We are in a stage where many useful open source libraries do not fully support .net core till the date of this post, masstransit is an example, so when I am developing a new software I will be using .net core project that depends on such libraries and I will update them later when they support .net core.
I am new to ASP.NET MVC applications and I'm building a web project in Visual Studio 2015. My project targets .Net framework 4.6. I want to know which version of ASP.NET MVC is installed with this version of the framework. I have browsed a lot and also looked for answers at the ASP.NET official website, but could not find the answer.
A relevant, but not specific, answer was found at:
https://softwareengineering.stackexchange.com/questions/157717/what-is-dependency-of-asp-net-mvc-on-net-framework-and-how-to-use-it-with-net
It would be great if someone could list the versions of ASP.NET MVC alongside the versions of the .Net framework they depend upon.
Try using Visual Studio 2017, because it is not dependent on the OS you are using or targeting.
As for your question, which version of MVC are you currently using, and what are the requirements for the project?
If you're building a website that uses Entity Framework or APIs, then I recommend using framework 4.6 and MVC 5 or Core.
According to MSDN:
Runtime Changes Runtime changes affect all apps that are running under
the .NET Framework 4.6 and that use a particular feature. Retargeting
Changes Retargeting changes affect apps that are recompiled to target
the .NET Framework 4.5, 4.5.1, or 4.5.2, or 4.6. They include: Changes
in the design-time environment. For example, build tools may emit
warnings when previously they did not. Changes in the runtime
environment. These affect only apps that specifically target the .NET
Framework 4.6. Apps that target previous versions of the .NET
Framework behave as they did when running under those versions.
I hope this helps you.
In a portable class library, you can select multiple platforms to target. I don't understand why ASP.NET Core 5.0 doesn't seem to share any API surface with Silverlight 5, yet it does with Windows 10, .NET Framework 4.6, Xamarin, etc.
Is this just a situation where the profile was not created? Or, is it just that the shared surface API hasn't been made portable? Or, do the two platforms really not share any APIs?
I don't understand why ASP.NET Core 5.0 doesn't seem to share any API surface with Silverlight 5
It boils down to the target CLR/.Net version which you want Asp.Net to sit upon, and whether specific portable libraries were made to target Silverlight's CLR. The choice for Asp.net is to target either Core 5 or .Net 4.6 and only one has portable libraries to Silverlight; not both can be targetted.
From top to bottom, Core 5, uses specific .Net Core libraries which sit upon the Core CLR and those libraries are not the same as the .Net 4.6 libraries which utilize the standard CLR. Specific portable libraries have to be made for each target implementation. (Remember also that Silverlight has its own CLR...its getting complicated right?)
Long story short, most likely there will not (and more important has not) be a bridge built to the Silverlight CLR to share portable libraries of the .Net 5 core libraries like the .Net 4.X libraries; hence one doesn't have that option.
References
Cross-Platform Development with the Portable Class Library .Net 4.6
What is .NET Core 5 and ASP.NET 5 within .NET 2015 Preview
Targeting Multiple Platforms with Portable Code: Overview
Sharing Silverlight Assemblies with .NET Apps
I have a big class library written in .NET 4.0 but when I reference it in a Store App that uses .NET Core, it shows an error. And further, Microsoft just released .NET Core for the next version of .NET.
I want to know what type of project will be able to be shared by both .NET 4.6 and .NET Core? Is a class library able to do that?
It seems that the release of .NET Core specialized for Store Apps causes confusion for me.
If you have a PCL (Portable Class Library) that works for Metro apps, it will definitely run on the fully fledged .NET (aka, your normal ASP.NET, WF, WPF applications).
That means that you don't have to do anything, besides porting your existing library to be compatible with the PCL you choose.
There is a new target called dotnet which you can use to target the platforms DNX, UWP and .Net 4.6. Effectively, this libraries are build against .Net Core packaged libraries instead of the libraries of the full .Net Framework.
Read more here: https://oren.codes/2015/07/29/targeting-net-core/ and related posts.