Adding .NET Standard libraries to 4.7.1 lib adds loads of references, some broken

Question

As I need to import a library targeting .NET Standard 2, I had upgraded my library to .NET 4.7.1, as I understood from this MS video that should avoid this issue: https://www.youtube.com/watch?v=u67Eu_IgEMs

However, adding .NET standard now results in dozens of System.xxx references, rather than a single reference to .NET Standard (as per the video).

Worse still, several of the references have been added but the underlying file appears to be missing generating warnings, e.g. Warning The referenced component 'Microsoft.Win32.Primitives' could not be found. Warning The referenced component 'System.IO.FileSystem' could not be found. Warning The referenced component 'System.Security.Cryptography.X509Certificates' could not be found. Warning The referenced component 'System.Globalization.Calendars' could not be found.
Warning The referenced component 'System.Security.Cryptography.Encoding' could not be found. Warning The referenced component 'System.Security.Cryptography.Primitives' could not be found. Warning The referenced component 'System.IO.Compression.ZipFile' could not be found. Warning The referenced component 'System.Console' could not be found. I even re-created the demo project in video and got the same result - no single reference to .NET Standard, lots of DLL references instead.

I've tried a NUGET update-package -reinstall and downgraded and upgraded to .NET standard 2.0 and 2.0.1 as well

Niphablepsia

Could this GitHub issue be what you are encountering? – Jason

