New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with .NET Standard 2.0 with .NET Framework & NuGet #481

Open
terrajobst opened this Issue Sep 1, 2017 · 144 comments

Comments

Projects
None yet
@terrajobst
Member

terrajobst commented Sep 1, 2017

Summary

We've designed .NET Standard & our tooling so that projects targeting .NET Framework 4.6.1 can consume NuGet packages & projects targeting .NET Standard 2.0 or earlier. Unfortunately, we've seen a few issues around that scenario. The purpose of this document is to summarize the issues, outline our plan on addressing them, and providing workarounds you can deploy with today's state of our tooling.

Symptoms and root cause

The primary symptom is that applications crash with a FileLoadException or a FileNotFoundException. Another symptom is warnings at build time regarding assembly versions. This is due to one or both of the following issues:

  1. Missing binding redirects
  2. Missing binaries that come from indirect NuGet packages

Missing binding redirects

.NET Standard 1.x was based around contracts. Many of these contracts shipped with .NET Framework 4.5 and later. However, different versions of .NET Framework picked up different versions of these contracts, as by-design of contract versioning. As a side effect of marking .NET Framework 4.6.1 as implementing .NET Standard 2.0, some projects will now start picking up binaries built for .NET Standard 1.5 and 1.6 (as opposed to previously where .NET Framework 4.6.1 was considered as implementing .NET Standard 1.4). This results in mismatches of the assembly versions between what was shipped in .NET Framework and what was part of .NET Standard 1.5/1.6.

This can be addressed by binding redirects. As writing them by hand sucks, we added an Automatic Binding Redirect Generation feature in .NET Framework 4.5.1. This feature is opt-in. Unfortunately, it's not enabled based on target framework, but by which target framework was selected when the project was created (as the feature is turned on via an MSBuild property that is conditionally emitted by the template). In practice, this means it's mostly off if you often upgrade existing projects, rather than creating new ones.

Missing binaries

There are two primary flavors of NuGet: packages.config and PackageReference.

  • With packages.config, each project has a config file with a flattened graph of all the NuGet dependencies. The project file in turn has direct links to all the assets. The assets are selected at install time. None of this includes indirect NuGet references coming from referenced projects.

  • With PackageReference each project contains MSBuild PackageReference items. The project file contains no references to any assets as the assets are selected at build time. Package restore will compute the graph of all packages, including indirect NuGet references coming from referenced projects.

The default for .NET Framework projects is packages.config. This ensures more compatibility because PackageReference doesn't support all the features that packages.config did, for example, PowerShell install scripts and content.

The only supported mode for SDK-style projects (.NET Core/.NET Standard) is PackageReference. This means that a .NET Framework project referencing a .NET Standard project ends up crossing the streams between two different NuGet models. When the .NET Standard project references NuGet packages that the .NET Framework project doesn't reference, the application ends up missing all binaries coming from those packages.

Why has this worked before? Because withpackages.config, all dependencies are copied to each project's output folder. MSBuild copies them up from there. With PackageReference, we don't copy the binaries because it relies on the consuming project to see its dependencies and extract the proper asset itself. This allows the consuming project to pick up the right assets for packages that use bait & switch (which many of the .NET packages must do).

Plan

The plan is to address these issues moving forward as follows:

  1. Converge on PackageReference for all project types, including .NET Framework. The short-term plan for (1) is to start blocking project-to-project references in Visual Studio 15.4 that will end up crossing the streams between packages.config and PackageReference. This block is UI only; you can still edit the reference by editing the project by hand. The error message will instruct you to switch the .NET Framework project to PackageReference if you want to reference a .NET Standard project. Referencing .NET Standard binaries or NuGet packages will not require this, it's only about project-to-project references. In later releases, we plan on providing a converter. The challenge is that packages.config has features we can't offer for PackagReference across the board, in particular PowerShell install scripts and content. We'll need good guidance and mitigations, if applicable.

  2. Ensure binding redirects are on by default. Short term, this means we need to fix our target files to make sure we turn on automatic binding redirect generation. However, binding redirects don't work well in all scenarios, when there is no application project (like unit tests or add-ins). We need to work on a plan to bring the regular “higher wins” binding policy without binding redirects. This needs a proposal and proper vetting, but it seems we've reached the point where this is necessary.

Workarounds

Regular .NET Framework projects

  1. Enable automatic binding redirects in the root .NET Framework application.
  2. Make sure your root application project doesn't use packages.config but uses PackageReference for NuGet packages
    • If you currently don't have packages.config, simply add <RestoreProjectStyle>PackageReference</RestoreProjectStyle> to your project file
    • If you currently do have a packages.config, convert the contents to packages references in the project file. The syntax is like this:
      • <PackageReference Include="package-id" Version="package-version" />

ASP.NET web applications and web sites

  1. Web applications and web sites don't support automatic binding redirect generation. In order to resolve binding conflicts, you need to double click the warning in the error list and Visual Studio will add them to your web.config file.
  2. In web application projects, you should enable PackageReference like mentioned above. In web sites, you cannot use PackageReference as there is no project file. In that case, you need to install all NuGet packages into your web site that any of the direct or indirect project references depend on.

Unit tests projects

By default, binding redirects aren't added to class library projects. This is problematic for unit testing projects as they are essentially like apps. So in addition to what's outlined in automatic binding redirects you also need to specify GenerateBindingRedirectsOutputType:

<PropertyGroup>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
@mungojam

This comment has been minimized.

Show comment
Hide comment
@mungojam

mungojam Sep 2, 2017

Thanks for this, things do seem a little unpolished, so it's useful to have some clarity.

Other things that currently make it painful for us to mix .net framework with .net standard are a FileNotFoundException that will make it difficult for us to migrate our internal packages in a safe way: NuGet/Home#5715 and the lack of visibility of indirect packages when switching to PackageReferences: UserVoice to convert all projects to new common project format

mungojam commented Sep 2, 2017

Thanks for this, things do seem a little unpolished, so it's useful to have some clarity.

Other things that currently make it painful for us to mix .net framework with .net standard are a FileNotFoundException that will make it difficult for us to migrate our internal packages in a safe way: NuGet/Home#5715 and the lack of visibility of indirect packages when switching to PackageReferences: UserVoice to convert all projects to new common project format

