I'm working on migrating a large code base of libraries in a direction to eventually support .NET Core. Currently, everything is based on .NET Framework. I have a set of library projects which are consumed by several web applications.
The plan is to convert the library projects over to .NET Standard 2.0 so that they can be consumed by both .NET Framework (version 4.7.1) based websites and by new .NET Core (version 2.0) websites. I've done some test solutions which proved that this can be done.
To convert the first library over to .NET Standard I had to leverage the Windows Compatibility Pack for some of the features that are not part of .NET Standard. Some features such as SqlClient and some System.Drawing tools had to be imported into the library. All of this worked but an issue turned up when trying to bring my library into code which was still targeting .NET Framework.
Even though the namespaces were the same, the consuming code could not see the objects (such as Image or SqlConnection) unless I added the same Windows Compatibility Pack libraries into the consuming project. If anything, I would have expected this to cause issues as I now have two identical classes (same namespace and object name) in different assemblies. Fortunately, it is working. At least the unit tests are still passing.
Is this the way the Windows Compatibility Pack libraries are supposed to work? I had hoped that they would provide the functionality in the .NET Standard or .NET Core code but allow the .NET Framework to still use its own implementation.
The compatibility package references a few of the assemblies that were brought back to increase the compatibility of .NET Core with .NET Framework.
The way the package works is that there is a meta-package (the one that you reference) and it has references to individual packages that actually contain the implementation. Those individual packages have different assets depending on the target framework.
Take for example System.IO.Ports. That package contains the following assets (and a few more things that are not directly relevant to this):
net461
netstandard2.0
The netstandard2.0 asset contains the code that implements the System.IO.Ports functionality. You will use this if you are building a .NET Core application.
The net461 asset type-forwards the types exposed by the System.IO.Ports namespace to the assemblies you will find in the .NET Framework installation. You will use these if you are building a .NET Framework application (like a console application of web site).
This means that when you are consuming your library on .NET Core, you are using the implementation that was ported and made to work on .NET Core.
When you are using your library on .NET Framework you will use the implementation that is part of .NET Framework.
Related
I wanted to know the difference between the two packages and if it had anything to do with .NETCore and NETStandard and compatibility. I found this:
The NETStandard target framework is an abstract target framework that represents API surface of many frameworks and platforms. As such NETStandard assemblies can run on any platform that supports the NETStandard targeted by that assembly, for example: .NET Desktop, Windows Phone, Universal Windows Platform applications, .NET Core applications, etc. NETCoreApplication is a concrete target framework that represents a single platform with both API surface and implementation. .NET Core applications are runnable on their own. .NETStandard libraries must be published-for or consumed-by a specific concrete target framework to be used in that type of application.
on https://masteringalm.github.io/framework/2018/07/24/NetStandardvsNetCoreApp-Project-Types.html
But I’m not really sure how to use this to describe the differences between the two packages. I saw a post on this link: What's difference between .NetCoreApp and .NetStandard.Library?
Where it said:
NetCoreApp is a platform and .NetStandard.Library is a library supposed to be cross platform (portable class library) for various .NET platforms runtimes.
I think this connects to differences between the two specific packages mentioned in the question header, but could anyone describe the differences between the packages in a not so convoluted way?
.net standard
Each implementation of the managed framework has its own set of Base Class Libraries. The Base Class Library (BCL) contains classes such as exception handling, strings, XML, I/O, networking, and collections.
.NET Standard is a specification for implementing the BCL. Since a .NET implementation is required to follow this standard, application developers will not have to worry about different versions of the BCL for each managed framework implementation.
Framework Class Libraries (FCL) such as WPF, WCF, and ASP.NET are not part of the BCL, and therefore are not included in .NET Standard.
The relationship between .NET Standard and a .NET implementation is the same as between the HTML specification and a browser. The second is an implementation of the first.
Hence, the .NET Framework, Xamarin, and .NET Core each implement .NET Standard for the BCL in their managed framework. Since the computer industry will continue to introduce new hardware and operating systems, there will be new managed frameworks for .NET. This standard allows application developers to know that there will be a consistent set of APIs that they can rely on.
Each .NET version has an associated version of the .NET Standard.
.NET Core is a free, cross-platform, open source implementation of the managed framework. It supports four types of applications: console, ASP.NET Core, cloud, and Universal Windows Platform (UWP). Windows Forms and Windows Presentation Foundation(WPF) are not part of .NET Core.
Technically, .NET Core only supports console applications. ASP.NET Core and UWP are application models built on top of .NET Core.
Unlike the .NET Framework, .NET Core is not considered a Windows component. Therefore, updates come as NuGet packages, not through Windows Update. Since the .NET Core runtime is installed App-Local, and applications are updated through the package manager, applications can be associated with a particular .NET Core version and be updated individually.
For more information visit https://www.infoq.com/news/2017/10/dotnet-core-standard-difference/
Overly simplistic, but think of .NET Standard as a library that runs on any platform that can run .NET. This means it can run on Linux, Mac, Windows, etc. .NET Core is a minimalistic version of the "framework", so you can keep your your apps as small as possible and only add what you need. Core means only the core functionality that is absolutely required for an app to run.
Why is standard and core different? It is largely because the functionality of .NET on other platforms started open source with someone other than Microsoft. As such, the features have lagged behind .NET. The name of the .NET "framework" on other platforms was Mono. As some point .NET Core may well replace standard, but certain things have to get to the same level.
I imagine some purist will disagree with my oversimplification, but it is an easy way to get your head around the libraries.
As for what specifically is different between the two (or "what is missing from standard to be equivalent to core") - I am not sure. I am sure it can be looked up. In many cases, I have found Core works fine, such as dockerizing the application (Yeah, I made the word "dockerizing", but meaning running in a Docker container). The problems are when you run some package that cannot be handled in "Mono".
When it comes to packages you add into the standard or Core (Nuget anybody?), where there is a difference deals with one having features that cannot run in standard.
I have a project that is targeted to .Net Framework 4.8. Now, we need to use a 3rd party dll. The problem is that the dll is targeted to .Net Standard 2.1.
Is there a way to use this dll in the .Net Framework 4.8 project?
I added the dll, get this error:
Could not load file or assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
I searched, seems it should work directly. Maybe I need to add a reference? Not sure what needs to do now.
Thanks
You cannot consume a .Net Standard 2.1 assembly in any .Net Framework Version because the .NET Framework (even the last ever version, 4.8) does not implement .Net Standard 2.1.
The .Net Standard .NET implementation support matrix at https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-1 does not contain an entry for 2.1 under "Framework". Although very unlikely, the support matrix might change in time; this was the supported list at the time of writing.
More details on the decision by MS: https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/
Extract:
Given many of the API additions in .NET Standard 2.1 require runtime
changes in order to be meaningful, .NET Framework 4.8 will remain on
.NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core
3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1.
Library authors who need to support .NET Framework customers should
stay on .NET Standard 2.0. In fact, most libraries should be able to
stay on .NET Standard 2.0, as the API additions are largely for
advanced scenarios. However, this doesn’t mean that library authors
cannot take advantage of these APIs even if they have to support .NET
Framework. In those cases, they can use multi-targeting to compile for
both .NET Standard 2.0 as well as .NET Standard 2.1. This allows
writing code that can expose more features or provide a more efficient
implementation on runtimes that support .NET Standard 2.1 while not
giving up on the bigger reach that .NET Standard 2.0 offers.
Solution:
The easiest way would be to convince the 3rd party to backport/multi-target to support netstandard2.0 as well. Alternatively, you can switch to targeting .Net 6 (LTS), .Net Core 3.1 (LTS), or Mono instead of Framework 4.8 in your project.
UPDATE:
Another possible workaround:
You might also attempt some trickery with .NET Framework compatibility mode. I had no idea you could do this. You could, for example, make a "wrapper" project that targets standard and references both your .Net Framework 4.8 code and the 3rd party library, unless the 4.8 part uses WPF - perhaps there are other pitfalls in unsupported scenarios as quoted below. It sounds convoluted to me, but if you have no other option, it might be worth a shot. From the same original site:
Starting with .NET Standard 2.0, the .NET Framework compatibility mode
was introduced. This compatibility mode allows .NET Standard (*) projects
to reference .NET Framework libraries as if they were compiled for
.NET Standard. Referencing .NET Framework libraries doesn't work for
all projects, such as libraries that use Windows Presentation
Foundation (WPF) APIs.
(*) - Also .Net Core (elsewhere in the document/page)
I am writing a simple .NET 4.6.1 console application (not .NET core), as below
References are
The problem is, once compiled, it generates a hefty lot of dlls that are supposed to be build-in dlls. What is the problem?
You left a big clue in the screenshot.
They're recommending that libraries target .NET standard.
There's a good discussion at:
https://github.com/dotnet/standard/issues/146
Libraries should generally target .NET Standard as this ensures that
they can be consumed by any app. There will be circumstances where you
need to access .NET Core specific APIs, either because the API is new
and not implemented anywhere else, or the concept is .NET Core only.
That's why I believe we should make it easy to retarget between .NET
Standard and .NET Core so that developers never have to fear being
"locked in". Start with NET Standard and retarget if necessary &
revert back once a new version of the standard is available that has
all the APIs you need.
So gRPC now works with .NET Standard.
If you don't want to opt-in, you could build the particular library targeting the .NET Framework.
Say I have a solution with several projects included. One of projects is Main (where general code and APIs are placed) and the rest are kind of extensions (Extension1, Extension2, Extension3) for the Main and use third-party libraries. Now I'm making the solution compatible on both Full Framework and .Net Core Framework.
The solution had already had conditional building process depending on target framework before I started adding support for .Net Core, so I have no problems with conditional building yet.
The problem what I do have is that part of third-party libraries is not compatible with .Net Core yet. That makes a part of the extensions incompatible with .Net Core. The only option that comes to my mind is to have separate solutions and code bases for full framework and .Net Core Framework. BUT I would like to have same code base in both cases because my code is pretty compatible with both frameworks and otherwise it would be such a pain in the neck to support.
Is it possible to have only one solution for that case and be able to build (Main + (Extension1, Extension2, Extension3)) projects for full framework and (Main + (Extension1, Extension2)) for .Net Core Framework? If it's not, what options do I have?
Thank you all in advance
You want to be looking into .NET Standard - I'd also take a look at the videos put out by Immo Landwerth about it.
The tl;dr is that .NET Standard lists the APIs and methods which you can expect a .NET application (Framework, Core, WPF, Xamarin, etc.) to have access to. Higher version numbers of the standard include more APIs but reduce the number of frameworks you can use (Framework, Core, WPF, Xamarin, etc.).
Here's a visual of how .NET Standard is adopted and supported by the different frameworks.
Along the top are the versions of .NET Standard, and down the left are the versions of the frameworks. Using this chart, you can see that .NET Standard 2.0 is supported by:
.NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
etc.
This means that any application which targets any of those frameworks will have access to the APIs listed in .NET Standard 2.0.
In your example, you could have all of your business logic in .NET Standard compatible libraries (regardless of whether they are Framework or Core) and have two separate Main projects (one for Framework and one for Core).
This could be done with three separate solutions:
One for your .NET Standard class libraries
One for your .NET Framework Main (which includes the .NET Standard class libraries)
One for your .NET Core Main (which includes the .NET Standard class libraries)
You could also build the .NET Standard class libraries as a NuGet package (with or without hosting them externally) and pull them into your two (.NET Framework and .NET Core) Main solutions.
I'd really like to start using .NET Core and slowly migrate applications and libraries to it. However, I can't realistically upgrade my entire code base to use .NET Core and then go through the process of testing and deploying a plethora of applications in production.
As an example, if I create a new .NET Core application and try to reference one of my .NET Framework projects I get the following:
The following projects are not supported as references: -
Foobar.NetFramework has target frameworks that are incompatible with
targets in current project Foobar.NetCore.
Foobar.NetCore: .NETCoreApp,Version=v1.0
Foobar.NetFramework: .NETFramework,Version=v4.5
Is it possible to create a new .NET Core application and reference my existing .NET Framework libraries? If so, what's the process for doing that? I've spent hours going through Microsoft's documentation and searching their issues on GitHub, but I can't find anything official on how to achieve this or what their long-term vision is for this process.
Old question, but with the release of .NetStandard 2.0 and .netcore 2.0 and vs2017.3, the game has changed.
You can use the Full .NET Framework (TFM) with .NetCore 2.0, but how?
In Visual Studio 2017.3, you can reference the Full .NET Framework (any version) directly from within a .NetCore2 project.
You can build the .NetStandard2 class library and reference your TFM. Then reference your .NetStandard2 library from your .NetCore2 project.
For example, referencing json.net net45 from .NetStandard2.
Browse to the folder and select version net45 (not netstandard1.3)
See the dependency in the image below, no yellow warning as you see.
Even if a Nuget library is not ready to be ported to .Netstandard 2, you can use any API in the library that is compliant to net461.
Quoting for the .NET Core 2/Standard 2.0 announcement with links:
.NET Core 2.0 is able to freely reference libraries that have been built for .NET Framework up to version 4.6.1
However, some libraries may fail at run time if they try to use API methods that aren't available on .NET Core
Reference: .NET Core App target .NET framework 4.5.2 on Linux
A need to use third-party .NET libraries or NuGet packages not available for .NET Core
So only in cases where the libraries or NuGet packages use technologies that aren't available in .NET Standard/.NET Core, you need to use the .NET Framework.
Reference: Choosing between .NET Core and .NET Framework for server apps
You can now reference .NET Framework libraries from .NET Standard libraries using Visual Studio 2017 15.3. This feature helps you migrate .NET Framework code to .NET Standard or .NET Core over time (start with binaries and then move to source). It is also useful in the case that the source code is no longer accessible or is lost for a .NET Framework library, enabling it to be still be used in new scenarios.
Reference: Announcing .NET Core 2.0
Yes, we are currently attempting the same thing. The trick is to make sure that you are supporting the same .NET frameworks. Inside your project.json file, make sure the framework matches the framework of the project you wish to include. For example:
"frameworks": {
"net46": { --This line here <<<<
"dependencies": {
"DomainModel": {
"target": "project"
},
"Models": {
"target": "project"
}
}
}
},
FYI: You might need to change the framework of your .NET Core or your older projects to achieve this. .NET Core can be changed just by editing the project.json file as seen above. You can so the same in .NET projects by right clicking the project and opening properties. Change the framework level there.
Once you have matched the two project frameworks then you should be able to include them. Good Luck!
We delayed migrations as long as could as it seemed daunting as first. But we got an insistent client who wanted to migrate ASAP.
So we migrated their Fintech Web App developed on .NET Framework 4.8 Web Forms to .NET 6 Razor Page. Our team scoured though hundreds of online resources & spoke to Microsoft Tech Support before we started the project. Hope the high-level walkthrough of our journey help you plan your migrations.
Our .NET Framework Website consisted of 1 .NET Web Forms project and 12 Class Libraries.
Here is how we did it.
Refactored the .NET Framework 4.8 Web Forms code
We ensured that the Web Forms code behind did not have a single line of service or business logic code. When we did find some business logic code in the web forms code behind, we refactored it, by moving it to the class libraries.
Created new .NET Standard projects
We created a new .Standard 2.0 Class library project for every .NET Framework 4.8 Class Library. If the original project was called "FintechProjectName.StockMarketClient", we named the .NET standard project "FintechProjectName.StockMarketClient.Standard".
Copied all files from .NET framework to .NET standard
We copied all the class files from .NET framework to .NET standard projects. We then removed all the .NET framework class libraries from the solution and added references to the new class libraries. All projects compiled on the 1st try itself and all our test cases too passed with minor changes.
Create new .NET 6 Web App Project
We created a new .NET 6 Web App Project. We had to entirely redo the front-end as there is no direct path for migrating Web Forms to Razor Pages. This was the only project which took us about 1 month to migrate.
Reference .NET standard class libraries in the new .NET 6 website
We copied all the .NET Standard libraries to this new solution containing the Razor Pages web site. Added the references and got it to work.
Move from .NET Standard to .NET 6 class libraries
Once the new website was up and running, with all test cases passed, we did the last step in the process which was the simplest. Created .NET 6 class library projects for each of the .NET standard libraries and named the projects appropriately. Copied all class files from .NET standard projects to their corresponding .NET 6 projects. Then we removed the .NET Standard libraries and added references to the new class libraries.
Overall project timelines were about a month and a half, most of it spend on Razor Pages implementation using the same html design.
Note:
If you are using any 3rd party library which does not have a .NET standard or .NET 5 version, then you are out of luck. You will need to find a replacement nuget package and recode your application to use this new library.
In my case with .net6 referencing framework 4.8 library ( both winforms), the trick seems to be to add the reference to the framework dll as a shared reference.