We have a legacy VB.NET application. The frontend is being redesigned in MVC 5, and I was assigned to abstract the business logic to an API.
I created a library with some code to make calls to the API (so the developer building the MVC 5 app can easily install/update the package and use it).
But I would like to help the developer responsible to redesign the VB.NET project to consume the API with the same NuGet package.
Is it possible to create one NuGet package compatible with both, or do I really need to make two packages?
I read something about .NET Standard, but I couldn't find anything about VB.NET, it looks they work for C# only (I'm not sure).
If it's possible, should the VB.NET project use the same .net framework version as the package in order to work?
A compiled .Net DLL is language agnostic: you can use a DLL written in any .Net language from any .Net language.
Note that in general you can only reference .Net DLL (.Net assembly) that is compiled for that or lower version of .Net compared to one you set target .Net version of code you compile. Ideally both DLL (on in NuGet and VB.Net) target the same .Net version, otherwise read MSDN: Version Compatibility in the .NET Framework.
The language does not matter for .Net Nuget packages because they all compile to the framework(s) they target. This means C# assemblies compiled from C# code can be decompiled into C# or VB .Net regardless of the original language they were created in.
A little more detail:
Nuget packages are limited by the framework version they target, so your legacy app should preferably target the latest version of the .Net framework (4.7.1 as of this post) if you want to maximally utilise third party libraries and target the latest .net standard (2.0 as of writing).
.Net Standard is a compatibility standard, which means that if a language runtime version supports that version of the standard, it is guaranteed to have certain APIs available.
https://learn.microsoft.com/en-us/dotnet/standard/net-standard
Based on the table in that documentation, if your legacy application is targeting .net framework 4.5, you can only build libraries that target .net standard 1.1. Any higher version for your nuget package will prevent you from using it in your legacy app.
Related
I have a net6.0 SDK-style project and I want to use a library which seems to be only released to .net framework. After I added the reference, I got a warning as below. And for sure I can't use any classes from the lib in my code.
Package 'xxx' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework 'net6.0'. This package may not be fully compatible with your project.
I'm new to C#. Does it mean that each lib only works for specific .net versions? Library developers declare and compile their code for the supported .net versions and publish to nuget. When we refer to a nuget lib, nuget will try to find the dll which matches our .net version and throw the above warning if not found.
That is to say, to be compat with the library, I have to downgrade my project to net472?
Yes, that is correct. Each library is typically compiled for specific versions of .NET.
If you want to use this library, you will need to downgrade your project to target one of the supported .NET Framework versions.
Does it mean that each lib only works for specific .net versions?
It is more nuanced than that; usually, libraries are perfectly happy with lower versions - meaning: if I target net5.0 from a library, and your application is net7.0: that's fine (with the caveat that even minor revisions can - but rarely - break something, if it was depending on functionality that has changed, perhaps because it was a bug - or some other implementation detail).
However, there is a hard break between .NET Framework and .NET Core (now just .NET); a .NET Core / .NET application cannot reliably consume a library that only targets .NET Framework, as .NET Framework is a fundamentally different framework than .NET Core / .NET.
In this scenario, libraries can do a few things to help you:
they can target some variant of .NET Standard, which is the subset of APIs that should work correctly on both .NET Framework and .NET Core / .NET (and other platforms that implement .NET Standard, such as Unity, Mono, Xamarin, etc as)
they can multi-target, which is to say: in the nupkg they can include multiple assemblies, perhaps a net472 target, a net6.0 target, and maybe one or two others
(the second option is more common than the first; .NET Standard is fading into the background now)
If the library you're using only supports .NET Framework, then indeed that won't work from .NET Core / .NET; you have three options:
limit yourself to .NET Framework (I do not recommend this option)
see if the library can be updated to use .NET Core / .NET (by contacting the maintainers, and possibly even proposing the changes yourself)
use a different library
The problem I have is the following: we have a series of functions, methods and datatypes in Dafny and with it we generate a c# dll library. In order to make use of those libraries, we have added them as a reference to a visual studio c# console application project.
The problem I have is that these libraries refer to a dependency to System.Private.CoreLib. The only place I have found this library is in the source code of dafny. By adding it as a reference, it becomes "incompatible" with all System.* libraries imported by default in c#. This makes it unable to create a class, method etc. Attached are screenshots of the problems I just mentioned.
Finally, if I compile these libraries with Dafny 2.0 (deprecated), I don't have this problem, but I would like to work with the latest version of dafny.
Thank you in advanced.
System.Private.CoreLib is part of the .NET Core runtime and doesn't have to be referenced directly. That's where the basic built-in types like Array, DateTime, Thread etc live. It's used implicitly by all .NET Core projects and doesn't have to be referenced explicitly.
The Dafny 3.0 release notes explain that the tooling migrated to .NET (Core) 5 from Mono and the .NET 5 version of Coco/R is used now
Tool
Migrate to .NET 5.0.
If you used to use mono Dafny.exe to run Dafny before, use dotnet Dafny.dll now.
Implementation
Use .NET 5.0 version of Coco/R.
Your projects will have to target .NET (Core) 5 as well.
I have a Xamarin Forms project and the majority of times that I want to install a nuget package I have an error saying that:
Install-Package : Could not install package 'Microcharts 0.7.1-pre'. You are trying to install this package into a project that targets
'.NETPortable,Version=v4.5,Profile=Profile259', but the package does not contain any assembly references or content files that are compatible with that framework.
I Assume I can work this out by changing the project .net framework target. But when I go and change it, I get an error saying that it cannot change the target because that implies upgrading nuget to 3.0 and It can´t do that.
So my question is: Which is the best way(and simplest) to change the target framework so I have less problems like above with nuget packages.
This library was built to target .NETStandard v1.4. You are trying to use it in a PCL project, that is not possible. PCL is on the way out as the previous not-so-good way to build cross-platform libraries, .NETStandard is the new way.
There is no older version available of this library, rebuilding it from source is a possible option. But realistically it is time to move on to avoid hitting this wall over and over again, you need to update your tooling so you can consume these kind of libraries. The VS2017 Community edition is freeware.
It is time to go from your
.NET PCL Library to an appropriate .NET Standard Library.
Here are some links concerning the migration to .NET Standard.
Upgrade PCL to .NET Standard Class Library
.NET Standard 2.0 Support in Xamarin.Forms
Converting PCL (Portable Class Libraries) to .NET Standard Class Libraries
.NET Standard - PCL Compatibility
.NET Standard Implementation Support
My Suggestion concerning the version of the .NET Standard to use.
If you don't care about backwards compatibility (You want to use the latest OS and SDKs) go all the way to .NET Standard 2.
If you want to have a good backward compatibility you should go on .NET Standard 1.1 - 1.5.
On most projects i use 1.4 - 1.5.
.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