@mungojam

This comment has been minimized.

Show comment
Hide comment
@mungojam

mungojam Sep 2, 2017

Is it correct that PackageReference is not supported for anything other than .net core, .net standard and UWP? See the 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).

Hopefully that will change in future as it is an option in Visual Studio and is the workaround that you describe.

mungojam commented Sep 2, 2017

Is it correct that PackageReference is not supported for anything other than .net core, .net standard and UWP? See the 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).

Hopefully that will change in future as it is an option in Visual Studio and is the workaround that you describe.

@0x53A

This comment has been minimized.

Show comment
Hide comment
@0x53A

0x53A Sep 2, 2017

Hi @terrajobst, is there a document detailing which scenarios are supported for .NET Framework 4.6.1 and .NET Standard 1.6?

I created a net461 old-sdk project in VS2017.3 and added a .NET Standard 1.6 NuGet. The build automagically copied the required shims to the output, totalling 100 files.

If I open the exact same project in VS2015 and build, the output contains only 4 files, so the shims are missing.


Where do the shims come from, anyway? I was following some earlier discussions, and I know at first they were deployed via a NuGet package. But later discussions talked about some machine-wide installation. What was the final result? What do we need to deploy to a build server to enable this scenario?

0x53A commented Sep 2, 2017

Hi @terrajobst, is there a document detailing which scenarios are supported for .NET Framework 4.6.1 and .NET Standard 1.6?

I created a net461 old-sdk project in VS2017.3 and added a .NET Standard 1.6 NuGet. The build automagically copied the required shims to the output, totalling 100 files.

If I open the exact same project in VS2015 and build, the output contains only 4 files, so the shims are missing.


Where do the shims come from, anyway? I was following some earlier discussions, and I know at first they were deployed via a NuGet package. But later discussions talked about some machine-wide installation. What was the final result? What do we need to deploy to a build server to enable this scenario?

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Sep 3, 2017

Member

@mungojam

Is it correct that PackageReference is not supported for anything other than .net core, .net standard and UWP?

You can use PackageReference in .NET Framework projects, but as I outlined there is a loss in certain features. For instance, if you install packages that rely on PowerShell scripts (for instance, EF6) they will no longer work. Also, packages that require content (i.e. source files that are copied to the consuming project) they will also no work.

@0x53A

Which NuGet package are you consuming? For .NET Standard 1.x, the package is supposed to depend on NETStandard.Library which will bring in the shims.

Member

terrajobst commented Sep 3, 2017

@mungojam

Is it correct that PackageReference is not supported for anything other than .net core, .net standard and UWP?

You can use PackageReference in .NET Framework projects, but as I outlined there is a loss in certain features. For instance, if you install packages that rely on PowerShell scripts (for instance, EF6) they will no longer work. Also, packages that require content (i.e. source files that are copied to the consuming project) they will also no work.

@0x53A

Which NuGet package are you consuming? For .NET Standard 1.x, the package is supposed to depend on NETStandard.Library which will bring in the shims.

@0x53A

This comment has been minimized.

Show comment
Hide comment
@0x53A

0x53A Sep 3, 2017

@terrajobst repro is here: https://github.com/0x53A/n16test

The nupkg was created calling "dotnet pack" on
https://github.com/0x53A/n16test/blob/75fcfdc0d540531c30b805e74bb239e42d13ffea/ns16lib/ns16lib.csproj#L1-L7.

The resulting package looks like this:
image

To reproduce my issue:

  1. open https://github.com/0x53A/n16test/blob/master/net461exe/net461exe/net461exe.sln in VS 2017.3 and build.
  2. note that /bin/ contains 100 files.
  3. clean /bin/, re-open in VS 2015.3 and build
  4. note that /bin/ contains only 4 files.

0x53A commented Sep 3, 2017

@terrajobst repro is here: https://github.com/0x53A/n16test

The nupkg was created calling "dotnet pack" on
https://github.com/0x53A/n16test/blob/75fcfdc0d540531c30b805e74bb239e42d13ffea/ns16lib/ns16lib.csproj#L1-L7.

The resulting package looks like this:
image

To reproduce my issue:

  1. open https://github.com/0x53A/n16test/blob/master/net461exe/net461exe/net461exe.sln in VS 2017.3 and build.
  2. note that /bin/ contains 100 files.
  3. clean /bin/, re-open in VS 2015.3 and build
  4. note that /bin/ contains only 4 files.
@FransBouma

This comment has been minimized.

Show comment
Hide comment
@FransBouma

FransBouma Sep 4, 2017

In vs2015, in a csproj targeting v4.6.2, I wanted to add a reference to Entity Framework Core 2.0, but that failed with this error:

Attempting to gather dependency information for package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' with respect to project 'EF Core 2\NWEFCore2.Persistence', targeting '.NETFramework,Version=v4.6.2'
Gathering dependency information took 0,87 ms
Attempting to resolve dependencies for package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0'
Resolved actions to install package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0'
Retrieving package 'Microsoft.EntityFrameworkCore.SqlServer 2.0.0' from 'nuget.org'.
Install failed. Rolling back...
Package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' does not exist in project 'NWEFCore2.Persistence'
Package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' does not exist in folder 'C:\Myprojects\VS.NET Projects\LLBLGen Pro v5.3\UnitTests\EntityFramework\packages'
Executing nuget actions took 62,07 ms
install-package : Could not install package 'Microsoft.EntityFrameworkCore.SqlServer 2.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6.2', but the package does not contain any assembly references or content fi
les that are compatible with that framework. For more information, contact the package author.
At line:1 char:1
+ install-package Microsoft.EntityFrameworkCore.SqlServer
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

Likely a bug in the Nuget client in 2015 (but I am under the assumption I have the latest version installed), but IMHO this should simply work as .NET 4.6.2 supports .NET standard 2.0

(edit) This does work in vs2017 15.3.x. That's not an excuse to not fix this! Many devs are on 2015 and have no plans to move to 2017 (yet) and as .net standard 2.0 is supported on .net 4.6.2, they should be able to expect this to just work.

