New .csproj cannot reference GAC assemblies

[davkean]

From @jnm2 on March 13, 2017 20:31

You can no longer reference some GAC assemblies without specifying a HintPath, at which point there isn't much point in using the GAC at all.

Class1.cs:

using System;
using Microsoft.SolverFoundation.Services;

public class Class1
{
    public static readonly Type X = typeof(ISolver);
}

Old .csproj, working:

<Project ToolsVersion="15.0">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
  <PropertyGroup>
    <OutputType>Library</OutputType>
    <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
    <OutputPath>bin\$(Configuration)\</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="Microsoft.Solver.Foundation" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="*.cs" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

New .csproj fails to find the reference:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="Microsoft.Solver.Foundation" />
  </ItemGroup>

</Project>

This also does not work: <Reference Include="Microsoft.Solver.Foundation, Version=3.0.2.10889, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />.

Why is this broken?

Copied from original issue: dotnet/project-system#1739

[davkean]

From @jnm2 on March 13, 2017 20:40

I'm also witnessing a weird phenomenon where some GAC assemblies can be referenced and the build succeeds, but Visual Studio shows build warnings and reference node warning icons saying the reference could not be resolved and if you open any of the .cs files, and the editor creates a whole bunch of errors as though the reference was not referenced at all. The weird part is, it builds fine. For example, <Reference Include="DevExpress.Data.v16.2, Version=16.2.4.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a, processorArchitecture=MSIL">. All DevExpress dlls are this way. In contrast, Microsoft Solver Foundation is not.

But the moment I add a <SpecificVersion>false</SpecificVersion> or a <SpecificVersion>true</SpecificVersion> subelement, it goes back to not building at all.

I would really like to understand this phenomenon.

I don't want to use HintPaths because of the chance something will be different across developer machines and the build server, and why should I have to add ugly GAC paths?

[davkean]

From @jnm2 on March 13, 2017 21:49

As it turns out, HintPath with SpecificVersion false is not a useful workaround because the HintPath does not exist on different machines.

[davkean]

From @jnm2 on March 13, 2017 23:11

Adding this to the bottom of the new csproj and reopening the solution fixes all problems:

  <!-- Workaround for https://github.com/dotnet/roslyn-project-system/issues/1739 -->
  <PropertyGroup>
    <AssemblySearchPaths>$(AssemblySearchPaths);{GAC}</AssemblySearchPaths>
  </PropertyGroup>

[davkean]

From @jmarolf on March 13, 2017 23:35

I can repro this. I'll need to look into what has changed regarding the GAC.

This should work in the mean time.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Solver.Foundation" Version="3.1.0" />
  </ItemGroup>

</Project>

[davkean]

In SDK-based projects {GAC} is no longer part of the search paths. GAC is a runtime-lookup location, not a build-time lookup location. This is a deliberate change - it resulted in a huge number of bugs where projects would accidentally pick up the wrong dependencies on build machines because a targeting pack or SDK wasn't installed. I suspect when you add a version number, you are resolving it from a build-time location such as {AssemblyFoldersEx} instead of the GAC. Looking at the build log would help us figure that out.

As you found, the workaround is to explicitly add {GAC} to the set of search paths.

[jnm2]

GAC is a runtime-lookup location, not a build-time lookup location.

Gotcha- and the ironic part is that we always have Copy Local true so at runtime they are never resolved from the GAC.

What's the ideal solution to resolve these references at build-time, with no hint path so that it works across multiple machines? PackageReference, or <AssemblySearchPaths>$(AssemblySearchPaths);{GAC}</AssemblySearchPaths>, or some other configuration? I'm not familiar with AssemblyFoldersEx, is that where the ideal solution lies?

[davkean]

The package isn't Microsoft-provided, so based on that - I would not recommend you use it.

If Microsoft.Solver.Foundation isn't installed into a folder listed under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319\AssemblyFoldersEx - and is only installed into the GAC, then the only recommendation I have is what you've done above.

[jnm2]

@davkean Microsoft Solver Foundation, for whatever reason, only appears at HKEY_CURRENT_USER\SOFTWARE\Microsoft\.Net Framework\Assembly Folders\Microsoft.Solver.Foundation, value All Assemblies In. It's nowhere else. It appears in Visual Studio's Add Reference dialog only if I target net40. It disappears if I target net45, net46 or net462.

DevExpress appears at HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\DevExpress Components 16.2, value (Default). For new csproj, the dlls in that folder never appear in the Add Reference dialog no matter what framework version I target. For legacy csproj, the dlls all show up under the Extensions category. Is this a bug?

[nguerrera]

This behaviour is by-design. You can opt back in as shown here. This should not be considered a workaround, but rather a deliberate and supported opt-in where you accept the consequences of having potentially different (and even incorrect) build behaviour on different machines.

[jnm2]

I'm still curious why VS2017 shows no AssemblyFoldersEx assemblies under Extensions for CPS csproj, but it does them all for legacy csproj.

[davkean]

@jnm2 Let's open another bug for that - that's not by design.