Unity .net Standard 2.1

[Cinda People]

Igot an interesting email today. The author said "I have a problem consuming a .net core class library in a winforms project and can't seem to find a solution." This was interesting for a few reasons. First, it's solvable, second, it's common, and third, it's a good opportunity to clear a few things up with a good example.

To start, I emailed back with "precision questioning." I needed to assert my assumptions and get a few very specific details to make sure this was, in fact, possible. I said. "What library are you trying to use? What versions of each side (core and winforms)? What VS version?"

.NET is this big name. It's the name for the whole ecosystem, but it's overloaded in such a way that someone can say "I'm using .NET" and you only have a general idea of what that means. Are you using it on mobile? in docker? on windows?

All of these runtimes are .NET. If you learn C# or F# or VB, you're a .NET Programmer. If you do a little research and google around you can write code for Windows, Mac, Linux, Xbox, Playstation, Raspberry Pi, Android, iOS, and on and on. You can run apps on Azure, GCP, AWS - anywhere.

.NET Standard isn't a runtime. It's not something you can install. It's not an "instance of .NET." .NET Standard is an interface - a versioned list of APIs that you can call. Each newer version of .NET Standard adds more APIs but leaves older platforms/operating systems behind.

The runtimes then implement this standard. If someone comes out with a new .NET that runs on a device I've never heard of, BUT it "implements .NET Standard" then I just learned I can write code for it. I can even use my existing .NET Standard libraries. You can see the full spread of .NET Standard versions to supported runtimes in this table.

Now, you could target a runtime - a specific .NET - or you can be more flexible and target .NET Standard. Why lock yourself down to a single operating system or specific version of .NET? Why not target a list of APIs that are supported on a ton of platforms?

When you make a new library in Visual Studio 2017 you get these choices. If you're making a brand new library that you might want to use in more than one place, you'll almost always want to choose .NET Standard.

You can check out .NET Standard 1.6, for example, and see all the namespaces and methods it supports. It works on Windows 10, .NET Framework 4.6.1 and more. If you need to make a library that works on Windows 8 or an older .NET Framework like 4.5, you'll need to choose a lower .NET Standard version. The table of supported platforms is here.

From the docs - When choosing a .NET Standard version, you should consider this trade-off: The higher the version, the more APIs are available to you. The lower the version, the more platforms implement it. In general, we recommend you to target the lowest version of .NET Standard possible. The goal here is reuse. You can also check out the Portability Analyzer and run it on your existing libraries to see if the APIs you need are available.

Sponsor: Big thanks to Raygun! Don't rely on your users to report the problems they experience. Automatically detect, diagnose and understand the root cause of errors, crashes and performance issues in your web and mobile apps. Learn more. About Scott Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

During the building pipeline, Unity will convert all references to netstandard.dll into final references such as mscorlib.dll, resulting in original codeThe reference relationship is very different from the final reference relationship. This difference will cause the command under Generate/All/* to run incorrectly. At the same time due toThe hot update dll compiled by the HybridCLR/CompileDll/* command still references netstandard instead of the final mscorlib and other programs.set, causing an error that the type in netstandard cannot be found when loading and running the hot update dll. Therefore, HybridCLR requires the use of Net Framework by defaultAPI Level.

Some projects originally worked on the .net standard Api Level. In order to be able to work normally after being connected to HybridCLR, some migration work needs to be performed.Fortunately, these tasks are one-time only.

If you can directly find the .Net Framework-based version of the external dll, just replace the dll corresponding to the project. If not found,Then you can use Unity's building pipeline to generate the final aot dll based on .Net Framework, and generate the dll's.Net Framework version. The specific operation is as follows:

3a8082e126