I don't know if this is the right location to file this (likely not!), if not please point me to the repo where I should file this, thanks.

FransBouma commented Sep 4, 2017

In vs2015, in a csproj targeting v4.6.2, I wanted to add a reference to Entity Framework Core 2.0, but that failed with this error:

Attempting to gather dependency information for package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' with respect to project 'EF Core 2\NWEFCore2.Persistence', targeting '.NETFramework,Version=v4.6.2'
Gathering dependency information took 0,87 ms
Attempting to resolve dependencies for package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0'
Resolved actions to install package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0'
Retrieving package 'Microsoft.EntityFrameworkCore.SqlServer 2.0.0' from 'nuget.org'.
Install failed. Rolling back...
Package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' does not exist in project 'NWEFCore2.Persistence'
Package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' does not exist in folder 'C:\Myprojects\VS.NET Projects\LLBLGen Pro v5.3\UnitTests\EntityFramework\packages'
Executing nuget actions took 62,07 ms
install-package : Could not install package 'Microsoft.EntityFrameworkCore.SqlServer 2.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6.2', but the package does not contain any assembly references or content fi
les that are compatible with that framework. For more information, contact the package author.
At line:1 char:1
+ install-package Microsoft.EntityFrameworkCore.SqlServer
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

Likely a bug in the Nuget client in 2015 (but I am under the assumption I have the latest version installed), but IMHO this should simply work as .NET 4.6.2 supports .NET standard 2.0

(edit) This does work in vs2017 15.3.x. That's not an excuse to not fix this! Many devs are on 2015 and have no plans to move to 2017 (yet) and as .net standard 2.0 is supported on .net 4.6.2, they should be able to expect this to just work.

I don't know if this is the right location to file this (likely not!), if not please point me to the repo where I should file this, thanks.

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Sep 4, 2017

cc @forki I wonder what impact this has on Paket vis-a-vis automatic binding redirects (Paket has the option to generate BRs on demand based on the dependency graph).

@terrajobst If there's a BR already in the app.config file and you turn on the automatic BR redirection, who wins?

isaacabraham commented Sep 4, 2017

cc @forki I wonder what impact this has on Paket vis-a-vis automatic binding redirects (Paket has the option to generate BRs on demand based on the dependency graph).

@terrajobst If there's a BR already in the app.config file and you turn on the automatic BR redirection, who wins?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2017

@isaacabraham I have no idea. this will bring interesting new problems to us.

forki commented Sep 4, 2017

@isaacabraham I have no idea. this will bring interesting new problems to us.

@FransBouma

This comment has been minimized.

Show comment
Hide comment
@FransBouma

FransBouma Sep 4, 2017

And another problem:

Using EF Core 2.0 in a .NET 4.6.2 project: as soon as you create a DbContext derived type, you'll get this error:

System.IO.FileLoadException : Could not load file or assembly 'System.ValueTuple, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
  Exception doesn't have a stacktrace

Likely caused by the same issue as the ValueTuple containing assembly isn't there. This is in vs2017 15.3.x btw.

Brb, throwing some heavy furniture against the wall screaming.

FransBouma commented Sep 4, 2017

And another problem:

Using EF Core 2.0 in a .NET 4.6.2 project: as soon as you create a DbContext derived type, you'll get this error:

System.IO.FileLoadException : Could not load file or assembly 'System.ValueTuple, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
  Exception doesn't have a stacktrace

Likely caused by the same issue as the ValueTuple containing assembly isn't there. This is in vs2017 15.3.x btw.

Brb, throwing some heavy furniture against the wall screaming.

@0x53A

This comment has been minimized.

Show comment
Hide comment
@0x53A

0x53A commented Sep 4, 2017

@FransBouma This looks familiar: #476 (comment)

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2017

How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?

matthid commented Sep 4, 2017

How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli Sep 4, 2017

Contributor

Note that the binding redirection documentation is missing the critical

<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>

property which is crucial to making "classic" test projects work (as well as libraries loaded via reflection).

Contributor

dasMulli commented Sep 4, 2017

Note that the binding redirection documentation is missing the critical

<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>

property which is crucial to making "classic" test projects work (as well as libraries loaded via reflection).

@FransBouma

This comment has been minimized.

Show comment
Hide comment
@FransBouma

FransBouma Sep 4, 2017

@0x53A yes, I think that's similar. The bindingredirect however kills nunit for some reason (the test is now simply not seen by it and not run).

@dasMulli Thanks for that, but I am at a loss where to add that... adding it to the bindingredirect nor the csproj etc. does make nunit work again.

