Microsoft has launched .NET Standard in recent years to standardize and unify the APIs of target platforms such as .NET Framework, .NET Core, and Xamarin, which greatly facilitates the work of class library writers. Simply put, when class library writers publish libraries, they only need to publish based on .NET Standard, and the programs they write can run on all target platforms.
.NET Standard is a standard, as long as the platform that conforms to this standard can run programs built on this standard API.
It feels good to use, but there are some pitfalls in actual use. For example, this common FileNotFoundException, when there is such a situation, often occurs:
The target platform of the main program is a specific platform (not .NET Standard, such as .NET Framework 4.0), and then in order to introduce new features, the Framework is upgraded to 4.6.1, and it references a .NET Standard class library , as it happens, this class library also references other packages. (That is, the form of passing reference A->B->C, where A is the .NET Framework program, B is the nuget package, and C is the nuget package referenced by B.) In this case, if F5 starts the program, a FileNotFoundException will be reported .
Test Conditions
Visual Studio 2015 Community
Test Package: UnifiedConfig v1.1.6
Prompt not found System.IO.FileSystem. At first glance, it feels like a simple reference error, but the unifiedconfig package has already referenced this project normally, and VS can help us deal with the reference problem normally. Go to the file output path and find that the corresponding package is not copied correctly. Manually copy it from the package folder and the problem is solved.
The reason is this cross-platform. Due to pass-by-reference, B cannot determine which target platform's package to copy to A's output path. When the program is upgraded from an old Framework, the old version of the project file does not handle this problem well with .NET Standard. But it is not a solution for us to copy one by one manually. The solution is given below.
solution:
- The most straightforward solution, modifying the .csproj file of the main project, will be
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>added to the first PropertyGroup - If that doesn't work, add
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
or
- In Tools->nuget Package Manager->Package Management->Default Package Management Format, change from Packages.config to PackageReference.
postscript
I remember that this bug still existed in the early version of visual studio 2017. After the upgrade, the version of visual studio 2017 15.6.4 tested the new project, and there was no such problem. And the default generated .csproj file based on Framework 4.5.2 and above has added <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>this configuration. However, when the old version of the project refers to the .NET Standard class library, this problem often occurs. At this time, we need to manually add the configuration project.