CODEWITHSUNDEEP
.net-core
Steve
Steve

Reputation: 1316

Porting a library to .NetCore. How do I know which nuget references are 'full' .NetCore (and therefore Linux/Mac compatible)

I am currently tasked with porting an code library over to .NetCore. Fundamentally, this is going fairly smoothly but there is one thing that is causing me concern and that is retaining platform independence.

Core is designed to run on Mac and Linux so I want to ensure that the library will also run on Mac and Linux when I'm done. However, in order to get things working I find myself including a lot of non Microsoft.AspNetCore.* nuget packages. (e.g. System.Diagnostics.Process, System.Net.Http, System.Threading.Thread, etc)

Clearly this won't be a problem on Windows but I do wonder if it would cause problems if say, someone targeting Linux was to include a reference to my library?

If it's not a problem then great but if it is then how do I know which nuget packages will be okay in a multi-platform library? (e.g. Is it only the AspNetCore ones that will work cross-platform?)

Upvotes: 0

Views: 69

Answers (1)

bartonjs
bartonjs

Reputation: 33266

The System.* packages are (usually) from https://github.com/dotnet/corefx, and the 99.5% use cases are going to work on macOS and (supported) Linux (distributions) the same as they do on Windows.

There are cases where the System.* packages don't work the way you'd expect them to. Mainly this comes from times that .NET was adding convenience APIs to wrap Windows behavior. So reading a registry key, for example, won't work (and even in a future where the registry API works, it certainly won't be backed by a legitimate hive, so reading obscure values will report key not found). Mostly when an API isn't going to work on Linux/macOS it'll throw a PlatformNotSupportedException, instead of producing some sort of unexpected/wrong result.

So, as long as what you're doing doesn't feel specifically "Windows-y", everything from a netstandard* or netcoreapp* RID should Just Work. And if it doesn't, you can always file an issue at the corefx github project.

Upvotes: 1

Related Questions