And here I am hoping that after weeks of fighting with MS pre-alpha quality tooling (Where's the QA testing? We paid for this software!), this week would go smoothly. Nope

(edit) fsck it, converting to new csproj format, perhaps that gives some results.

(edit) for ref: dotnet/sdk#1070 adding the 2 redirects made nunit work again. With the new csproj format the bindingredirect isn't needed, the valuetuple issue isn't popping up, but the attribute referred by @dasMulli are required to make things work.

Man... one could start wondering what 'alpha' quality means these days if 'RTM' is this quality.

FransBouma commented Sep 4, 2017

@0x53A yes, I think that's similar. The bindingredirect however kills nunit for some reason (the test is now simply not seen by it and not run).

@dasMulli Thanks for that, but I am at a loss where to add that... adding it to the bindingredirect nor the csproj etc. does make nunit work again.

And here I am hoping that after weeks of fighting with MS pre-alpha quality tooling (Where's the QA testing? We paid for this software!), this week would go smoothly. Nope

(edit) fsck it, converting to new csproj format, perhaps that gives some results.

(edit) for ref: dotnet/sdk#1070 adding the 2 redirects made nunit work again. With the new csproj format the bindingredirect isn't needed, the valuetuple issue isn't popping up, but the attribute referred by @dasMulli are required to make things work.

Man... one could start wondering what 'alpha' quality means these days if 'RTM' is this quality.

@aliostad

This comment has been minimized.

Show comment
Hide comment
@aliostad

aliostad Sep 4, 2017

On the announcement, the "primary symptom" link is broken (via @forki )

image

aliostad commented Sep 4, 2017

On the announcement, the "primary symptom" link is broken (via @forki )

image

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli Sep 4, 2017

Contributor

@FransBouma I wasn't directly referring to your problem but rather pointing out that the official documentation and announcement issue lacks this information (cc @terrajobst).

For VS 2015, there is an additional extension to install for .NET Standard 2.0 support - When using NuGet 3.6.0, it will print out the link. However, I've tried it but it is currently broken anyway for most scenarios: dotnet/sdk#1539

Contributor

dasMulli commented Sep 4, 2017

@FransBouma I wasn't directly referring to your problem but rather pointing out that the official documentation and announcement issue lacks this information (cc @terrajobst).

For VS 2015, there is an additional extension to install for .NET Standard 2.0 support - When using NuGet 3.6.0, it will print out the link. However, I've tried it but it is currently broken anyway for most scenarios: dotnet/sdk#1539

@FransBouma

This comment has been minimized.

Show comment
Hide comment
@FransBouma

FransBouma Sep 4, 2017

@dasMulli oh sorry about that, but in any case it helped me a lot, so thanks for your input :)
Yeah I think 2015 is a lost cause at the moment. Thanks for referring to the nuget link, I didn't know I had to install a separate extension. In my 2015 installation it didn't mention that.

FransBouma commented Sep 4, 2017

@dasMulli oh sorry about that, but in any case it helped me a lot, so thanks for your input :)
Yeah I think 2015 is a lost cause at the moment. Thanks for referring to the nuget link, I didn't know I had to install a separate extension. In my 2015 installation it didn't mention that.

@mariusGundersen

This comment has been minimized.

Show comment
Hide comment
@mariusGundersen

mariusGundersen Sep 4, 2017

When you say

simply add PackageReference to your project file

I'm assuming this means the csproj has to use the VS2017 style csproj, as in, it needs to start with <Project Sdk="Microsoft.NET.Sdk"> and it needs to be built using msbuild 15 or the dotnet cli, right? Only working in Visual Studio is not much use for everyone (and I hope this is the majority) who use CI/CD pipelines. So this means that we can't really use netstandard nugets without converting the csproj file to vs2017 style.

mariusGundersen commented Sep 4, 2017

When you say

simply add PackageReference to your project file

I'm assuming this means the csproj has to use the VS2017 style csproj, as in, it needs to start with <Project Sdk="Microsoft.NET.Sdk"> and it needs to be built using msbuild 15 or the dotnet cli, right? Only working in Visual Studio is not much use for everyone (and I hope this is the majority) who use CI/CD pipelines. So this means that we can't really use netstandard nugets without converting the csproj file to vs2017 style.

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli Sep 4, 2017

Contributor

@mariusGundersen all csproj format ("classic" + "sdk-style") can use PackageReference items since VS 2017 15.2. NuGet tries to detect if there is any <PackageReference> item in the project or if there is a packages.config in the project to determine which "restore style" is to be used.

However, if neither of those are present, the <RestoreProjectStyle> can be set to PackageReference to enable all features of projects using this style. This then enables transitive dependencies from referenced projects also using PackageReference. The "sdk-style" (<Project Sdk="Microsoft.NET.Sdk">) projects already set this by default.

Contributor

dasMulli commented Sep 4, 2017

@mariusGundersen all csproj format ("classic" + "sdk-style") can use PackageReference items since VS 2017 15.2. NuGet tries to detect if there is any <PackageReference> item in the project or if there is a packages.config in the project to determine which "restore style" is to be used.

However, if neither of those are present, the <RestoreProjectStyle> can be set to PackageReference to enable all features of projects using this style. This then enables transitive dependencies from referenced projects also using PackageReference. The "sdk-style" (<Project Sdk="Microsoft.NET.Sdk">) projects already set this by default.

@mariusGundersen

This comment has been minimized.

Show comment
Hide comment
@mariusGundersen

mariusGundersen Sep 4, 2017

So I need to install the latest nuget client on the build server to be able to use <PackageReference>? And I guess that as long as the project file is still classic style it needs the <Reference> and <HintPath> to work?

mariusGundersen commented Sep 4, 2017

So I need to install the latest nuget client on the build server to be able to use <PackageReference>? And I guess that as long as the project file is still classic style it needs the <Reference> and <HintPath> to work?

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Sep 4, 2017

Member

@0x53A

Thanks for the repo, we'll take a look.

@FransBouma

