Referencing .NET Standard Assemblies from both .NET Core and .NET Framework
I like getting great questions in email but I LOVE getting great questions in email with a complete and clear code repro (reproduction) that's in a git somewhere. Then I can just clone, build (many many bonus points for a clean build) and check out the bug.
I got a great .NET Core question and repro here https://github.com/ScarlettCode/Example. I forked it, fixed it, and submitted a PR. Here's the question and issue and today's fix.
The project has a C# library project (an assembly) that is written to the .NET Standard 2.0. You'll recall that the .NET Standard isn't a runtime or a library in itself, but rather an interface. They are saying that this library will work anywhere that the .NET Standard is supported, like Linux, Mac, and Windows.
Here's that main .NET Standard Library called "Example.Data" written in C#.
Then he had:
- Windows Forms (WinForms) application in VB.NET using .NET "full" Framework 4.6
- Console Application also using .NET Framework 4.6
- Console Application using .NET Core 2.0
Each of these apps is referring to the Example.Data library. The Example.Data library then pulls in a database access library in the form of Microsoft.EntityFrameworkCore.InMemory via NuGet.
WinForms app -> Data Access library -> Some other library. A->B->C where B and C are packages from NuGet.
The .NET Core console builds and runs great. However, when the other projects are run you get this error:
Can't load
Could not load file or assembly
'Microsoft.EntityFrameworkCore, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=adb9793829ddae60'
or one of its dependencies. The system cannot find
the file specified.
Pretty low level error, right? First thing is to check the bin folder (the results of the compile) for a project that doesn't run. Looks like there's no Microsoft.EntityFrameworkCore there. Why not? It's assembly "C" downstream of "A" and "B". EntityFramework's assembly is referred to by the Example.Data assembly...but why didn't it get copied in?
The "full" Framework projects are using the older .csproj format and by default, they use package.config to manage dependencies. The newer projects can reference Packages as first-class references. So we need to tell ALL projects in this solution to manage and restore their packages as "PackageReferences."
I can open up the .csproj file for the Framework projects and add this line within the first <PropertyGroup> like this to change the restore style:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
As Oren wisely says:
"Using .NET Standard requires you to use
PackageReference
to eliminate the pain of “lots of packages” as well as properly handle transitive dependencies. While you may be able to use .NET Standard withoutPackageReference
, I wouldn’t recommend it."
I can also change the default within VS's Package Management options here in this dialog.
Hope this helps.
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.
About Newsletter
In fact given this issue why not make package reference the default format going forward? Presume there is some kind of backwards compatibility thing, but would there be no way for MS to "upgrade" the project to make it work?
I will try to produce a reproducible example of these at some point.
Hopefully this will all be fixed once this uservoice is completed to give the new csproj sugar to all .net projects.
Talking of A->B->C, I've raised a nuget issue that highlights a risk of runtime exceptions with the new transitive references.
At present, package references are supported in Visual Studio 2017 only, for .NET Core projects, .NET Standard projects, and UWP projects targeting Windows 10 Build 15063 (Creators Update).
I guess it's just growing pains.
When is VB coming to asp.net core? A little under a year ago at AngleBrackets in Vegas, I asked Scott Hunter directly if I should learn C# and he told me point blank that VB was coming to .NET core / ASP.NET core. Now that 2.0 is out I'm wondering if I should still be holding my breath...
I must admit, what I'm currently seeing in the RC2 tooling is kind of disappointing =( So... is there a new estimation on when we can expect .NET Framework -> .NET Core project references to start working properly?
Create admin panels in clicks without knowledge of Programming
Matt
1) If you change the Default package management format to PackageReference, do you need to manually add <RestoreProjectStyle>PackageReference</RestoreProjectStyle> to every project?
2) As Mark Adamson has pointed out, the documentation seems to indicate that PackageReference is NOT supported for "legacy" .NET framework projects. Is this still the case, or has this OFFICIALLY changed in one of the recent VS 2017 updates?
Thanks.
If this indeed works it'll indeed be a time-saver.
Found this article amd tried it out, specifically the nuget package format option.
But I still have no intellisense from my netstd 2.0 projects just ???.
Plan B. Use the netstd 2.0 project as a base. Create a 4.7 and core lib to shadow the std lib. Add the contents of the std lib to the shadows as links.
At last in my core and fx apps/libs I have intellisense.
Once MS sort out intellisense then its just a question of deleting the shadow projects. So frustrating that their quality control is not good enough.
It appears this was down to Resharper not MS. The Resharper upgrade released on 24th August fixes this issue.
.NET Standard is a specification, not an implementation
https://weblog.west-wind.com/posts/2016/Nov/23/NET-Standard-20-Making-Sense-of-NET-Again
Comments are closed.