'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]

[dotnet-issue-labeler]

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.

[richlander]

I wrote this brain-dump on shared libraries last summer: https://github.com/dotnet/designs/blob/shared-libraries/accepted/2021/shared-libraries.md. It's just a branch I pushed. Nothing more has happened on it. I didn't even re-read it just now so I hope it is semi-coherent.

I'll let @baronfel speak to the current status dotnet store.

[EdLichtman]

@richlander Our team is incredibly interested in something like the dotnet package store.

Our use case is, we have software that is installed on servers with the caveat that they may or may not be beyond our control.

Therefore, we cannot just "containerize" to solve all of our problems.

Likewise, we cannot make a requirement that the dotnet runtime be pre-installed on the system, for reasons beyond the scope of this issue.

But finally, packing a self-contained app costs 100mb at a minimum, and we're splitting our software into microservices, which will not scale well when each app costs a minimum of 100mb, along with all of the other software requirements.

So what we're looking into is shipping the standalone dotnet runtime binary, and using that to run the application. In order to reduce the storage of our application, we were hoping to ship all of the nuget packages and internal libraries to a dotnet runtime store, and if we needed to patch a piece of software, we could overwrite that library within the package store for all apps, or overwrite that library in the local repo for a single application being updated.

What's the status on whether an optimization like this will be allowed in the future?

[agocke]

What's the status on whether an optimization like this will be allowed in the future?

There's a lot of moving parts there. The only thing I could see us working on in the near future (read: .NET 10) would be a feature that allows you to "build your own" shared framework, like Microsoft.AspNetCore.App or Microsoft.NetCore.App. These are effectively groups of assemblies that ship with the runtime. When users building framework-dependent apps reference those shared frameworks they don't get DLLs copied to their output. Instead, the SDK assumes that the framework will be available on the machine installation whenever they deploy, and it will pick those DLLs from the shared framework during run time.

This is along the same lines as what @richlander posted above.

The challenge with this feature set that it is going to require significant design and implementation in both the .NET SDK and the .NET runtime.

we could overwrite that library within the package store for all apps, or overwrite that library in the local repo for a single application being updated.

I don't think we will ever support something like this. Updating individual DLLs is something that we've stopped supporting on moving to .NET Core. Updating the shared framework would involve redeploying the whole thing, then copying the changed files over.

[KalleOlaviNiemitalo]

Updating individual DLLs is something that we've stopped supporting on moving to .NET Core.

@agocke, is that policy specifically for .NET SDK (e.g. trimming during dotnet publish) as opposed to the runtime? IsCompatibleAssemblyVersion allows higher assembly versions, so there appears to be some support for running with higher versions of referenced libraries than what the compiler saw.

[AraHaan]

I find it really cool how easy it is for someone to build their own FrameworkReference's. All you need is a custom MSBuild SDK to insert it as a KnownFrameworkReference and then anyone who <FrameworkReference />'s it will be able to and it will resolve it provided it is installed at $(DOTNET_ROOT)/shared and a few things for it as well in $(DOTNET_ROOT)/packs. While many would argue that it should be for the .NET Team remember that many companies could benefit from being able to use the same sort of benefits such a thing would have.

Benefits include:

• Installing updates to their frameworks that includes security, bug fixes, and performance improvements would automatically apply to every single application they develop for free as long as they are not self-contained.
• Building Shared Frameworks requires use of dotnet/arcade which means that special RID versions of them that is R2R and crossgen2'd gets generated which also improves startup performance for free.
• Makes maintaining everything for an organization / company less stressful as it requires less needless work to do (publish each updated assembly as nuget package and then opening every application's project up and recompile to get the updated dependencies when their code does not directly change at all).
• Logically the best path forward. If anything I think FrameworkReference should be allowed for anyone, but have it check a Microsoft licensing API that Microsoft owns and then sell rights to use this feature as well for companies and organizations that wants this path. BESIDES if this is not done it WONT stop them from using dotnet/arcade today to ship their own shared framework due to how easy they make it possible to do currently. Might as well use it as a way to fund the .NET Foundation in this case and review those who actually want to use this feature (on top of them paying the fee for it) to ensure they won't use it as a way to attack people.

[agocke]

Updating individual DLLs is something that we've stopped supporting on moving to .NET Core.

@agocke, is that policy specifically for .NET SDK (e.g. trimming during dotnet publish) as opposed to the runtime? IsCompatibleAssemblyVersion allows higher assembly versions, so there appears to be some support for running with higher versions of referenced libraries than what the compiler saw.

It’s not that we specifically ban handling DLLs, it’s that the shared framework is not distributed as individual DLLs. We don’t support shipping or updating them individually

[AraHaan]

Updating individual DLLs is something that we've stopped supporting on moving to .NET Core.

@agocke, is that policy specifically for .NET SDK (e.g. trimming during dotnet publish) as opposed to the runtime? IsCompatibleAssemblyVersion allows higher assembly versions, so there appears to be some support for running with higher versions of referenced libraries than what the compiler saw.

It’s not that we specifically ban handling DLLs, it’s that the shared framework is not distributed as individual DLLs. We don’t support shipping or updating them individually

Not in an official way no, but it is possible for one to copy & paste the updated dlls into the folder manually though.