Make sure you have the latest NuGet client for VS 2015. It looks your client doesn't know that .NET Framework 4.6.1 supports .NET Standard 2.0. If the error persist after upgrading, I'd file a bug in the NuGet org (https://github.com/NuGet/Home/issues/new).

@isaacabraham and @forki

I wonder what impact this has on Paket vis-a-vis automatic binding redirects (Paket has the option to generate BRs on demand based on the dependency graph).

My recommendation is: don't add BR via a package manager. We've worked with the NuGet folks to disable their BR generation as well. It should be generated during build, because that's the only place where all the necessary context is available. If anything, I'd consider making Paket add the AutoGenerateBindingRedirects property to the project file if it isn't set already.

Eventually, I'd like the desktop binder to do the right thing here, but we'll see whether we can actually pull this off...

If there's a BR already in the app.config file and you turn on the automatic BR redirection, who wins?

The automatic binding redirect feature will attempt to merge them. Generally speaking, manual BRs will be honored and win.

@matthid

How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?

What would you do differently from what I outlined in the plan above? To me, the plan is precisely what you're asking for.

@dasMulli

Excellent point. Fixed.

@mariusGundersen

When you say

simply add PackageReference to your project file

I'm assuming this means the csproj has to use the VS2017 style csproj

No, you can use non-SDK style projects with PackageReference.

Member

terrajobst commented Sep 4, 2017

@0x53A

Thanks for the repo, we'll take a look.

@FransBouma

Make sure you have the latest NuGet client for VS 2015. It looks your client doesn't know that .NET Framework 4.6.1 supports .NET Standard 2.0. If the error persist after upgrading, I'd file a bug in the NuGet org (https://github.com/NuGet/Home/issues/new).

@isaacabraham and @forki

I wonder what impact this has on Paket vis-a-vis automatic binding redirects (Paket has the option to generate BRs on demand based on the dependency graph).

My recommendation is: don't add BR via a package manager. We've worked with the NuGet folks to disable their BR generation as well. It should be generated during build, because that's the only place where all the necessary context is available. If anything, I'd consider making Paket add the AutoGenerateBindingRedirects property to the project file if it isn't set already.

Eventually, I'd like the desktop binder to do the right thing here, but we'll see whether we can actually pull this off...

If there's a BR already in the app.config file and you turn on the automatic BR redirection, who wins?

The automatic binding redirect feature will attempt to merge them. Generally speaking, manual BRs will be honored and win.

@matthid

How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?

What would you do differently from what I outlined in the plan above? To me, the plan is precisely what you're asking for.

@dasMulli

Excellent point. Fixed.

@mariusGundersen

When you say

simply add PackageReference to your project file

I'm assuming this means the csproj has to use the VS2017 style csproj

No, you can use non-SDK style projects with PackageReference.

@scottsauber

This comment has been minimized.

Show comment
Hide comment
@scottsauber

scottsauber Sep 4, 2017

@terrajobst when you say "No, you can use non-SDK style projects with PackageReference" does this mean I can just delete my packages.config and then in my .csproj remove the hint paths and replace with PackageReferences and it'll just work (provided I'm on the correct NuGet version)?

Or is there some other magic you need to do to use PackageReference with non-SDK style projects?

scottsauber commented Sep 4, 2017

@terrajobst when you say "No, you can use non-SDK style projects with PackageReference" does this mean I can just delete my packages.config and then in my .csproj remove the hint paths and replace with PackageReferences and it'll just work (provided I'm on the correct NuGet version)?

Or is there some other magic you need to do to use PackageReference with non-SDK style projects?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2017

forki commented Sep 4, 2017

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2017

@terrajobst

How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?

What would you do differently from what I outlined in the plan above? To me, the plan is precisely what you're asking for.

I appreciate the response. Well yes you are dropping packages.config support. But I meant dropping the compatibility of net461 with netstandard20 from the compatibility table and remove all the special handling around this. This would be the honest way of saying: "Well the runtime did not ship with the proper support for netstandard20 but a future version will". What are the reasons which justify the amount of pain you put everyone through and the amount of effort it generates everywhere (not only internally in Microsoft but also externally like in Paket). There must be really important reasons to have this single compatibility connection but I have no clue what they are.

Could this been fixed with net462 or net463? Maybe I'm missing something here.

matthid commented Sep 4, 2017

@terrajobst

How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?

What would you do differently from what I outlined in the plan above? To me, the plan is precisely what you're asking for.

I appreciate the response. Well yes you are dropping packages.config support. But I meant dropping the compatibility of net461 with netstandard20 from the compatibility table and remove all the special handling around this. This would be the honest way of saying: "Well the runtime did not ship with the proper support for netstandard20 but a future version will". What are the reasons which justify the amount of pain you put everyone through and the amount of effort it generates everywhere (not only internally in Microsoft but also externally like in Paket). There must be really important reasons to have this single compatibility connection but I have no clue what they are.

Could this been fixed with net462 or net463? Maybe I'm missing something here.

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Sep 4, 2017

Member

@scottsauber

when you say "No, you can use non-SDK style projects with PackageReference" does this mean I can just delete my packages.config and then in my .csproj remove the hint paths and replace with PackageReferences and it'll just work (provided I'm on the correct NuGet version)?

Two options: remove the packages.config and convert all package references by hand as explained above. You can also control the default for .NET Framework works via Tools | Options | Package Manager | General.

@matthid

But I meant dropping the compatibility of net461 with netstandard20 from the compatibility table and remove all the special handling around this.

Believe me, no one on my team is keen on on the way the net461 support story has unfolded. In a sense, what you're asking has already been implemented: .NET Framework 4.7.1 will ship with full built-in support of .NET Standard 2.0. The challenge is that (1) it hasn't been shipped yet and (2) many of our customers will not be able to upgrade immediately because the target environment is outside their control. The option was to support it the best we can or can it altogether. Yes, this unfortunately requires jumping through hoops but at least there is something app developers can do. If you fully control the environment, by all means, jump to .NET Framework 4.7.1.

Member

terrajobst commented Sep 4, 2017

@scottsauber

when you say "No, you can use non-SDK style projects with PackageReference" does this mean I can just delete my packages.config and then in my .csproj remove the hint paths and replace with PackageReferences and it'll just work (provided I'm on the correct NuGet version)?

Two options: remove the packages.config and convert all package references by hand as explained above. You can also control the default for .NET Framework works via Tools | Options | Package Manager | General.

@matthid

But I meant dropping the compatibility of net461 with netstandard20 from the compatibility table and remove all the special handling around this.

Believe me, no one on my team is keen on on the way the net461 support story has unfolded. In a sense, what you're asking has already been implemented: .NET Framework 4.7.1 will ship with full built-in support of .NET Standard 2.0. The challenge is that (1) it hasn't been shipped yet and (2) many of our customers will not be able to upgrade immediately because the target environment is outside their control. The option was to support it the best we can or can it altogether. Yes, this unfortunately requires jumping through hoops but at least there is something app developers can do. If you fully control the environment, by all means, jump to .NET Framework 4.7.1.

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Sep 4, 2017

Member

@forki

Actually we often set it to make sure nuget/build does not mess with what we intended (or at least to know when that happens). As double-entry bookkeeping if you will. Now this usecase is basically broken - or in some sense you are basically removing all use cases of the redirects if you make the automatic all the time.

The problem with double bookkeeping is that automatic binding redirect generation has to assume the project owner knows best and has to honor the BRs that are present. I don't know Paket well enough, but with NuGet we had the issue that NuGet assumed that the same package & version will have consistent assembly versions and not generate redirects based on the referenced assemblies but based on whether package versions differed. If Paket gets it right a 100% then there is arguably nothing against it, but I'd also argue nothing in favor of it either. Outside of .NET Framework you already rely on the binding behavior that higher wins. A generated app.config with the right redirects will do the same, so I don't see a reason why a checked in copy with the project is helping. I just think it causes noise and adds potential for conflicts...