Not sure it is @FrankFajardo but thanks for the pointer. It refers to 4.6.1 which I know does not support netstandard 2.0. I tried creating the demo application in the MS video (a console app referencing a .netstd 2 library, and got a similar result - so I think it must be an issue with netstd support.. – Niphablepsia

There is nothing to "reference" relating to .NET Standard, it is a "target." A library target just declares its API compatibility. Therefore it isn't clear what you're trying to do or asking about. – Yenyenisei

Also, the missing items you list are .NET Framework (Windows-specific) so it wouldn't be possible for a .NET Standard library to pull in those dependencies. – Yenyenisei

@Yenyenisei I'm referencing a library that has netstandard as the target, from a library targeting 4.7.1.- that should mean it doesn't create loads of shim libs, but it doesn't – Niphablepsia

Ah, I see. 4.7.1 shouldn't require all the individual DLLs, so I assume you mean it does create the shims? (You wrote "doesn't" twice, above.) – Yenyenisei

Yes wasn’t proofreading my reply thx .. it does create them. I’ve manually deleted the broken refs for now, although it’s rather tedious- thx for the help – Niphablepsia

@Yenyenisei the missing refs were added by Visual Studo when I added a reference to .netstandard 2, not by me. So it's doubly annoying that they're all broken. – Niphablepsia

Which do you use, packages.config or package references? – Durand

I use packages.config @LexLi – Niphablepsia

@Niphablepsia the earlier you migrate to package references, the better you get away from such issues (not all but most). – Durand

@LexLi I investigated migrating away from packages.config but this then broke my ASP.NET application because packageReference does not support older Content packages - like JQuery or Bootstrap or all my TypeScript definition files. I tried to migrate but it just caused even more problems. The new approaches are nice but backward compatibility is pretty much awful. – Niphablepsia

JS/TS dependencies should move away from NuGet, hanselman.com/blog/… Visual Studio has supported the typical tooling since 2014. – Durand

Thanks @lex-li, I know and that's several days work to fix and make it work, so it's not a fix, more like a rewrite. – Niphablepsia

Right now I'm trying to figure out which approach to take so I can definitely fix my app which is totally broken right now. At present I'm thinking scrap .NET Standard, remove it completely and revert – Niphablepsia

Answer 1

The answer I'm creating for my own question is:

Does your .NET Framework project use packages.config ? If it does, DO NOT reference .NET Standard libraries. The package/reference/binding-redirect in VS 2017 is horribly broken if you introduce .NET Standard. Trying to fix it will cause more problems (I've wasted several days trying). Expect to have assemblies which don't load despite being present, lots of warnings and a broken app.

If you use System.Net.Http, plan on spending several days in Google and GitHub issues trying to get that to work.

If you are able to upgrade to packageReferences, this should fix the problem. But if your project contains packages that import content, like JQuery or Bootstrap be aware that these no longer work and you'll instead spend more time trying to fix those references and migrate to npm or bower, along with fixing TypeScript compilation too. No thanks.

Ideally you'd be using the 2017 csproj format but that's not compatible with WinForms, ASP.NET or Windows Services - so tough if you've got a legacy project.

Niphablepsia

Answer 2

Because of some issues with the implementation of the .NET Standard 2.0 support on .NET Framework 4.7.1, additional files are required to be deployed to your bin folder.

This issue is described as a known issue here.

The number of files copied to the output folder will be 0 when you are targeting or running on .NET Framework 4.7.2.

Please also make sure you are using the latest Visual Studio (at least version 15.6.3) because some of the changes required to make this scenario work are available there.

Thirzia

Thanks Alex. Yes I'm using VS 15.6.4. The known issue doesn't explain why I'm getting broken references though (although it might be related). Weirdly I upgrade a vb.net library to 4.7.1 and no reference errors there..! The user experience when mixing Standard with Framework really needs work.. – Niphablepsia

Are you building an ASP.NET application? Are you getting reference assemblies instead of regular assemblies deployed? If yes, can you share a solution (or a build log) that shows the problem? We are aware of issues in the ASP.NET space (github.com/dotnet/corefx/issues/28833) – Thirzia

Thanks @alex-ghiondea I've found that rewriting my .csproj file to the new format and using <Project Sdk="Microsoft.NET.Sdk"> along with <TargetFramework>net471</TargetFramework> removes the issues (although it's more work) – Niphablepsia

Thanks for letting me know @Quango! Glad it addressed your issue! – Thirzia

I've unmarked this as the answer. Basically I'm finding NET Standard compatability with Framework anything an absolute nightmare of errors, warnings, binding redirects and more. I've wasted a week trying to fix errors, upgrade projects, downgrade projects etc. I think my conclusion is that .NET Standard is fine for .NET Core, and should be avoided like the plague if you have a Framework app – Niphablepsia

Oh, and before you say "4.7.2" I tried upgrading to that now it's released and it's even more broken. I now have 2012 errors due to libraries not loading and 2691 warnings. Nice – Niphablepsia

I am sorry to hear that this does not address your issue. Based on my understanding, .NET Framework 4.7.2 should address your issues. If it does not I would really want to know why it doesn't and see what can be done to fix it. – Thirzia

Thanks, I’m still trying to find a solution that doesn’t cause yet more issues, so will get back to you if it doesn’t t work – Niphablepsia

Feel free to reach out directly to me (# ghiondea [d_o_t] alexandru [a__t] microsoft.com #). I would like to understand why you are still seeing issues with .NET Framework 4.7.2 – Thirzia

I've bitten the bullet and migrated the solution to packageReference style. This has broken every package that has the old ContentFiles format (most of them) so I had to re-install scripts, css, fonts etc. manually. It has finally fixed the errors, so my somewhat salty answer to my own question still stands - NET std + package.config is best avoided. I've not yet upgraded to 4.7.2 as it seems to be happy now packageReferences are present. If I get any issues with 4.7.2 I'll email you. – Niphablepsia

I am glad to hear that eventually everything works! Please email me if you run into issues with this in the future. – Thirzia

.NET 4.7.2 made things worse for me. Now I have broken references to dlls pointed at my c:\users\my-user folder. I can delete them but they're back next time I open the project. I can't migrate to packageReference because WebJob deployment doesn't work with packageReference. – Holierthanthou

@BrowserKingKoopa I would be interested to debug your scenario. Could you file an issue here for us to investigate: GitHub.com/Microsoft/dotnet or share a repro solution? – Thirzia

Answer 3

I had an absolutely the same issue. I was trying to install Microsoft.Azure.ServiceBus package on the empty console .NET Framework 4.7.1 project and got all these broken references.

As far as I understood the root cause is https://github.com/dotnet/standard/issues/567 and the possible workaround described here https://github.com/dotnet/corefx/issues/29622#issuecomment-396753264

So I just replaced broken references like

<Reference Include="System.Security.Cryptography.Primitives, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Security.Cryptography.Primitives.4.3.0\lib\net46\System.Security.Cryptography.Primitives.dll</HintPath>
</Reference>

in my .csproj file to

<Reference Include="System.Security.Cryptography.Primitives"/>

and it had worked because this assembly is the part of .NET Framework 4.7.1. Also I deleted all binding redirects from the .config file regarding the broken references.

Also, I've found an interesting fact. There was a reference

<Reference Include="System.Runtime.Serialization.Primitives, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Runtime.Serialization.Primitives.4.3.0\lib\net46\System.Runtime.Serialization.Primitives.dll</HintPath>
</Reference>

and it was not broken, because this assembly exists in the .../MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib folder. So I wonder, could it be the problem of MS build?

Deneb

Answer 4

FWIW, I was using Visual Studio 15.7.5, and was manually fixing up all of my binding redirects (to remove them). However, I noticed that my colleague had Visual Studio 15.9.4 and on the project properties screen there is now a 'Auto generate binding redirects'. I'd previously set this in the csproj manually. But, updating to VS 15.9.4 and re-building the projects got rid of all of the binding redirects for me.

Embry