5

I have a desktop application and a simple class library that targets the .Net framework 4.6.2. Recently I noticed that when I update my nuget packages in VS 2017 (15.6.3), one of them started pulling in the some newer netstandard2.0 assemblies.

I'm eager to build netstandard libraries some day. But for now I'd prefer it if the corresponding PCL (available within the same nuget package) would be introduced into my project as a dependency instead of the netstandard assembly. The nuget PCL assembly which I'm after targets "portable-net45+win8+wp8+wpa81".

The reason I don't want a netstandard2.0 assembly is because it causes a bunch of shim assemblies to appear in the output directory and this is overkill given that my application class library itself doesn't target netstandard2.0. Another thing that happens is VS starts generating a bunch of version conflicts (warnings in compiler output) for unrelated packages like System.ValueTuple. This appears to be shim-related as well (the shims are probably coming from the path C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib)

Below is a sample of the version conflicts that I've started seeing.

Encountered conflict between 'Reference:System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL' and 'Reference:System.ValueTuple'. Choosing 'Reference:System.ValueTuple' because file version '4.6.26011.1' is greater than '4.6.25519.3'.

I expect these are just warnings, albeit very scary ones. I believe these are just file version problems (not related to assembly versions), and don't think they will result in any need for binding redirects. Even so, I'd be much happier to go back to my PCL's again and avoid all of this stuff. I think I'll be more eager to use and build netstandard assemblies once the .Net Framework 4.7.2 is released.

I'm using the old-school csproj format and packages.config for nuget. The nuget dependency that seems to bring in the netstandard2.0 bits is System.Composition.

System.Composition  1.1.0
System.Composition.AttributedModel  1.1.0
System.Composition.Convention   1.1.0
System.Composition.Hosting  1.1.0
System.Composition.Runtime  1.1.0
System.Composition.TypedParts   1.1.0
System.ValueTuple   4.4.0

Hope this is clear. My workaround at this time is to create another class library that targets .Net 4.5, introduce the System.Composition nuget dependency, run update-package, and then copy/paste the packages references from the .Net 4.5 csproj to the .Net 4.6.2 project. Then I have to remember to avoid updating my packages on that .Net 4.6.2 project or it will overwrite my references to the PCL assemblies.

I'd greatly appreciate any help. I spent a couple hours playing with nuget update commands and haven't found the trick to avoiding netstandard yet. The closest I got was to use "TargetFrameworks" in the csproj instead of "TargetFrameworkVersion" but ran into trouble with that as well.

David Beavon
  • 1,141
  • 9
  • 16
  • 1
    use old package.config instead of PackageReference here you can set the path in the csproj file to the pcl version. – magicandre1981 Mar 27 '18 at 15:01
  • @magicandre1981 - Yes, that is basically the workaround I described above. I use the nuget update-package on a project for 4.5; and this composes the correct paths that I really wanted in the first place. Then I just copy the results from one csproj to the other. – David Beavon Mar 30 '18 at 16:24
  • with the new way you loose the options to configure the paths. use the old way until package reference gives an option to specify the preferred DLL to load. – magicandre1981 Mar 30 '18 at 16:37
  • I think you are telling me that even the old way involves manual edits to the "hint path" in the csproj. These manual edits must be performed after including the nuget reference. This is not ideal because, when I subsequently run nuget commands in the future, it will overwrite all of the manual edits I had made to hint paths. I want a solution that is less fragile than that. However if you think that editing the hint path manually is the only way to point a project at the PCL assemblies, then I suppose I can accept this as the answer. – David Beavon Apr 02 '18 at 22:41
  • I think that editing is currently the only way. try it and see if it works or not. if you use a source versioning control system (SVN, Git, TFS) you can track each change in detail. – magicandre1981 Apr 03 '18 at 15:20

2 Answers2

1

When using nuget packages is there a way to avoid netstandard assemblies in favor of PCL?

This is a known issue for .net 4.6.2 and 4.7.1, which needs a few of these system.* assemblies since there is a bug in 4.7.1, when you update some nuget packages to the latest version, some of them may pull the newer netstandard2.0 assembly.

If you do not want add those netstandard assemblies, you can targets to .net 4.7.1, but it still needs 12 of them and on .net 4.7.2, the bin folder will only contain your dlls and pdbs. For some more detailed info you can refer to following thread:

net462 referencing netstandard2.0 - can the large number of dlls be avoided?

Actually 4.7.1 will also need a few shims in order to be able to load .netstandard2.0 assemblies, but there are only 12 needed and with the tooling that we are about to release these are the only ones that will be copied to the bin folder. On 4.7.2, compatibility with netstandard will be inbox which means that if you retarget your app for 4.7.2 (once that is avaliable) the bin folder will only contain your dlls and pdbs.

In 4.6.2 you still need the shims there because that is the way your netstandard library will be able to bind to the desktop runtime.

.NET Standard issues on .NET Framework 4.7.1

Hope this helps.

Community
  • 1
  • 1
Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • It is a known issue that the netstandard libraries introduce a bunch of shims into the output. But given the fact that I don't actually want the netstandard libraries in the first place, how do I avoid them altogether in favor of the PCL assembly - which would work just as well? I don't know any way to tell nuget to avoid the netstandard assemblies in favor of PCL. Right now I am having to hack into my csproj files and correct the paths that are produced from the nuget update-package command. – David Beavon Mar 30 '18 at 16:30
  • 1
    I'm using 4.7.2 but still having the same problem – cscmh99 Feb 19 '19 at 03:23
-1

You should be able to use the PackageTargetFallback msbuild property to specify which asset to use:

https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets#packagetargetfallback

Please let me know if that doesn't work for you.

Alex Ghiondea - MSFT
  • 3,182
  • 1
  • 8
  • 11