Member

terrajobst commented Sep 4, 2017

@forki

Actually we often set it to make sure nuget/build does not mess with what we intended (or at least to know when that happens). As double-entry bookkeeping if you will. Now this usecase is basically broken - or in some sense you are basically removing all use cases of the redirects if you make the automatic all the time.

The problem with double bookkeeping is that automatic binding redirect generation has to assume the project owner knows best and has to honor the BRs that are present. I don't know Paket well enough, but with NuGet we had the issue that NuGet assumed that the same package & version will have consistent assembly versions and not generate redirects based on the referenced assemblies but based on whether package versions differed. If Paket gets it right a 100% then there is arguably nothing against it, but I'd also argue nothing in favor of it either. Outside of .NET Framework you already rely on the binding behavior that higher wins. A generated app.config with the right redirects will do the same, so I don't see a reason why a checked in copy with the project is helping. I just think it causes noise and adds potential for conflicts...

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 5, 2017

forki commented Sep 5, 2017

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Sep 5, 2017

If what @terrajobst is saying is that simply adding that single element to a vbproj, fsproj or csproj magically fixes all binding redirects, all the time, then I'm not averse to using that instead and deprecating Paket support for BRs. But only if this works consistently and can be applied to e.g. net452 projects running on old MSBuild project format.

isaacabraham commented Sep 5, 2017

If what @terrajobst is saying is that simply adding that single element to a vbproj, fsproj or csproj magically fixes all binding redirects, all the time, then I'm not averse to using that instead and deprecating Paket support for BRs. But only if this works consistently and can be applied to e.g. net452 projects running on old MSBuild project format.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 5, 2017

magically fixes all binding redirects

think about what that means. It means there are effectively no binding redirects anymore.
So in some sense the feature is gone.

forki commented Sep 5, 2017

magically fixes all binding redirects

think about what that means. It means there are effectively no binding redirects anymore.
So in some sense the feature is gone.

@shadowmint

This comment has been minimized.

Show comment
Hide comment
@shadowmint

shadowmint Sep 24, 2018

Adding +1's to this issue appears to be no impact.

I've also encountered this, and tried all of the extensive advice in this thread to migrate a 4.6 ASP.Net project to 4.7.2... and it doesn't work.

After migrating to PackageReferences and updating my bindings by hand, I still encounter the dreaded System.IO.FileNotFound error at runtime for System.Web.Http.

As far as I can tell, the summary of this entire thread basically boils down to:

There is currently no migration path from < 4.6.1 to > 4.6.1 for ASP.NET projects.

No migration tooling for ASP.Net projects, and the guidance by doing it by hand (as shown by the dozens of issues referenced in this thread), don't work.

That's it. End of story.

This is extremely disappointing, and should be much more clearly communicated; because the migration advice for 4.7.x doesn't mention anywhere that this is the case.

shadowmint commented Sep 24, 2018

Adding +1's to this issue appears to be no impact.

I've also encountered this, and tried all of the extensive advice in this thread to migrate a 4.6 ASP.Net project to 4.7.2... and it doesn't work.

After migrating to PackageReferences and updating my bindings by hand, I still encounter the dreaded System.IO.FileNotFound error at runtime for System.Web.Http.

As far as I can tell, the summary of this entire thread basically boils down to:

There is currently no migration path from < 4.6.1 to > 4.6.1 for ASP.NET projects.

No migration tooling for ASP.Net projects, and the guidance by doing it by hand (as shown by the dozens of issues referenced in this thread), don't work.

That's it. End of story.

This is extremely disappointing, and should be much more clearly communicated; because the migration advice for 4.7.x doesn't mention anywhere that this is the case.

@Timovzl

This comment has been minimized.

Show comment
Hide comment
@Timovzl

Timovzl Sep 24, 2018

@shadowmint In case it helps you, I have looked up how we dealt with this last year. After moving to PackageReference, we had to add a binding redirect to App.config that points to 4.0.0.0:

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>

Only by pointing it to 4.0.0.0 I could get it working. My suspicion is that this has something to do with the GAC, where this version is found and somehow preferred.

Timovzl commented Sep 24, 2018

@shadowmint In case it helps you, I have looked up how we dealt with this last year. After moving to PackageReference, we had to add a binding redirect to App.config that points to 4.0.0.0:

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>

Only by pointing it to 4.0.0.0 I could get it working. My suspicion is that this has something to do with the GAC, where this version is found and somehow preferred.

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli Sep 24, 2018

Contributor

@shadowmint I don't think asp.net (classic) projects support PackageReference yet.
In any case, you should see a warning in the error list about binding redirects. you should be able to double click that and VS will add the missing binding redirects to your web.config file.

Contributor

dasMulli commented Sep 24, 2018

@shadowmint I don't think asp.net (classic) projects support PackageReference yet.
In any case, you should see a warning in the error list about binding redirects. you should be able to double click that and VS will add the missing binding redirects to your web.config file.

@shadowmint

This comment has been minimized.

Show comment
Hide comment
@shadowmint

shadowmint Sep 25, 2018

you should be able to double click that and VS will add the missing binding redirects to your web.config file...

You most certainly can click on the warning, and have visual studio update your web.config.

If you want it to actually do something meaningful, you should first go in and remove any existing bindings, because you probably have some which are invalid or unnecessary, and it won't update them correctly.

However, even so, unfortunately, after doing so you may encounter:

Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Despite having this in your web.config have no reference to System.Runtime after using the visual studio helper function.

What then?

I mean, I think it's fair to say from the length of this thread, and that people are still linking new issues to it, that this is fundamentally broken.

...and look, sure. I appreciate that it's not always easy to upgrade, and it's not always easy to support legacy projects, and building tooling to automate processes takes time and effort.

