I have an old .Net Class Library project project with some old ADO .Net code to run SQL queries but also has some third party libraries that have been upgraded over time.
I think its time to upgrade this to Entity Framework so was considering moving this from .Net 4.7 to .Net 6 at the same time too.
It seems i have to upgrade the project to an SDK version but with it being a large project could i upgrade this to an SDK version using .Net 4.7 so I could replace existing projects with the newer version of the class library and the introduce .Net 6 at a later date?
I dont want to do a large upgrade but prefer to take it in smaller chunks but after researching around i cant find a good enough answer to see if i should focus on an upgrade or a rewrite (we want to leave a rewrite as a last resort)?
So firstly, we should probably clear up some understandings. .Net 4.7 is actually .NET Framework, and .Net 6 is what evolved from .NET Core, now referred to simply as .NET. (Further, .NET [Core] skipped versions number in 4.x to try to reduce this confusion)
.NET Framework and .NET are different. .NET Framework is Windows only; .NET is cross-platform. Not all the libraries you may have used with .NET Framework may be available for .NET [6].
I don't think it would necessarily require a rewrite, but you're going to need to do some research into what targets the libraries you're using are targeted at in their TargetFrameworks attribute. For example, here's one from a library I use:
<TargetFrameworks>net462;netstandard2.0;netstandard2.1;net6.0;net7.0</TargetFrameworks>
net462 is indicating it can target .NET Framework 4.6.2 specifically.
net6.0 and net7.0 are similar, but for .NET 6.0 and .NET 7.0 respectfully.
netstandard2.0 and netstandard2.1 are probably the more useful ones for you at this point. They refer to standardization between various versions, meaning it can potentially target both .NET Framework and .NET, which is what you're looking for here to not have to rewrite. You can read more about .NET Standard here.
Regarding EntityFramework specifically, it looks like you may be possible as a stepping stone, though its target would be .NET Framework 4.5 rather than 4.7, so mileage may vary. It supports .NET Standard 2.1, though which should make it viable for later .NET versions (6+). I'd recommend getting your application into .NET (5+ at least) as soon as you're able, though, and switching to EntityFrameworkCore when you get the chance.
Related
I googled...
I only saw way to migrate ... .Net Framework to .Net Core , but no on the contrary(.Net core to .Net Framework)?
If have take .Net Core project and need migrate to .Net Framework? (is there any way?) ... just curiosity.
Possibility of a practical solution or a tool that did this
I have not undertaken such a move manually but .NET Framework is at its end. All future .NET developments will proceed under .NET (Core)
.NET Framework 4.6.x and above will be frozen in long term support for about 10 years, getting critical updates for i.e. security but no newly developed features. This breakdown gives concrete dates for .NET Framework's lifecycles. To be honest, I am also unsure how long the support for various nuget packages for Framework will be kept up. Just because 4.6+ will be around for long, doesn't mean each and every 3rd party library will be getting updates. These are individuals and companies that most likely will be allocating their resources to cutting edge developments for .NET, not for .NET Framework
.NET Framework by definition is Windows only, while .NET is cross platform. You should be using .NET from now on
Also, take from me personally, I am stuck on .NET Framework 4.6 at my job and there are a lot of really cool things that are being added to the language that I wish I could use. Don't constrain yourself to .NET Framework if don't have to
Whenever I'm creating a new solution with VS2017 I'm usually choosing one of the newer Frameworks as a target (most often currently 4.6.1).
Now though when I create a .dll Subproject within the solution it sets the target Framework for that subproject to .NET Standard 2.0. With that being the most "modern" target Framework that can be set.
This though has the Problem that I can't use some things I'm used to like "Resources.MyResource" (which works fine with Framework 4.6.1).
Now I'm wondering is there any way to rectify this Problem? Either by increasing the .NET Standard, or by enabling one to choose the .NET Framework also for These .dll Projects (aside from creating the .DLL Project outside the solution and then importing it into the solution)?
.Net Standard is a specification of the .NET API's that are available on all implementations of .NET.
What does this mean? - Calling an API in .Net Standard will run on all .Net versions that have implemented that version of the Standard.
SO what does that mean? - .Net Core introduces cross platform development. The need to now possibly share code between a Windows machine and a Linux box require a "standard" that can be implemented across all equally.
Think of it as a contract. If a version of .Net implements .Net Standard 2.0, it is saying that it will have a version of the API's in that standard available for use on all platforms.
So, back to your original question. .Net Standard 2.0 is not a "new" version of the framework. It is the contract that your subproject, assuming it's a class library is going to abide by. If an API appears to be missing it is because it doesn't have it as part of it's contract (maybe). I say maybe because it's not the easiest to find.
**** Start Revised ****
Here is a table of the versions of .Net that support the versions of .Net Standard.
In your case 4.6.1 doesn't even support 2.0. The last version of the Standard that 4.6.1 supported is 1.4.
I thought 4.6.1 supported .Net standard 2.0 after I wrote the above and upon further reading found a more up to date chart along with this post stating it is supported in 4.6.1. sigh
**** End Revised ****
This SO answer seems to indicate that 1.4 does have Resources in it but it was preview versions and things change. I don't see it in the APIs supported list but I could have missed it. The SO answer seems to indicate it was a tooling issue and could be worked around. That could be fixed by now....
Here's where you can look to see what each Standard supports for APIs.
HOWEVER, I don't think this is actually what you want.
I think what you really want is to simply change your sub project's target to 4.6.1 as is your main app since I highly suspect you have no need/desire to run cross platform.
Additionally, prior to .Net Standard 2.0, thousands of API's were not in the Standard. IMO, prior to 2.0, the Standard is a hard sell especially for users on the .Net Full Framework.
From what I can tell the Project Template to use is under "Windows Classic Desktop > Class Library (.Net Framework)"
EDIT
That said, you can add a .resx file to a .Net Standard project and use it in exactly the same way.
.Netstandard2 is released final with .Net Core 2.0 and vs2017.3 with nuget4.3 and API surface cover 32k (except 41 class) and full cover net461
Quoting from Announcing .NET Core 2.0
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.
We expect that this feature will be used most commonly from .NET Standard libraries. It also works for .NET Core apps and libraries. They can depend on .NET Framework libraries, too.
The supported scenario is referencing a .NET Framework library that happens to only use types within the .NET Standard API set. Also, it is only supported for libraries that target .NET Framework 4.6.1 or earlier (even .NET Framework 1.0 is fine).
So, in .netcore2 environment we can continue build/use Full .Net Framework as we did many years without the need to switch to .netstandard2 libraries.
With multi target project ,(net64;netstandard2), we get .net standard 2.0 out of box free (zero time effort) with the same API coverage.
Can you share your experience regarding: Can we continue build Full Framework 4.6.1 class library and use it in .netcore2? what is the limitation?
When you build a .NET Framework library, you can only use 4.6.1 with .NET Standard. If you want to use a newer API that is in e.g. netstandard2.0 or .NET 4.7, you'd need to retarget your library to 4.7, which then cannot be used by netstandard2.0 / netcoreapp2.0 projects. Effectively, you are locked into .NET Framework version 4.6.1 and can (/should) never update it to a newer version. (Of course, there is a workaround involving disabling the implicit fallback definition and manually setting AssetTargetFallback in the consuming project, but it requires manually editing the .csproj file and instructing all package consumers to do so).
Furthermore, the compatibility layer does not protect against using APIs that are not implemented on netstandard so a consuming project may get exceptions about missing types, methods, assemblies etc. Only when you target .NET Standard, your library is guaranteed to work on .NET Standard conformant platforms.
A practical limitation currently is that referencing .NET Framework library projects(!) (not NuGet packages) from .NET Core is not possible / only works with specific setups and workarounds (you will get an incompatible target framework warning).
I just can't understand why I can't use an old library in a .net Core app targeting Windows and the full .net framework (I don't care about multi-platform).
Just trying to understand the limits here. I don't want to hit a wall after investing too much into it.
Steps followed:
Create a new .Net core web Application
Added PetaPoco from NuGet (just an example)
Can't use the library
From a comment from you on a deleted answer to this question
It's not about this particular reference. I just want to understand why I can't use an arbitrary Windows DLL. (I don't care about multi-platform) – Eduardo Molteni
It appears you are not too concerned why this specific project is not working (the deleted answer you commented on covered that quite well and if it was not deleted I would have up-voted it) but why in general you can't use a .NET Framework DLL in a .NET Core project.
Here is a diagram showing the layout of the ".NET ecosystem"
Things built for .NET Framework can't use DLLs built specifically for .NET Core, and things built for .NET Core can't use DLLs built specifically for .NET Framework because they are two "siblings" in the hierarchy.
Both .NET Framework and .NET Core can use .NET Standard libraries in their projects because .NET Standard is the "parent" of both the framework and core. Many newer NuGet packages now release versions that target .NET Standard so the library can be used with both versions. See the below chart to see what version of the .NET Standard library is compatible with various platforms. netstandard libraries are forward compatible so something that is compatible with 1.5 (like .NET 4.6.2) is also compatible with versions 1.0-1.4
We distribute a .NET 3.5 assembly to more parties to be referenced and used in different applications.
We are now intending to upgrade this assembly to .NET 4.6 so it will benefit of all performance and security improvements in this .NET version and not for using new .NET features.
But we don't want to break existing applications that are using it.
Some consumer applications might still be using .NET 3.5 so they won't be able to use it, so I was thinking how about having two projects targeting two .NET versions (3.5 and 4.6), but same code files.
What would you recommend for maintaining and distributing one assembly code base for both .NET 3.5 and .NET 4.6 version lines?
Later Edit: This question is not about referencing a .NET 4.6 assembly in .NET 3.5, it's about how can a .NET 4.6 application to use my assembly and benefit of the security and performance of .NET 4.6 while running it. The 3.5 apps should continue to use my 3.5 assembly.
Look into creating your own nuget repository and publish the libraries in each specific version of .net needed. (For one package can have varying .net versions as needed).
Once in your nuget repository they have their own version and can be updated either in lockstep or differently. That way the consumers can use the target version as needed for the target .net version.
See Hosting Your Own NuGet Feeds
There seem's to be an assumption that an identical code base compiled in .Net 4.6 will gain "performance and security". This isn't true. If the codebase is identical it will perform identically and the security will be the same.
Each iteration of .Net contains the previous one (it's actually a monolythic process that Microsoft are trying to move away from, hence projects such as Katana)
Each new version of the .NET Framework retains features from the
previous versions and adds new features.
source
Simply upgrading the framework will not magically make you code faster or more secure.
At a previous company we used to do as you are suggesting and ship a .NET 3.5 version (for users on XP) and a .NET 4.0+ (up to 4.5) version.
The way we did this was to have two separate solutions basically called the same and have each of the projects mirrored from the .NET 4.0 version into the 3.5 version. These were actual projects added to the solution.
For the files we simply linked the .NET 4.0 files directly into these projects, but we did have to manually create each folder so that the namespaces matched. For any code that was not supported by .NET 3.5 we had to create an actual file in the 3.5 solution and re-write entirely that feature so that it would compile with 3.5.
This was not fun and actually wasted a lot of development time simply looking after a legacy solution. In the end we migrated everything to .NET 4.5 and expressed to users that we were discontinuing support for the 3.5 version, for us there was not cost for the user to upgrade so it was up to them if they wished to upgrade hardware for new functionality.
In conclusion I would say if you don't need to I would recommend that you don't attempt to support both solutions, it will impact your development time and frustrate developers when they've written this nice feature using the concurrent functionality to then realize this isn't in .NET 3.5 (I know what this is like because I've had it happen).