sdk: New .csproj cannot reference GAC assemblies
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/roslyn-project-system#1739
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 2
- Comments: 17 (11 by maintainers)
Links to this issue
Commits related to this issue
- Update dependencies from https://github.com/dotnet/arcade build 20191005.1 (#987) - Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19505.1 — committed to mmitche/sdk by dotnet-maestro[bot] 5 years ago
From @jnm2 on March 13, 2017 23:11
Adding this to the bottom of the new csproj and reopening the solution fixes all problems:
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 Let’s open another bug for that - that’s not by design.