I'm prototyping a .net core 2 web application. I've been asked to use Log4Net for handling our logging, but I want to put it in a .net framework 4.6.1 wrapper project as to allow for changing out the internal logging systems without having to update all of the method calls throughout the site.
Everything that I've found so far is for doing one or the other. Wrapping the log4net in 4.6.1 or doing a direct reference to the .net core.
So far, my 2 main exceptions are "FileNotFoundException" for when I use it as a direct reference, or when I do the PackageReference in the Framework proejct files I get a "Logging is not compatible with netcoreapp2.0. Logging is framework 4.6.1.
First, I would recommend making your wrapper using .NET standard 1.3 as this is the currently .NET core version supported by log4net, plus, this would allow you to reference this wrapper in .NET core and .NET framework 4.6 and up.
Second, see: https://stackify.com/making-log4net-net-core-work/ for some more info on getting log4net working with .NET core.
Related
I've inherited a bunch of net framework 4.71 solutions, and two net core 2.1 solutions.
I need to write a library for blob storage that can be used by both of them. I found that the net framework won't call a net core library, and a net core framework won't call the net framework library. So I was in the midst of trying a couple of net standard 2.1 libraries. (one for external models and one for the blob storage functions)
I haven't even gotten to the point of making sure that the net core and net framework projects can reference net standard libraries.
Question 1) can net framework and net core reference net standard libraries?
Question 2) is there a way to even share code between net core and net framework or should I just work on creating duplicate libraries?
Edit: I did just finally figure out what I was doing wrong in referencing the net standard model project from the blob storage net standard project. I had to add the project reference directly. Haven't had to do that in a long time. Visual Studio would add it for me with net framework.
Edit2: looks like I'm just an idiot. I finally figured out that I needed to also manually add the project reference for the library to the net core project. Now it compiles. Thanks everyone.
can net standard libraries reference other net standard libraries?
yes; a netstandard2.0 library can reference another netstandard2.0 library; a netstandard2.1 library can reference netstandard2.0 and netstandard2.1 libraries
can net framework and net core reference net standard libraries
.NET Framework 4.7.1 can allegedly reference netstandard2.0 libraries, although it has some assembly-binding-redirect problems in a few areas ("unsafe", "buffers", etc) - and some areas are simply glitchy; it cannot reference netstandard2.1 libraries
.NET Core can reference netstandard libraries; these days you shouldn't really be looking at .NET Core below .NET Core 3.1, which means it can reference both netstandard2.0 and netstandard2.1 libraries
is there a way to even share code between net core and net framework or should I just work on creating duplicate libraries
multi-targeting is also an option, if netstandard doesn't work well for you; you can use <TargetFrameworks>netcoreapp3.1;net471</TargetFrameworks>, for example, and use #if as necessary to switch between target-specific implementations.
In additional to the excellent answer by Marc I would like to add the .net standard support matrix that shows what .net version support what .net standard version.
The way I understand it, the intended migration strategy is something like this
Migrate the core libraries to .net standard 2.0 (or lower), starting with the libraries with the fewest dependencies.
Migrate the applications, UI projects, and any other project that depends on things outside .net standard.
Migrate the core libraries to .Net core or .Net 5. No new versions of .net standard will be released. So to use any new features the libraries need to be updated to .net core/5/6 etc.
This way should limit the number of projects that need to be updated at once. Allowing migration to be done piecemeal rather than all at once.
I created a new project in VS 2019 in .NET Framework 4.6 and now I want to upgrade it to .NET Core 3.1.
I do not want to do manually because their is ton of code.
How can I do this?
Microsoft published a guide for porting .NET Framework applications to .NET Core:
https://learn.microsoft.com/en-us/dotnet/core/porting/
In a nutshell, it boils down to the following:
Manually convert your dependency and project files.
Ensure that all your dependencies are compatible with .NET Core.
Use the .NET Portability Analyzer to find out if you are using features which are not supported in .NET Core.
Use the .NET API analyzer to find out if you are using features which are not supported on some platforms.
Target .NET Core, fix compile errors and test.
The guide contains detailed descriptions for specific steps (e.g., how to port your WinForms/WPF UI code), which are too long to paraphrase in an SO answer, so be sure to read it carefully.
I do not want to do manually because their is ton of code.
Then you'll have to pay a developer to do that for you. Sorry, but at the time of writing, there is no fully automated .NET Framework -> .NET Core converter available.
I'm building an ASP.NET Core Web API project. I will be heavily using EF Core with the connection with SQL Server. I want to organize the project around 3 main tiers: Core/Logic/Domain, Data/Infrastructure and Web/API.
Web/API will be definitely a .NET Core project, but I'm struggling with the decision whether Core and Data projects should be .NET Core library or .NET Standard library.
My question is, will I lose any features or anything while building my data persistence in .NET Standard library?
For a class library, the target framework simply specifies a compatibility layer. The ultimate functionality comes from the target framework of the project that references the class library.
For example, let's say that you create a .NET Standard library, and then you include that in a .NET Framework project. Everything you do happens on .NET Framework, and for all intents and purposes you could've targeted .NET Framework from your class library as well. The choice of .NET Standard simply says that you're going to use APIs from some .NET Standard-compliant target. That's all. As a result, the functionality of something like EF Core, ultimately depends on what you drop the library into, not what framework your library targets.
As to whether to choose .NET Standard or .NET Core as the target framework for your library, simply: use .NET Standard unless you have a good reason not to. If you target .NET Standard, you can drop it into any project that targets any framework that is compatible with the version of .NET Standard your library targets. If you choose .NET Core, you can only use the library in .NET Core projects.
Things get a little murkier when you start looking at .NET Core 3.0, though. You can technically target .NET Standard 2.1 and get all the goodness of .NET Core 3.0, but nothing but .NET Core 3.0 actually supports .NET Standard 2.1. You can target .NET Standard 2.0, but then you're stuck with .NET Core 2.2. In other words, if you want to use .NET Core 3.0, right now, there's no functional different between choosing .NET Standard 2.1 or .NET Core 3.0 as the target framework of your library. In either case, it will only work in .NET Core 3.0 projects.
Adding even more confusion, Microsoft is moving the next version of everything under the .NET 5 umbrella. What becomes of .NET Standard at that point hasn't been discussed, by I'd imagine it largely goes away. Once there's a .NET 5, any project can target .NET 5 and be used by any other project that targets .NET 5. That's still a ways off, though. The reason I bring it up, is that if you want to use .NET Core 3.0 today, there's not much point in targeting anything but .NET Core 3.0. Most of the stuff in .NET Standard 2.1 is not back-portable to things like .NET Framework and Unity, so those will never be on .NET Standard 2.1. The path forward for those frameworks is making them .NET Core compatible, to eventually end up with .NET Core 4.0, which Microsoft will call .NET 5.
Long and short, the best performance and features are with .NET Core 3.0, as long as you can go 100% .NET Core 3.0, then that's what you should target. If you need to use your library in something like an Xamarin or .NET Framework app, then stick with .NET Standard 2.0.
From the .NET Standard Microsoft Docs
The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations.
From the .NET Core Microsoft Docs
.NET Core is an open-source, general-purpose development platform
What this means in relation to your question.
Creating a .NET Standard library, you would be able to pull that library into a .NET Core project or a .NET Framework project assuming that the .NET Core/Framework project would adhere to the same .NET Standard version of your library or greater. So, the .NET Standard library would give you more flexibility regarding the projects you would be able to pull that library into(good if this needs to be pulled into legacy applications running on .NET Framework >=4.6.1 as well as new applications that would be written in .NET Core).
The only hiccup I've encountered with this approach is regarding migrations. If you want to use EFCore Migrations through the dotnet ef commands, it expects you to target a project with a .NET Core version. So, if you create your DbContext in the .NET Standard library and want to create migrations from it, you will either have to give it a startup project that is a .NET Core project or implement a 'Design-time DbContext Creation'. As an aside, this last option does have a few limitations, one of which is documented in an issue on GitHub.
Referring to Why use the full .NET Framework with ASP.NET Core?, it appears .NET 4.7.2 is the way to go forward?
Our existing application targets .NET 4.6.1 using ASP.NET Boilerplate.
Is it mandatory to migrate to .NET 4.7.* in order to leverage ASP.NET Core 2.1 features?
To use .NET Core 2.1 features, you need to target .NET Core 2.1
There is .NET Standard, which is an intersection of features that are available in a range of implementations, including .NET Core and .NET Framework. If you target .NET Standard (some specific version), then you can use the features available in that version of .NET Standard, and it should run on either .NET Framework 4.7.2 or .NET Core 2.1.
As a general guide: libraries (such as Aspnet Boilerplate) should now - where possible - target .NET Standard, but will often have a multi-target build to allow them to internally exploit target-specific features of specific frameworks (perhaps using the enhanced "span" or SIMD capabilities in .NET Core).
Application code should (and must, if it is an executable) target a specific framework such as .NET Framework or .NET Core.
No, it is not necessary to migrate to .NET 4.7.* in order to leverage ASP.NET Core 2.1 features.
ASP.NET Core 2.x is made up of .NET Standard libraries. Apps written with .NET Standard 2.0 run anywhere that .NET Standard 2.0 is supported.
ASP.NET Core 2.x is supported on .NET Framework versions compatible with .NET Standard 2.0:
.NET Framework 4.7.1 and later is strongly recommended.
.NET Framework 4.6.1 and later.
You only need to migrate to .NET 4.7.2 if you need features in Announcing .NET Framework 4.7.2:
ASP.NET – Dependency Injection in WebForms
ASP.NET – SameSite Cookie
ClickOnce – Per-monitor support for WPF and HDPI-aware ClickOnce deployed apps
ClickOnce – Enable SHA256 timestamping of Deployment Manifests
SQL – Azure AD Universal and Multi-factor Authentication Support
BCL – Cryptographic Improvements
BCL – ZLib decompression support to DeflateStream
BCL – Additional Collection APIs
WorkflowDesigner High Contrast Improvements
WPF – Finding ResourceDictionaries by Source
WPF – Finding ResourceDictionary owners
WPF – Finding StaticResource references
References:
ASP.NET Core targeting .NET Framework
.NET Standard implementation support
For real, if you're building an application using .NET Core/Standard, but in your application, you may have some reference that using .NET Framework, it must be a big problem.
A story: I'm building a web application using ASP.NET Core, in this application, I want to have an extension that converting HTML to pdf.
I've tried to searched on Google and found a plugin that is called: itextsharp. And the problem comes from here.
itextsharp is using .NET Framework while my main project is using .NET Core. Since I want to create a class library to build this extension, I have 3 options:
Using .NET Core class library.
Using .NET Standard class library.
Using .NET Framwork class library.
All of them can be refered to the main project. BUT:
I cannot use itextsharp references (itextsharp.dll, itextsharp.xtra.dll, itextsharp.pdfa.dll, itextsharp.xmlworker.dll...) in .NET Core/Standard class libray. All of them can run only on target .NET Framework.
(I haven't mentioned about how to convert the code to target .NET Standard or Core because of license yet)
And my solution is: Build a .NET Framework app and publish it to exe file before appending to the main project as a reference.
P/S: For now, itextsharp has a Core version but I think it's not good enough (problems about: displaying images, fonts with unicode text, style tag...).
Totally, if you want to build some app that is using target .NET X, you must make sure all of the references can use target .NET X, too.
Another example: if you want to build a class library that using Razor class library. You must make sure that all of the references are using target .NET Core/Standard. Because Razor class library cannot refer to .NET Framework class library.
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.