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.
Related
I have been writing an analyzer and using .NET Standard 2.0 so that I could target .NET Framework 4.7.2, which I was using in the VSIX version of the analyzer. Soon however I chose to drop it as supporting it was not beneficial. Ever since I have wanted to upgrade the supported framework to .NET 5.0 to also get the new language features along the path.
How would that affect the end users that would include the analyzer to their projects through the released NuGet package? Should I also keep supporting the older framework versions?
You can't use anything other than .NET Standard 2.0, because VS runs under .Net Framework 4.* and the csc Roslyn compiler runs under .Net 5/6. The common ground is .NET Standard 2.0, nothing else will work.
This is still the case with VS 2022, it is still a .Net Framework application, the only difference is that it's now a 64-bit process, which means that your analyzer needs to be Any CPU to work in both.
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?
I'm new to C# programing & i just installed .NET SDK but i'm confused if I should also install .NET Core SDK or should I leave .NET SDK alone. I've tried searching on google & on YouTube but I can't find the answer.
.NET 5.0 is the new release of the family. The goal is to merge .NET Framework and .NET Core into one unified platform.
So in short this is a new version of .NET Core, if you just want to start programing in .NET without the need of one version or another you're fine.
You can check with dotnet --info the .NET SDKs installed
.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).
Is .NET 4.5 mandatory for using Windows API Code Pack (Microsoft.WindowsAPICodePack and Microsoft.WindowsAPICodePack.Sensors.dll)
Will it work for .NET 4.0?
The latest version of Windows API Code Pack is 1.1 but there doesn't seems to be a dedicated page for it.
The library was published when Windows 7 was released (replacing the "Vista Bridge" library), and targets the .NET Framework version that is pre-installed on Win7, version 3.5. You cannot go lower than 3.5, it has a dependency on System.Core.dll. Targeting .NET 4.x is not a known problem.
Do keep the target operating system requirement in mind for the Sensor api, the underlying COM interface (ISensor et al) requires Windows 7 or higher and is not available on the Server edition.
The actual code of the Windows API Code Pack is compatible with .NET 3.5 and above. .NET 4 or 4.5 certainly won't be a problem.
I just downloaded the NuGet package using Install-Package WindowsAPICodePack-Core and it works for .NET 3.5.