What is not ok is pretending that this is just a little bug you can sweep under the carpet, like oh hey, we're going to release 4.8 in a few months, upgrade everyone... when for two years:

  • it's been a nightmare to upgrade to the most recent releases for people,
  • people still can't upgrade framework version.
  • the 'suggested' solutions are either a) if you're a library author multi-target your library so it doesn't target net standard, and b) if you're an application author, manually edit your configuration files, use the VS tooling and good luck with that when it doesn't work.

Let's face it: You cannot upgrade some projects at this point.

That's it.

Now, if someone had pinned that to the top of this thread, I wouldn't have wasted a week trying to upgrade my projects; perhaps, by leaving this here, I can help the next person not doing the same.

shadowmint commented Sep 25, 2018

you should be able to double click that and VS will add the missing binding redirects to your web.config file...

You most certainly can click on the warning, and have visual studio update your web.config.

If you want it to actually do something meaningful, you should first go in and remove any existing bindings, because you probably have some which are invalid or unnecessary, and it won't update them correctly.

However, even so, unfortunately, after doing so you may encounter:

Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Despite having this in your web.config have no reference to System.Runtime after using the visual studio helper function.

What then?

I mean, I think it's fair to say from the length of this thread, and that people are still linking new issues to it, that this is fundamentally broken.

...and look, sure. I appreciate that it's not always easy to upgrade, and it's not always easy to support legacy projects, and building tooling to automate processes takes time and effort.

What is not ok is pretending that this is just a little bug you can sweep under the carpet, like oh hey, we're going to release 4.8 in a few months, upgrade everyone... when for two years:

  • it's been a nightmare to upgrade to the most recent releases for people,
  • people still can't upgrade framework version.
  • the 'suggested' solutions are either a) if you're a library author multi-target your library so it doesn't target net standard, and b) if you're an application author, manually edit your configuration files, use the VS tooling and good luck with that when it doesn't work.

Let's face it: You cannot upgrade some projects at this point.

That's it.

Now, if someone had pinned that to the top of this thread, I wouldn't have wasted a week trying to upgrade my projects; perhaps, by leaving this here, I can help the next person not doing the same.

@GSPP

This comment has been minimized.

Show comment
Hide comment
@GSPP

GSPP Oct 14, 2018

I'm tracking related issues and information in a list. They are related to System.Net.Http, System.Runtime, System.IO, System.ValueTuple, System.Buffers and others.

dotnet/corefx#32587
dotnet/corefx#32561
#481
#567
#558
#887
#891
dotnet/corefx#32610
dotnet/corefx#30642
dotnet/corefx#32757
#895
#877
#521
#295
#476
#184

.NET 4.7.2 helps with some but not all of these. You can look at my comments on some of these issues for some ideas on how to work around those problems. I also have a central list of ideas to try.

GSPP commented Oct 14, 2018

I'm tracking related issues and information in a list. They are related to System.Net.Http, System.Runtime, System.IO, System.ValueTuple, System.Buffers and others.

dotnet/corefx#32587
dotnet/corefx#32561
#481
#567
#558
#887
#891
dotnet/corefx#32610
dotnet/corefx#30642
dotnet/corefx#32757
#895
#877
#521
#295
#476
#184

.NET 4.7.2 helps with some but not all of these. You can look at my comments on some of these issues for some ideas on how to work around those problems. I also have a central list of ideas to try.

@cocowalla

This comment has been minimized.

Show comment
Hide comment
@cocowalla

cocowalla Oct 14, 2018

@GSPP a bit cheeky of me, but is there any chance of a TLDR?

cocowalla commented Oct 14, 2018

@GSPP a bit cheeky of me, but is there any chance of a TLDR?

@GSPP

This comment has been minimized.

Show comment
Hide comment
@GSPP

GSPP Oct 14, 2018

@cocowalla I think there are multiple issues none of which I fully understand. What I did was to experiment a lot, diff the changes in detailed MSBuild logs and draw some conclusions.

I encountered these issues in multiple projects. It is very easy to trigger them (e.g. new solution, add DLL project, add two NuGet packages, bug). Google and this issue tracker is full of people hitting this. I spent days with this.

These are candidates for workarounds:

  • Upgrade to .NET 4.7.2 (fixes some but not all issues)
  • Downgrade to .NET 4.7.0. This might actually help because the problems started in .NET 4.7.1 when netstandard was partly integrated into the Framework. I have not tried downgrading and it might not be feasible on Windows 10.
  • Update all packages (doesn't help much)
  • Reinstall all packages (I found that "Update-Package -Reinstall" was not enough. Each package must be reinstalled individually ("Update-Package -Reinstall PackageName") and in each project).
  • PackageReference seems to solve some issues but I encountered show-stopper bugs
  • Delete binding redirects for those assemblies that can not be loaded (e.g. System.Runtime)
  • Change the binding redirect to the framework version (e.g. System.Runtime to 4.0.0.0)
  • I encountered build errors when a dependent project mysteriously referenced a different version of an assembly although everything clearly specified the right version. Manually play with the <Reference> elements in the csproj
  • Add references that appear unneeded (I fixed a System.Buffers problem that way)
  • Delete bin/obj folders (this often makes a difference because old assemblies are left there. VS clean does not remove them! This can make you believe that your solution works but it really just depends on old assemblies. I always have deleted these folders between tests to be sure.)
  • If you want to know what an assembly resolves to use the VS properties panel on the reference. This uses the information from MSBuild. Note, that each project might resolve each reference differently.
  • Use fuslogvw.exe settings to turn on assembly load information and see what's loaded.
  • Use Sysinternals Process Monitor to see what file paths are being search for the DLL name by the CLR and by MSBuild.
  • Note, that MSBuild can use other assembly versions and locations against your direct instructions in the csproj. Both version and hint path can be overridden by a process that I do not understand. There is no way to truly force anything.
  • The "Automatic binding redirects" feature can make a difference.
  • I have only worked on .NET Framework projects. For .NET Core and netstandard there might be differences in behavior. Some of the issues from my list are about netstandard.

As you can see this is a dirty situation. Be happy when you find a working state, check it into source control and risk no further changes :)

I understand the .NET team is aware and working on a fix. I am puzzled, though, how such egregious issues can be left standing for such a long time. 4.7.2 is 6 month old and these bugs are older.

GSPP commented Oct 14, 2018

