dotnet store fails with error that it cannot find DiaSymReader

[davmason]

Steps to reproduce

The complete scenario is here: https://github.com/aspnet/JitBench/blob/dev/README.md

This has been working for a while and regressed in the past few days.

The issue is when the store is generated by this script: .\AspNet-GenerateStore.ps1 -InstallDir .store -Architecture x64 -Runtime win7-x64

This is the command that is run by the script:

dotnet store --manifest .\CreateStore.proj -f netcoreapp2.0 -r win7-x64 --framework-version 2.1.0-preview1-25405-02 -w D:\JitBenchDevTest\JitBench\.temp -o D:\JitBenchDevTest\JitBench\.store

Expected behavior

Dotnet store runs successfully

Actual behavior

Crossgen fails on generating pdb with error

Unable to load Microsoft.DiaSymReader.Native.amd64.dll.  Please ensure that Microsoft.DiaSymReader.Native.amd64.dll is on the path.  Error='126'

Environment data

dotnet --info output:

 .NET Command Line Tools (2.1.0-preview1-006329)

Product Information:
 Version:            2.1.0-preview1-006329
 Commit SHA-1 hash:  defa3c3973

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   X:\JitBench\.dotnet\sdk\2.1.0-preview1-006329\

CC @lt72 @rynowak

[lt72]

@eerhardt: Eric, could you please take a look?

[eerhardt]

The default experience for dotnet store has recently changed to generate symbols by default. To generate symbols, crossgen needs Microsoft.DiaSymReader.Native.

To unblock yourself you can either:

• pass --skip-symbols into the dotnet store command to not generate the symbols
• run the dotnet store command from a VS dev command prompt, which has Microsoft.DiaSymReader.Native on the %PATH%.

We should investigate how to get the correct Microsoft.DiaSymReader.Native during dotnet store and put it somewhere crossgen can find it.

[eerhardt]

Related: aspnet/MetaPackages#135

[rynowak]

Should we revert this until this is resolved? It's really disruptive when changes like this come down the pipe and break something that's been working for months.

[eerhardt]

Does one of the two above workarounds not work for you until this is fixed?

If they don't work for you, we can back the change out. But it would be more work, adding more risk and time to the 2.0 release.

[rynowak]

I'm testing this out and running into some issues. Currently trying to figure out if they are related to the store or something else.

[eerhardt]

I have a fix for this issue I am testing out locally. So it hopefully shouldn't be too long...

[rynowak]

@eerhardt - what I'm seeing now is that I can create the store, but I fail consistently at runtime with:

Starting request to http://localhost:5000
fail: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[0]
      An unhandled exception has occurred: Cannot find assembly file Microsoft.AspNetCore.Antiforgery.dll at 'C:\Users\r
ynowak\git\aspnet\JitBench\src\MusicStore\bin\Release\netcoreapp2.0\publish\refs,C:\Users\rynowak\git\aspnet\JitBench\sr
c\MusicStore\bin\Release\netcoreapp2.0\publish\,C:\Users\rynowak\git\aspnet\JitBench\.dotnet\shared\Microsoft.NETCore.Ap
p\2.1.0-preview1-25405-02'

Notice it's not probing my store for the reference assembly.

Is this a separate issue?

.NET Command Line Tools (2.1.0-preview1-006329)

Product Information:
 Version:            2.1.0-preview1-006329
 Commit SHA-1 hash:  defa3c3973

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Users\rynowak\git\aspnet\JitBench\.dotnet\sdk\2.1.0-preview1-006329\

Microsoft .NET Core Shared Framework Host

  Version  : 2.1.0-preview1-25405-02
  Build    : e9e4ff10a4d38fbd48138abb686cbc23a32baab1

[eerhardt]

It looks like a separate issue that was fixed a few weeks ago. https://github.com/dotnet/core-setup/issues/2496.

Is there anyway you can check which version of Microsoft.Extensions.DependencyModel is being referenced by that app? Try looking in the .deps.json file or the project.assets.json file. Which version of ASP.NET are you referencing?

[rynowak]

This is happening for me with the 2.0.0-preview1 release of ASP.NET and the newest shared framework/SDK

The version of dependency model in my project.assets.json is 2.0.0-preview1-002111

[eerhardt]

Yep, that's the issue.

After preview1, there was a request to remove the ASP.NET assemblies from the publish\refs folder because they are already in the runtime store. See #1216. So the preview2 (and later) SDK now stops copying the ASP.NET assemblies to the publish\refs folder. However, the preview1 runtime had a bug in it - the one I referenced above https://github.com/dotnet/core-setup/issues/2496.

Basically, the newer SDK is not compatible with the ASP.NET preview1 runtime out of the box, since it no longer copies files the preview1 runtime needed.

An easy way to work around this issue is to add <PackageReference Include="Microsoft.Extensions.DependencyModel" Version="2.0.0-preview2-25407-01" /> to your project.

Other options would be:

• Use the preview1 SDK
• Use the preview2 ASP.NET runtime
• Add some gunk into your project that makes these files get copied to the publish/refs directory.

[rynowak]

OK interesting, I'm not sure why we're just running into this now. I'll try hoisting dependency model

[rynowak]

Thanks @eerhardt - hoisting the dependency model workaround that issue, so it looks like we're not blocked here.

[livarcocc]

I believe this issue has been fixed now that we inserted an SDK with the fix in the CLI.