7

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

Quango
  • 12,338
  • 6
  • 48
  • 83
  • Could [this GitHub issue](https://github.com/dotnet/standard/issues/481) be what you are encountering? – Frank Fajardo Mar 30 '18 at 08:37
  • 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.. – Quango Mar 30 '18 at 11:33
  • 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. – McGuireV10 Mar 30 '18 at 11:33
  • 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. – McGuireV10 Mar 30 '18 at 11:42
  • @McGuireV10 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 – Quango Mar 30 '18 at 11:54
  • 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.) – McGuireV10 Mar 30 '18 at 11:59
  • 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 – Quango Mar 30 '18 at 12:16
  • @McGuireV10 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. – Quango Mar 30 '18 at 13:09
  • Which do you use, `packages.config` or package references? – Lex Li Apr 03 '18 at 19:40
  • I use `packages.config` @LexLi – Quango Apr 05 '18 at 07:18
  • @Quango the earlier you migrate to package references, the better you get away from such issues (not all but most). – Lex Li Apr 05 '18 at 13:08
  • @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. – Quango May 03 '18 at 09:16
  • JS/TS dependencies should move away from NuGet, https://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx Visual Studio has supported the typical tooling since 2014. – Lex Li May 03 '18 at 09:20
  • 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. – Quango May 03 '18 at 09:24
  • 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 – Quango May 03 '18 at 09:28

4 Answers4

9

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.

Quango
  • 12,338
  • 6
  • 48
  • 83
6

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.

Alex Ghiondea - MSFT
  • 3,182
  • 1
  • 8
  • 11
  • 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.. – Quango Apr 05 '18 at 07:22
  • 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 (https://github.com/dotnet/corefx/issues/28833) – Alex Ghiondea - MSFT Apr 05 '18 at 19:48
  • Thanks @alex-ghiondea I've found that rewriting my `.csproj` file to the new format and using `` along with `net471` removes the issues (although it's more work) – Quango Apr 06 '18 at 07:51
  • Thanks for letting me know @Quango! Glad it addressed your issue! – Alex Ghiondea - MSFT Apr 09 '18 at 02:32
  • 2
    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 – Quango May 03 '18 at 09:11
  • 1
    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 – Quango May 03 '18 at 09:18
  • 1
    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. – Alex Ghiondea - MSFT May 03 '18 at 18:01
  • 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 – Quango May 03 '18 at 18:02
  • 2
    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 – Alex Ghiondea - MSFT May 04 '18 at 13:37
  • 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. – Quango May 04 '18 at 14:02
  • I am glad to hear that eventually everything works! Please email me if you run into issues with this in the future. – Alex Ghiondea - MSFT May 04 '18 at 17:45
  • .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. – BowserKingKoopa May 05 '18 at 02:08
  • @BrowserKingKoopa I would be interested to debug your scenario. Could you file an issue here for us to investigate: https://GitHub.com/Microsoft/dotnet or share a repro solution? – Alex Ghiondea - MSFT May 05 '18 at 02:53
1

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?

Nikita Makarov
  • 11
  • 1
1

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.

RichS
  • 3,097
  • 30
  • 26