@cocowalla I think there are multiple issues none of which I fully understand. What I did was to experiment a lot, diff the changes in detailed MSBuild logs and draw some conclusions.

I encountered these issues in multiple projects. It is very easy to trigger them (e.g. new solution, add DLL project, add two NuGet packages, bug). Google and this issue tracker is full of people hitting this. I spent days with this.

These are candidates for workarounds:

  • Upgrade to .NET 4.7.2 (fixes some but not all issues)
  • Downgrade to .NET 4.7.0. This might actually help because the problems started in .NET 4.7.1 when netstandard was partly integrated into the Framework. I have not tried downgrading and it might not be feasible on Windows 10.
  • Update all packages (doesn't help much)
  • Reinstall all packages (I found that "Update-Package -Reinstall" was not enough. Each package must be reinstalled individually ("Update-Package -Reinstall PackageName") and in each project).
  • PackageReference seems to solve some issues but I encountered show-stopper bugs
  • Delete binding redirects for those assemblies that can not be loaded (e.g. System.Runtime)
  • Change the binding redirect to the framework version (e.g. System.Runtime to 4.0.0.0)
  • I encountered build errors when a dependent project mysteriously referenced a different version of an assembly although everything clearly specified the right version. Manually play with the <Reference> elements in the csproj
  • Add references that appear unneeded (I fixed a System.Buffers problem that way)
  • Delete bin/obj folders (this often makes a difference because old assemblies are left there. VS clean does not remove them! This can make you believe that your solution works but it really just depends on old assemblies. I always have deleted these folders between tests to be sure.)
  • If you want to know what an assembly resolves to use the VS properties panel on the reference. This uses the information from MSBuild. Note, that each project might resolve each reference differently.
  • Use fuslogvw.exe settings to turn on assembly load information and see what's loaded.
  • Use Sysinternals Process Monitor to see what file paths are being search for the DLL name by the CLR and by MSBuild.
  • Note, that MSBuild can use other assembly versions and locations against your direct instructions in the csproj. Both version and hint path can be overridden by a process that I do not understand. There is no way to truly force anything.
  • The "Automatic binding redirects" feature can make a difference.
  • I have only worked on .NET Framework projects. For .NET Core and netstandard there might be differences in behavior. Some of the issues from my list are about netstandard.

As you can see this is a dirty situation. Be happy when you find a working state, check it into source control and risk no further changes :)

I understand the .NET team is aware and working on a fix. I am puzzled, though, how such egregious issues can be left standing for such a long time. 4.7.2 is 6 month old and these bugs are older.

@shadowmint

This comment has been minimized.

Show comment
Hide comment
@shadowmint

shadowmint Oct 15, 2018

I would like to add here, that the suggestion that this is because "users are not on 4.7.2 or using the latest VS" is not correct (see #895 for a minimal repo that flatly contradicts this assertion).

The issue here, is that this issue isn't being looked after.

Although, potentially, the issues linked here by @GSPP may or may not all be exactly the same issue, it is extremely difficult to get any kind of 'tldr' on this issue, or have any idea what to do when you encounter it on any of the related issues.

The pinned advice here is simply:

  • Upgrade to 4.7.?
  • Upgrade to PackageReference
  • Update bindings / use autobindings tooling from VS (whatever internal magic that uses)

...that's it. The reason we're forced to trawl stack overflow and these issue trackers for other crazy things to try (I mean seriously, go and read #891, #895), if that we have zero guidance here on what to do when the above doesn't work.

  • Where should repo's be posted?
  • Who is looking after them?
  • What is being done to fix the root cause?
  • What meaningful things should be tried to resolve these errors?

This thread epitomizes the problem:

Look, what you should be doing is locking and closing all the related issues and all the related issue trackers and directing people to "try [list of suggestions from ?? here], and post a repo of the issue [on this issue tracker] which uses [this issue template for a repo] if that doesn't help you".

Just leaving these issues open isn't achieving anything; the only thing @GSPP appears to have actually done here is raise the profile of this issue significantly enough that someone has actually decided they need to respond to it finally.

That it took someone manually going out and linking all these issues for that to happen is massively disappointing; surely there is more going on 'behind the scenes' here, but it's certainly not visible to us.

Some of the fixes suggested may work, some may not... but this is the most pertinent part of the above response:

As you can see this is a dirty situation. Be happy when you find a working state, check it into source control and risk no further changes :)

shadowmint commented Oct 15, 2018

I would like to add here, that the suggestion that this is because "users are not on 4.7.2 or using the latest VS" is not correct (see #895 for a minimal repo that flatly contradicts this assertion).

The issue here, is that this issue isn't being looked after.

Although, potentially, the issues linked here by @GSPP may or may not all be exactly the same issue, it is extremely difficult to get any kind of 'tldr' on this issue, or have any idea what to do when you encounter it on any of the related issues.

The pinned advice here is simply:

  • Upgrade to 4.7.?
  • Upgrade to PackageReference
  • Update bindings / use autobindings tooling from VS (whatever internal magic that uses)

...that's it. The reason we're forced to trawl stack overflow and these issue trackers for other crazy things to try (I mean seriously, go and read #891, #895), if that we have zero guidance here on what to do when the above doesn't work.

  • Where should repo's be posted?
  • Who is looking after them?
  • What is being done to fix the root cause?
  • What meaningful things should be tried to resolve these errors?

This thread epitomizes the problem:

Look, what you should be doing is locking and closing all the related issues and all the related issue trackers and directing people to "try [list of suggestions from ?? here], and post a repo of the issue [on this issue tracker] which uses [this issue template for a repo] if that doesn't help you".

Just leaving these issues open isn't achieving anything; the only thing @GSPP appears to have actually done here is raise the profile of this issue significantly enough that someone has actually decided they need to respond to it finally.

That it took someone manually going out and linking all these issues for that to happen is massively disappointing; surely there is more going on 'behind the scenes' here, but it's certainly not visible to us.

Some of the fixes suggested may work, some may not... but this is the most pertinent part of the above response:

As you can see this is a dirty situation. Be happy when you find a working state, check it into source control and risk no further changes :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment