Custom metadata on framework references is ignored when a NuGet package references the same assembly

[sharwell]

As demonstrated in DotNetAnalyzers/StyleCopAnalyzers#2499, it appears impossible to assign a new alias to the System reference. I used the following code to add the alias:

<ItemGroup>
  <Reference Update="System">
    <Aliases>global,system</Aliases>
  </Reference>
</ItemGroup>

Attempts to use members of this assembly qualified with system:: instead of global:: resulted in build errors of the following form:

error CS0234: The type or namespace name 'System' does not exist in the namespace 'system' (are you missing an assembly reference?)
error CS0430: The extern alias 'system' was not specified in a /reference option
error CS0616: 'System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute' is not an attribute class

🔗 Here is an AppVeyor build showing the output from a command line build: https://ci.appveyor.com/project/sharwell/stylecopanalyzers/build/1.0.3133

[rainersigwald]

This issue was moved to dotnet/roslyn#21060

[sharwell]

@rainersigwald The main indicator to me that this was a bug for dotnet/sdk is the fact that the above reference works fine in the legacy project system. See DotNetAnalyzers/StyleCopAnalyzers#2426.

[sharwell]

I also wasn't able to get an alias for System working using this approach:

<PropertyGroup>
  <DisableImplicitFrameworkReferences>True</DisableImplicitFrameworkReferences>
  <AddAdditionalExplicitAssemblyReferences>False</AddAdditionalExplicitAssemblyReferences>
  <NoStdLib>True</NoStdLib>
</PropertyGroup>

<ItemGroup>
  <Reference Include="mscorlib" />
  <Reference Include="System">
    <Aliases>system</Aliases>
  </Reference>
</ItemGroup>

[rainersigwald]

You're right, this is closer to an SDK issue than Roslyn. I have more information but have to step away for a minute; I'll update with my investigation in a couple of hours.

[rainersigwald]

Ok, this is indeed more interesting.

Here's a binary log showing the problem on the StyleCopyAnalyzers PR: sdk1443_repro_binlog.zip

It shows that ResolveLockFileReferences is repsonsible for adding a second Reference item pointing to System, which then is used later when ResolveAssemblyReferences gets file paths (they seem equivalent to RAR since they differ only in metadata).

Fortunately, framework package references are conditioned, so this can be worked around:

Workaround

diff --git a/StyleCop.Analyzers/StyleCop.Analyzers.Test/StyleCop.Analyzers.Test.csproj b/StyleCop.Analyzers/StyleCop.Analyzers.Test/StyleCop.Analyzers.Test.csproj
index 3e1bf760..021b7924 100644
--- a/StyleCop.Analyzers/StyleCop.Analyzers.Test/StyleCop.Analyzers.Test.csproj
+++ b/StyleCop.Analyzers/StyleCop.Analyzers.Test/StyleCop.Analyzers.Test.csproj
@@ -12,6 +12,8 @@
   <PropertyGroup>
     <SignAssembly>true</SignAssembly>
     <AssemblyOriginatorKeyFile>..\..\build\keys\TestingKey.snk</AssemblyOriginatorKeyFile>
+
+    <DisableLockFileFrameworks>true</DisableLockFileFrameworks>
   </PropertyGroup>
 
   <ItemGroup>
@@ -26,7 +28,7 @@
   </ItemGroup>
 
   <ItemGroup>
-    <Reference Update="System">
+    <Reference Include="System">
       <Aliases>global,system</Aliases>
     </Reference>
   </ItemGroup>

I'm not sure what the ideal behavior is here. Avoid adding redundant references from package framework references? Merge metadata instead?

@dsplaisted @natidea Thoughts?

[bording]

I believe I've run into another side effect of this issue in #1469. In my case, I'd actually want the reference from the project system to win over the one from the package. Merging the metadata would not solve the problem, because that would mean it would still have Pack=false.

My vote is to drop the package references.

[nguerrera]

I agree that the project should win and that solving this that way is necessary to also fix #1469. I'm closing #1469 as a duplicate since the root cause is the same, but we need to add test cases for both the issue reported here and there when fixing this.

[bording]

I see this currently has no milestone. Any update on when this is likely to be fixed?

[bording]

@nguerrera Any thoughts on when this might get prioritized?

[bording]

@nguerrera Coming up on a year since I last asked about this. Any chance of it getting fixed?

[nguerrera]

I think this was fixed. I recall @dsplaisted making changes around this.

[livarcocc]

Assigned to @dsplaisted to confirm if this has been addressed.

[bording]

I just tested my scenario described in #1469 (which was closed as a dupe of this issue) with VS 2019 RC1 and the 2.2.200 SDK, and the problem does not appear to be fixed. The package still doesn't have the framework references it should have.

[nguerrera]

It's possible we can close this, but need to reopen #1469. I specifically recall fixing something around aliases. Maybe it was something else.

[dsplaisted]

This looks similar to #2254, which I started working on a while ago, but never finished

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.