We all want to climb on .NET Core for a long time, but something is constantly interfering. For example, nothing can be done when there are not enough important APIs. In version 2.0, the process has been simplified thanks to .NET Standard 2.0 , but that's not all. Well, Microsoft-gods listened to our prayers and delivered 20,000 APIs , available as a single package in NuGet!

Who needs it at all?

In short, everyone needs this. IMHO, the very possibility of dragging your tons of Legacy to the .NET Core is already enough justification for any casualties.

Skeptics, however, need to be reminded that the .NET Core is being sawn specifically for scalable web applications on all reasonable operating systems (GNU / Linux, macOS and Windows), and a more specific document will help you choose between Core and Framework.

How to use it?

First, it is necessary to understand that the deposits of the Legacy themselves will not be raked. There is nothing even to think about grabbing a million classes and dragging them with one button.

Suppose you nakadilu on ASP.NET MVC for Windows-localhost, and you are not fired for this. It’s time to drag it to a true Linux running on Azure! It is better to eat an elephant in pieces, namely:

• Drag and drop everything onto an ASP.NET Core (but continue to hold the .NET Framework as the target platform);
• Crawl to .NET Core (but continue to use Windows);
• Jump to GNU / Linux;
• Run on Azure.

It is clear that this great plan should not be approached as the construction of communism, but sensibly. For example, if you want to show the big bosses launch on Azure - this is the place to start. If you think laziness (for example, I’m exactly lazy), our leaders wrote a special training manual for gaining faith in the .NET Core .

In short, you need to uncover NuGet, install the Microsoft.Windows.Compatibility package , and find that a huge pile of different useful and unnecessary APIs have become available.

It is important to understand that this very Microsoft.Windows.Compatibility is still furiously finishing, so that all the amazing stories are just ahead of us.

Now we have the following set of nishtyaks (the table turned out to be huge; the man reading this post from the mobile: please forgive me!):

And what to do with the Windows-only API?

Suffer, what.

For tankers. Not all APIs are equally portable. If you stay on Windows, there are no problems. If you want to join the holiness of Richard Stallman and Tim Cook on GNU / Linux and macOS, respectively, you will have to suffer.

Looking at the label nishtyakov, we see: there are almost half of the Windows-only components. Good Microsoft gods, however, allow you to successfully compile such code under any platform. When trying to use a non-existent feature, we will come across PlatformNotSupportedException in runtime, so all such features will need to be thickly smeared with calls to RuntimeInformation.IsOSPlatform() :

 private static string GetLoggingPath() { // Verify the code is running on Windows. if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { using (var key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam\AssetManagement")) { if (key?.GetValue("LoggingDirectoryPath") is string configuredPath) return configuredPath; } } // This is either not running on Windows or no logging path was configured, // so just use the path for non-roaming user-specific data files. var appDataPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); return Path.Combine(appDataPath, "Fabrikam", "AssetManagement", "Logging"); } 

How to understand which API-scale will work only in Windows? Nobody reads the documentation, right?

Dear my lover of programming copy-paste with StackOverflow! Microsoft - the gods are harsh, but fair, so just a couple of weeks ago, they wrote down the API Analyzer tool . With Roslyn, this tula marks the Windows-only API, and only when the target is set to .NET Core or .NET Standard.

What to do with errors? As mentioned earlier, suffer.

• Delete unported code. Why do I need a feature if it does not run on macOS? :-)
• Diligently refactor code using other, more cross-platform APIs. The benefit of this update brought such a set.
• Arrange checks on the type of OSes in those places where GNU / Linux-specific things happen that are simply not needed in Windows.

In the example from the picture, someone is trying to subtract the settings in the Registry. You can wrap this line in the test, perform it only on Windows. In GNU / Linux, the equivalent of this line will be different, much more painful.

Note that the Windows Compatibility Pack is a meta package. Microsoft was well aware that ordinary people would not be tormented by searching for individual small sachets and would want to switch to a new platform in one leap (subject to the reservations above). However, if you are a thoughtful cool developer, then you can drag out features one by one. Thus, it will be possible to throw out much more dependencies on unnecessary trash.

What's next?

Moral preparing for porting. Install Windows Compatibility Pack . You study nishtyaki, of which there are more than 20 thousand, including EventLog, WMI, Performance Counters, Windows Services and so on.

If you want to make a cross-platform app, you run the API Analyzer. You can pre-cry a little or vapka vodka.

Unfortunately, now .NET Core does not cover the needs of desktop development. Maybe someday this will change. But that's another story.

If you want to learn more about .NET in general and .NET Core in particular, we are waiting for you on DotNext 2018 Piter , which will take place, suddenly, in St. Petersburg. I strongly advise to this confer to try to file something or port to Core so that a pool of questions for the speakers has accumulated.