I'm porting the existing library from .Net Framework 4.7.2 to .Net Standard 2.0 to make it cross-platform but still retain compatibility with .Net Framework apps.
I do not understand how to avoid non-cross-platform dependencies.
My library uses dynamic types and Settings.Designer.cs.
To support it in .Net Standard, I have to add a reference to Microsoft.CSharp and System.Configuration.ConfigurationManager NuGet packages, which in turn adds dependencies to some other packages like System.Security.Principal.Windows, even though I don't use any security-related code.
The last two are clearly part of Microsoft.Windows.Compatibility package.
How to find out, if these dependencies are cross-platform or not (i.e. part of Windows Platform Extensions)?
When I go to .NET API Browser I see that Microsoft.Csharp is not in .Net Standard 2.0, however it is in .Net Platform Extensions 2.1 and further. Does it mean, that this package is not cross-platform? Are there any other services to check platform support for NuGet packages?
When I created a simple test app on .Net Core 2.1 that uses my library and published it to a Linux platform with dotnet publish -c Release --self-contained true --runtime linux-x64, the app actually works fine on Linux machine. Does it mean, that my lib is fully cross-platform and I can safely use it in production, or I may still encounter System.PlatformNotSupportedException on Linux in the future?
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
I have a .NET Framework library with NuGet package dependencies. This library is consumed exclusively by .NET Framework projects. Some of them by local project references, and most through NuGet. I publish the library to a private NuGet server.
A few projects have cropped up using .NET Core based infrastructure, and I would like to make my standard library available to these projects. I am not switching any of the existing infrastructure to .NET Core. I don't want to introduce .NET Core dependencies into every existing .NET Framework project. I have noticed that when I install certain multi-targeted libraries, sometimes they include "netstandard" or something like that -- and install lots of dependencies. These are unacceptable and get immediately uninstalled from .NET Framework projects.
Is it possible to multi-target my .NET Framework (4.72 if it matters) project to .NET Core as well, while still producing native .NET Framework libraries? I can copy and paste all the code in my library into a netcoreapp3.1 project, install NuGet dependencies, and that code runs fine. However, I don't want to port this library to .NET Core, and then multi-target it back to .NET Framework. As far as I am aware, that is not the same as having a native implementation. I just want to be able to use the library in a .NET Core app without copying and pasting the entire library, and letting the versions get out of sync. The less ceremony the better.
My csproj file doesn't have a <TargetFramework or <TargetFrameworks> property. It has a <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion> property.
Is what I'm trying to do possible? I can't tell from the documentation I have read.
I want to create a Nuget Package for a C# library that targets .NET Framework 4.0 and higher.
If I put my library in a directory named Net40, will this cause issues for projects that target say 4.1 and higher?
Should i just publish my library in a lib folder without specifying the supported .NET Framework version?
My library supports .NET Framework 4.0 and higher.
The reason why I am asking is that sometimes projects get messed up quickly when they target a different platform whilst the installed libraries via NuGet target another platform version. At least I want to avoid issues when developers target 4.0 and higher.
I hope your advice will be very helpful.
The question is stupid enough, but it didn’t work with NuGet before. After installing the NuGet package through the console, to connect to PostgreSQL, files appeared that NetFramework should contain. Without copying these files, the project does not start. What to do to get rid of them and not copy them to the directory with the program. In my understanding, these files should be taken from the framework.
See screenshots:
All need files in project C#
My guess is that you have .Net Standard 2.0 libraries/dependencies in your project.
.NET 4.6.1 might add additional runtime dependencies in your output folder:
.NET 4.6.1, 4.6.2, .NET 4.7 and 4.7.1 all have partial .NET Standard
2.0 support in the natively shipped runtimes, but they still are .NET Standard 2.0 compliant by adding additional runtime dependencies into
your output folder to provide the missing functionality. NuGet along
with the runtime targeting handles automatically adding those
dependencies to your projects to provide the needed runtime support
for those extra features. A lot of those assemblies override behavior
from the base framework and .NET uses runtime redirects to route api
calls to the appropriate assemblies rather than than mscorlib.dll or
other system assemblies.
.NET 4.7.2 is the first version of the full .NET Framework that is
fully .NET Standard 2.0 compliant without any additional dependencies.
See: https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET
In other words, targeting .NET 4.7.2 should get rid of the additional files.
Does anyone know if .NET Standard 2.0.0 is supported on Mono? I currently have a build that is working fine on windows 10. When I attempt to use in Mono in a Ubuntu Linux environment I get the following error:
Could not locate the assembly 'netstandard'. Check to make sure the assembly exists on disk.
Dotnet core 2 is added with no problems via the SDK, but I seem to not have any references to .NET Standard 2. I had a similar problem on windows 10 originally, which was resolved after I updated my version of visual studio.
Consult the release notes for details, but Mono 5.4.0 includes NuGet 4.3.0 and MSBuild 15.4.
Mono 4.8.0 Preliminary support
API additions for .NET Standard 2.0
We added APIs to comply with .NET Standard 2.0, which is still a work in progress at the time of this writing. Note that in some cases an implementation is still missing and will throw at runtime.
Mono 5.2.0 Runtime support (compiling is in "Preview Status")
.NET Standard 2.0 groundwork
We’ve done all the groundwork to support libraries that conform to .NET Standard 2.0. Loading and running a library compiled against the 2.0 standard should work fine, tooling support (i.e. creating a .NET Standard 2.0 library) is still in preview though.
.NET Core 2.0 SDK Installation needed
You’ll need to install the .NET Core 2.0 SDK for tooling support as we use the MSBuild tasks which are installed as part of the .NET Core 2.0 SDK, similar to how Visual Studio/MSBuild on Windows does it.