'dotnet store' can't find crossgen with .NET 6

[Beau-Gosse-dev]

Describe the bug

Calling 'dotnet store' on a package store manifest throws error that it can't find crossgen, since crossgen is not included in the tools directory of .NET 6.0.3

To Reproduce

0. On Windows, install .NET 6.0.3 SDK
1. Create a file called packages.csproj
2. Fill it with the example content from here (the example with Moq and Newtonsoft.Json): https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-store
3. From the same directory as the created csproj run dotnet store --manifest packages.csproj --framework net6.0 --runtime win-x64
4. Exception is thrown
5. Add flag --skip-optimization to command and it will work

Exceptions (if any)

C:\Program Files\dotnet\sdk\6.0.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.CrossGen.targets(82,5): error NETSDK1016: Unable to find resolved path for 'C:\Users\username\.nuget\packages\microsoft.netcore.app.runtime.win-x64\6.0.3\runtimes\win-x64\native\..\..\..\tools\crossgen.exe'. [C:\Users\username\Downloads\DleteMe\subTest\testProject\packages.csproj]

Further technical details

Results of dotnet --info

.NET SDK (reflecting any global.json):
 Version:   6.0.201
 Commit:    ef40e6aa06

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.201\

Host (useful for support):
  Version: 6.0.3
  Commit:  c24d9a9c91

.NET SDKs installed:
  3.1.417 [C:\Program Files\dotnet\sdk]
  7.0.406 [C:\Program Files\dotnet\sdk]
  8.0.101 [C:\Program Files\dotnet\sdk]
  6.0.102 [C:\Program Files\dotnet\sdk]
  6.0.200 [C:\Program Files\dotnet\sdk]
  6.0.201 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[baronfel]

Some old comments seem to suggest that this functionality is no longer needed with the move to shared frameworks as the unit of deployment - by adding a FrameworkReference to your project you implicitly use that pre-provisioned set of assemblies (which can be installed and updated as a unit via .NET SDK packages for your host OS), or you can bundle them with a self-contained deployment. Do either of those tackle your use case?

In either case, we should either research and remove the explicit requirement for crossgen here, or condition it based on the version of the runtime assets in use - from some quick investigation it looks like we still bundled it in the 5.x versions of this package, so the constraint should be a semver comparison with 6.0.0 as the lower bound I guess. @marcpopMSFT thoughts on that?

[Beau-Gosse-dev]

@baronfel do you have a link to documentation for the mentioned FrameworkReference? A quick search only seems to show how to use the ASP.NET FrameworkReference, but in this case we're trying to build our own custom store (maybe that means we should be trying to build our own custom FrameworkReference now?).

Our use case is shown here in the Lambda Layers CLI PublishLayers command.

[baronfel]

@Beau-Gosse-dev The primary design is here, I believe. @richlander do you have an opinion on the way forward for folks that rely(ied) on the Runtime Store? Should we be guiding them to FrameworkReferences?

[pn185067]

Additionally..

After getting around using the --skip-optimization flag for a dotnet 6 console app, publishing against the generated manifest doesn't seem to be working either.

Sample app:
RPSTest.zip

To reproduce:

• On the terminal

1. dotnet store --manifest RPSTest.csproj --runtime win10-x64 --framework net6.0 --framework-version 6.0.2 --skip-optimization
2. dotnet publish --manifest C:\Users\<username>\.dotnet\store\x64\net6.0\artifact.xml
3. Try running ..\RPSTest\RPSTest\bin\Debug\net6.0\publish\RPSTest.exe

Expectation - Hello World ! on console.
Actual - "Could not load file or assembly 'Moq, Version-4.17.0.0"

[Beau-Gosse-dev]

@richlander any advice on this?

[richlander]

The dotnet store feature is no longer under development (or testing). We don't have a good replacement for it either. FrameworkReference is reserved for .NET Team delivered frameworks (like ASP.NET Core). At some point, we will stop shipping this command altogether.

For now, it seems like you have a workaround. Is that good enough?

We have started to talk about the shared library scenario, however, we don't have a spec on that yet. Once I've written a spec on it, It would be great to get feedback from your team.

[pn185067]

We have started to talk about the shared library scenario, however, we don't have a spec on that yet. Once I've written a spec on it, It would be great to get feedback from your team.

Is this to me ? Or @Beau-Gosse-dev ?

[richlander]

Well, really anyone, but I meant @Beau-Gosse-dev.

[normj]

@richlander I would be interested in that spec. It sounds like our AWS Lambda feature relying on store's ability to do assembly optimization doesn't have any path forward right now is that correct? It is not one of our most widely known features but people that knew about it really like it and we have been wanting to make the feature more widely known.

[AraHaan]

@baronfel do you have a link to documentation for the mentioned FrameworkReference? A quick search only seems to show how to use the ASP.NET FrameworkReference, but in this case we're trying to build our own custom store (maybe that means we should be trying to build our own custom FrameworkReference now?).

Our use case is shown here in the Lambda Layers CLI PublishLayers command.

KnownFrameworkReference vibes.