Scott Hanselman

Referencing .NET Standard Assemblies from both .NET Core and .NET Framework

August 22, 2017 Comment on this post [25] Posted in DotNetCore | NuGet | Open Source
Sponsored By

Lots of .NET Projects sharing a .NET Standard LibraryI 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 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=,
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:


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 without PackageReference, I wouldn’t recommend it."

I can also change the default within VS's Package Management options here in this dialog.

 <RestoreProjectStyle>PackageReference</RestoreProjectStyle> Default Package management format

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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
August 22, 2017 6:04
Great advice, thank you.
August 22, 2017 10:57
To which version/SKU of Visual Studio does this refer to? I'm assuming VS2015 is out.
August 22, 2017 11:04
This seems like something Visual Studio should be able to figure out and automatically set for you, i.e. if any .NET standard references always use package reference format and don't allow it to be changed.

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?
August 22, 2017 15:25
Timely! I just ran into this this weekend while working on porting an open source project to .NET standard. Very helpful. Thanks!
August 22, 2017 16:30
I can't say I'm a big fan of this solution. The support for PackageReference in old style csproj projects seems very flaky last time I tried (with 2017.2). The references would sometimes spontaneously vanish in VS and AssemblyReference tags in nuspecs were sometimes being ignored.

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.
August 22, 2017 16:32
Also note that PackageReference is officially not supported for anything other than .net core, .net standard and UWP according to the microsoft documentation:

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).
August 22, 2017 17:25
I remember the ancient times (2015) when things as simple as assembly references just worked.
August 22, 2017 18:56
I agree with Peter. This should be handled better by VS and I wonder why it's not the default? Mark makes good points too, and I think we all can commiserate with Bryan Slatneer.

I guess it's just growing pains.
August 22, 2017 21:26
@Mark It may only be "officially" supported for those types, but if you change the nugget settings as described, other projects will use it. I did notice that for new projects created under that nuget setting, there is no RestoreProjectStyle tag in the csproj
August 22, 2017 21:37
@Mike I guess the thing is that when I have run into flaky bugs with it, which I have, it's not clear that these can be raised as bugs against NuGet. I tried to comment to ask for clarification on the most recent NuGet blog post but my comment never appeared :(.
August 23, 2017 2:19
Great thing to know. However most of the issues I've found with .NET Core and existing libraries is the build server packaging say on Team City with options like this restoring packages not working, or having to include files in source control from wwwroot due to not being restored as part of build.
August 23, 2017 4:40
And here I thought I was the last VB developer on earth :)

When is VB coming to 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...
August 23, 2017 10:24
The functionality to reference .NET Core projects from the full framework projects was the most important thing I was waiting for in RC2, ever since it was announced at one of community stand-ups. If you consider a scenario of porting parts of a large solution to .NET Core, this is definitely a blocker: you can't really port ~100 projects simultaneously, and you can't do it gradually if the tooling doesn't allow referencing new projects from classic projects (or vice versa).

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
August 23, 2017 13:50
Oh man I just spent an hour this morning fixing this manually by adding all the NuGet references to the full framework project. Then I check my RSS reader and see your fix. Thanks!

August 23, 2017 21:26
This article requires a bit of clarification.

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?

August 23, 2017 23:46
I'll have to double check this with VS 2017.3, because for now, as mentioned by @Mark, it seems very buggy in VS2017.2: I have weird "references" with the nuget icon appearing (and not disappearing even by removing everything related in the csproj; I event wonder if some information is not kept in .vs because it survives cleanup and vs restarts!)...then at runtime, the app complaining it can't load some .NET Standard Lib (the assembly was copied to my bin/debug even though I target .NET 4.6)

If this indeed works it'll indeed be a time-saver.
August 24, 2017 2:52
I'll echo Olivier. Tons of reference wierdness just as he describes. Couldn't get a web api 4.6 sln to consume a netstandard 1.6 nuget after 2 long days of trying. Just doesn't seem ready for prime time. Great idea though. Hope it works eventually.
August 24, 2017 7:58
Thanks for the post, package referencing is a bit confusing on .NET Core.
August 29, 2017 1:11
How would you fix NU1701 warnings? Package was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
August 31, 2017 4:15
Hi, this issue drove me crazy a few weeks ago. I eventually found the solution. This article would have save me a few hours. I hope it does for other people. Thanks for posting!
August 31, 2017 21:38
While converting a solution to netstd 2.0 from 1.6 I had almost reached the stage of giving up.

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.

September 01, 2017 15:38
Re my previous concerning the failure of intellisense.

It appears this was down to Resharper not MS. The Resharper upgrade released on 24th August fixes this issue.
September 02, 2017 14:27
There's an announcement about this now and some listed workarounds:
September 05, 2017 21:04
So that's what MSFT made out of VS/.Net: We have to edit project files manually to add references in a way they actually work.
September 06, 2017 2:14
Confused with .NET Standard, Core, Full Framework, ... versions ...

.NET Standard is a specification, not an implementation

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.