Microsoft.DiaSymReader.Native.x86.dll ends up in nuget package

[joperezr]

@natemcmaster commented on Fri Oct 21 2016

Microsoft.DiaSymReader.Native 1.4.0 includes a .props file as included below. This includes a condition !Exists('project.json') AND !Exists('$(MSBuildProjectName).project.json'). The deprecation of project.json means that when users upgrade from a project.json build system to a MSBuild system (and thus deletes project.json), this .props file will include Microsoft.DiaSymReader.Native.{arch}.dll as 'content' in all projects using the .NET Core SDK.

Example:
dotnet build3 on a netcoreapp will copy the file to the output directory

_CopyOutOfDateSourceItemsToOutputDirectory:
  Copying file from "C:\Users\namc\.nuget\packages\microsoft.diasymreader.native\1.4.0\runtimes\win\native\Microsoft.DiaSymReader.Native.x86.dll" to "bin\Debug\netcoreapp1.0\Microsoft.DiaSymReader.Native.x86.dll".
  Copying file from "C:\Users\namc\.nuget\packages\microsoft.diasymreader.native\1.4.0\runtimes\win\native\Microsoft.DiaSymReader.Native.amd64.dll" to "bin\Debug\netcoreapp1.0\Microsoft.DiaSymReader.Native.amd64.dll".

The extra file in the output directory may be harmless for "dotnet run", but it's still wrong for .NET Core projects which resolve native assets from the nuget cache.

The worse problem is "dotnet pack3", which includes all 'content' items. This means Microsoft.DiaSymReader.Native.x86.dll and Microsoft.DiaSymReader.Native.amd64.dll will end up in the nuget package of anyone performing "dotnet pack3" on a csproj that uses Microsoft.NETCore.App.

The offending props file, from .nuget\packages\microsoft.diasymreader.native\1.4.0\build\microsoft.diasymreader.native.props

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup Condition="!Exists('project.json') AND !Exists('$(MSBuildProjectName).project.json')">
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win\native\Microsoft.DiaSymReader.Native.x86.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Visible>false</Visible>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win\native\Microsoft.DiaSymReader.Native.amd64.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Visible>false</Visible>
    </Content>
  </ItemGroup>
</Project>

cc @emgarten @piotrpMSFT

---

@ericstj commented on Thu Nov 10 2016

This isn't a CoreFx package, please open in https://github.com/dotnet/roslyn/issues

---

@joperezr commented on Thu Nov 10 2016

thanks @ericstj I'll move this issue over to roslyn repo.

[tmat]

@ericstj I believe the condition is there to detect older versions of nuget that use packages.config. Perhaps we should check for presence of packages.config?

[ericstj]

Potentially. We should ask the NuGet folks for a best practice recommendation for folks who are trying to write packages that work in both a packages.config project, project.json project, and packagereference project. /cc @rrelyea @emgarten

[emgarten]

Checking for packages.config or packages.projectName.config is a better option. Project.json and PackageReference type projects will behave the same.

We could potentially improve this by setting a property in the targets/props files auto generated for project.json/packagereference to declare the mode NuGet brought the package in under. NuGet/Home#3928

For NETCore apps the problem is just that this target is used at all since the dlls come from runtimes, right? Fixing this targets file to work PackageReference would solve that.

I've opened NuGet/Home#3927 to track excluding content items coming from packages, the pack3 behavior you are seeing seems wrong.

[tmat]

I have changed the .props file like so:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup Condition="Exists('packages.config') OR Exists('$(MSBuildProjectName).packages.config') OR Exists('packages.$(MSBuildProjectName).config')">
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win\native\Microsoft.DiaSymReader.Native.x86.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Visible>false</Visible>
      <Link>Microsoft.DiaSymReader.Native.x86.dll</Link>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win\native\Microsoft.DiaSymReader.Native.amd64.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Visible>false</Visible>
      <Link>Microsoft.DiaSymReader.Native.amd64.dll</Link>
    </Content>
  </ItemGroup>
</Project>

Changed the condition and added <Link> to copy the .dlls directly to output dir, instead of a subdirectory.

See https://github.com/dotnet/roslyn-internal/pull/1384

[natemcmaster]

packages.$(MSBuildProjectName).config is also a valid name for NuGet 2 config file. (cref https://github.com/NuGet/NuGet2/blob/e89c4b2fc6dc2fc752d2fceecd2a2175b0f4ab69/src/Build/NuGet.targets#L40)

[tmat]

OK, I'll add that. Thanks for pointing it out. Is it now correct?

[tmat]

@natemcmaster Could you confirm that the above snippet is correct and complete now? Thanks.

[natemcmaster]

@tmat LGTM

[jasonmalinowski]

@tmat good to close now?

[tmat]

Yup.

[rohit21agrawal]

@tmat
this is happening with projects that are targeting netcoreapp1.1 as the dependency microsoft.diasymreader.native of Microsoft.netcore.app is bringing in a prop files which adds DLLs into the content item.

This can be prevented by adding <Pack>false</Pack> on these items