aspire Aspire does not launch

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug

Launching Aspire fails with an exception about not finding DCP.

Already tried reinstalling aspire workload in the Visual Studio Installer.

Expected Behavior

Aspire launches normally

Steps To Reproduce

No clue, the same project works on other machines.

Exceptions (if any)

info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.2.1+137e8dcae0a7b22c05f48c4e7a5d36fe3f00a8d7
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: D:\Work\Projects\Estaldo\brixter-hotfix\src\Launcher
fail: Aspire.Hosting.Dcp.the program finished with an error[0]
      {"ExitCode": 1, "error": "could not determine installed DCP extensions: CreateFile C:\\Users\\Tibold\\.dcp\\ext: The system cannot find the file specified."}

.NET Version info

.NET SDK:
 Version:           8.0.402
 Commit:            70aa751718
 Workload version:  8.0.400-manifests.d97747b4
 MSBuild version:   17.11.4+37eb419ad

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22631
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.402\

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: SDK 8.0.400, VS 17.11.35312.102
   Manifest Version:    8.2.0/8.0.100
   Manifest Path:       c:\program files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.0\WorkloadManifest.json
   Install Type:        FileBased

 [wasm-tools]
   Installation Source: SDK 8.0.400, VS 17.12.35323.107, VS 17.11.35312.102
   Manifest Version:    8.0.8/8.0.100
   Manifest Path:       c:\program files\dotnet\sdk-manifests\8.0.100\microsoft.net.workload.mono.toolchain.current\8.0.8\WorkloadManifest.json
   Install Type:        FileBased


Host:
  Version:      9.0.0-rc.1.24431.7
  Architecture: x64
  Commit:       static

.NET SDKs installed:
  6.0.321 [C:\Program Files\dotnet\sdk]
  6.0.425 [C:\Program Files\dotnet\sdk]
  8.0.400 [C:\Program Files\dotnet\sdk]
  8.0.402 [C:\Program Files\dotnet\sdk]
  9.0.100-rc.1.24452.12 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.26 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0-rc.1.24452.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.26 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0-rc.1.24431.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.26 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0-rc.1.24452.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  arm64 [C:\Program Files\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation]
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  D:\Work\Projects\Estaldo\brixter-hotfix\global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Anything else?

global.json

{
  "sdk": {
    "allowPrerelease": false,
    "version": "8.0.400",
    "rollForward": "latestMinor"
  }
}

Oct 04 '24 20:10 tibold

cc @joperezr

Oct 04 '24 21:10 davidfowl

Thanks for opening the issue @tibold. Looks like you are not on the latest version of Aspire yet, can you please try running dotnet workload config --update-mode workload-set and dotnet workload update to install 8.2.1 and see if that fixes your issue?

If that doesn't work, can you please provide a binlog of your build so we can investigate further?

To produce one, you can call dotnet build /t:rebuild YourAppHostProject.csproj /bl:msbuild.binlog

Oct 04 '24 22:10 joperezr

I tried the workload update:

dotnet workload update

Updated advertising manifest microsoft.net.workloads.
Installing workload version 8.0.402.1.
Downloading microsoft.net.workloads.8.0.400.msi.x64 (8.402.1)
Installing microsoft.net.workloads.8.0.400.msi.x64 .... Done
Downloading microsoft.net.workload.emscripten.current.manifest-8.0.100.msi.x64 (8.0.8)
Downloading microsoft.net.workload.emscripten.net6.manifest-8.0.100.msi.x64 (8.0.8)
Downloading microsoft.net.workload.emscripten.net7.manifest-8.0.100.msi.x64 (8.0.8)
Downloading microsoft.net.workload.mono.toolchain.current.manifest-8.0.100.msi.x64 (8.0.8)
Downloading microsoft.net.workload.mono.toolchain.net6.manifest-8.0.100.msi.x64 (8.0.8)
Downloading microsoft.net.workload.mono.toolchain.net7.manifest-8.0.100.msi.x64 (8.0.8)
Workload installation failed. Rolling back installed packs...
Removing microsoft.net.sdk.aspire.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.workload.mono.toolchain.net7.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.workload.mono.toolchain.net6.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.workload.mono.toolchain.current.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.sdk.tvos.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.sdk.maui.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.sdk.macos.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.sdk.maccatalyst.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.sdk.ios.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.sdk.android.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.workload.emscripten.net7.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.workload.emscripten.net6.manifest-8.0.100.msi.x64 .... Done
Removing microsoft.net.workload.emscripten.current.manifest-8.0.100.msi.x64 .... Done
Installation rollback failed: Workload manifest microsoft.net.sdk.aspire: 8.2.1/8.0.100 from workload version 8.0.402.1 was not installed. Running "dotnet workload repair" may resolve this.
Removing microsoft.net.workloads.8.0.400.msi.x64 .... Done
Workload update failed: Workload manifest microsoft.net.sdk.aspire: 8.2.1/8.0.100 from workload version 8.0.402.1 was not installed. Running "dotnet workload repair" may resolve this.

Then I ran:

dotnet workload repair

Repairing workload installation for workloads: aspire wasm-tools
Repairing Aspire.Hosting.Sdk.Msi.x64 ............ Done
Repairing Aspire.ProjectTemplates.Msi.x64 .... Done
Repairing Microsoft.NET.Runtime.WebAssembly.Sdk.Msi.x64 .... Failed
Workload repair failed: Failed to repair 39129fe046f1dbf9be30a08b93de6b29-x64.msi. Error: 0x0000064c, The installation source for this product is not available. Verify that the source exists and that you can access it.

Oct 05 '24 07:10 tibold

Hey @joperezr ,

I have created a new aspire project from the Visual Studio 17.11.4 template to get a clean environment to test on. Here is the output:

PS D:\Work\temp\aspire\AspireApp1\AspireApp1.AppHost> dotnet build /t:rebuild  /bl:msbuild.binlog
  Determining projects to restore...
  Restored D:\Work\temp\aspire\AspireApp1\AspireApp1.ServiceDefaults\AspireApp1.ServiceDefaults.csproj (in 177 ms).
  Restored D:\Work\temp\aspire\AspireApp1\AspireApp1.AppHost\AspireApp1.AppHost.csproj (in 176 ms).
  Restored D:\Work\temp\aspire\AspireApp1\AspireApp1.Web\AspireApp1.Web.csproj (in 177 ms).
  Restored D:\Work\temp\aspire\AspireApp1\AspireApp1.ApiService\AspireApp1.ApiService.csproj (in 177 ms).
  AspireApp1.ServiceDefaults -> D:\Work\temp\aspire\AspireApp1\AspireApp1.ServiceDefaults\bin\Debug\net8.0\AspireApp1.ServiceDefaults.dll
  AspireApp1.ApiService -> D:\Work\temp\aspire\AspireApp1\AspireApp1.ApiService\bin\Debug\net8.0\AspireApp1.ApiService.dll
  AspireApp1.Web -> D:\Work\temp\aspire\AspireApp1\AspireApp1.Web\bin\Debug\net8.0\AspireApp1.Web.dll
  AspireApp1.AppHost -> D:\Work\temp\aspire\AspireApp1\AspireApp1.AppHost\bin\Debug\net8.0\AspireApp1.AppHost.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:04.04
PS D:\Work\temp\aspire\AspireApp1\AspireApp1.AppHost> dotnet run
Building...
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.2.0+75fdcff28495bdd643f6323133a7d411df71ab70
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: D:\Work\temp\aspire\AspireApp1\AspireApp1.AppHost
fail: Aspire.Hosting.Dcp.the program finished with an error[0]
      {"ExitCode": 1, "error": "could not determine installed DCP extensions: CreateFile C:\\Users\\Tibold\\.dcp\\ext: The system cannot find the file specified."}
fail: Microsoft.Extensions.Hosting.Internal.Host[11]
      Hosting failed to start
      System.OperationCanceledException: The operation was canceled.

msbuild.zip

Oct 05 '24 07:10 tibold

Did some digging. 😇 The binlog did indeed help. Didn't think to look at it before, although the structured log viewer is one of my pinned tools. 🙈

The culprit seems to be the generated assembly attribtues. The code is looking for the following:

internal class ConfigureDefaultDcpOptions(
    DistributedApplicationOptions appOptions,
    IConfiguration configuration) : IConfigureOptions<DcpOptions>
{
    private const string DcpCliPathMetadataKey = "DcpCliPath";
    private const string DcpExtensionsPathMetadataKey = "DcpExtensionsPath";
    private const string DcpBinPathMetadataKey = "DcpBinPath";
    private const string DashboardPathMetadataKey = "aspiredashboardpath";

However, the SDK target on my machine is doing something different:

  <Target Name="SetOrchestrationDiscoveryAttributes" BeforeTargets="GetAssemblyAttributes" Condition=" '$(DcpDir)' != '' ">
    <PropertyGroup>
      <DcpDir>$([MSBuild]::EnsureTrailingSlash('$(DcpDir)'))</DcpDir>
      <DcpExtensionsDir Condition=" '$(DcpExtensionsDir)' == '' ">$([MSBuild]::NormalizePath($(DcpDir), 'ext'))</DcpExtensionsDir>
      <DcpExtensionsDir>$([MSBuild]::EnsureTrailingSlash('$(DcpExtensionsDir)'))</DcpExtensionsDir>
      <DcpBinDir Condition=" '$(DcpBinDir)' == '' ">$([MSBuild]::NormalizePath($(DcpExtensionsDir), 'bin'))</DcpBinDir>
      <DcpBinDir>$([MSBuild]::EnsureTrailingSlash('$(DcpBinDir)'))</DcpBinDir>
      <DcpCliPath Condition=" '$(DcpCliPath)'  == '' ">$([MSBuild]::NormalizePath($(DcpDir), 'dcp'))</DcpCliPath>
      <DcpCliPath Condition=" '$(OS)' == 'Windows_NT' and !$(DcpCliPath.EndsWith('.exe')) ">$(DcpCliPath).exe</DcpCliPath>
    </PropertyGroup>

    <ItemGroup>
      <AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
        <_Parameter1>dcpclipath</_Parameter1>
        <_Parameter2>$(DcpCliPath)</_Parameter2>
      </AssemblyAttribute>
      <AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
        <_Parameter1>dcpextensionpaths</_Parameter1>
        <_Parameter2>$(DcpExtensionsDir)</_Parameter2>
      </AssemblyAttribute>
      <AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
        <_Parameter1>dcpbinpath</_Parameter1>
        <_Parameter2>$(DcpBinDir)</_Parameter2>
      </AssemblyAttribute>
      <AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
        <_Parameter1>apphostprojectpath</_Parameter1>
        <_Parameter2>$(MSBuildProjectDirectory)</_Parameter2>
      </AssemblyAttribute>
    </ItemGroup>
  </Target>

Notice the "DcpExtensionsPath" vs dcpextensionpaths.

The following target in the apphost csproj makes my project boot:

	<Target Name="FixAspire" DependsOnTargets="SetOrchestrationDiscoveryAttributes" BeforeTargets="GetAssemblyAttributes">
		<ItemGroup>
			<AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
				<_Parameter1>DcpExtensionsPath</_Parameter1>
				<_Parameter2>$(DcpExtensionsDir)</_Parameter2>
			</AssemblyAttribute>
		</ItemGroup>
	</Target>

What I don't quite understand yet, is how another machine boots Aspire.

Oct 05 '24 16:10 tibold

same issue,how to fix it ?

Dec 12 '24 09:12 Broderick890

info: Aspire.Hosting.DistributedApplication[0] Aspire version: 9.0.0+01ed51919f8df692ececce51048a140615dc759d info: Aspire.Hosting.DistributedApplication[0] Distributed application starting. info: Aspire.Hosting.DistributedApplication[0] Application host directory is: G:\Source\Test\AspireApp1\AspireApp1.AppHost fail: Aspire.Hosting.Dcp.the program finished with an error[0] {"ExitCode": 1, "error": "could not determine installed DCP extensions: CreateFile C:\Users\Administrator\.dcp\ext: The system cannot find the file specified."}

Dec 12 '24 09:12 Broderick890

In my case, the issue was with the symbolic link. I had created a link for the folder C:\Users[username].nuget to another drive due to a lack of space. After removing the link, it started to work.

Dec 12 '24 10:12 gmatv

In my case, the issue was with the symbolic link. I had created a link for the folder C:\Users[username].nuget to another drive due to a lack of space. After removing the link, it started to work.

wow, amazing! I had created a link for the nuget package folder. It works when i remove the link and change the package folder to other drive ! Thank you!

Dec 12 '24 11:12 Broderick890

I have this issue as well. Initially, I set my NUGET_PACKAGES environment variable to a symlink path pointing to a Dev Drive. I changed the path to point to the dev drive directly and now it works.

Dec 13 '24 14:12 almostchristian

I can confirm that dev drive is the problem... NUGET_PACKAGES set to c:\<where my dev drive is mounted>\.nuget cannot start aspire. With it set to d:\.nuget, it works

Dec 17 '24 13:12 davhdavh

I feel as though this is a bug in dcp itself - i.e., it fails to resolve the symlink.

Like the others in this thread, I have redirected my global nuget cache to another drive.

https://github.com/dotnet/aspire/blob/89e329c95ebac571567a58f27bfeb462d8e6b35d/Directory.Build.props#L47 https://github.com/dotnet/aspire/blob/89e329c95ebac571567a58f27bfeb462d8e6b35d/src/Aspire.Hosting.AppHost/build/Aspire.Hosting.AppHost.targets#L195-L201 This resolves to: ...and can be accessed in Explorer:

At runtime these get read seemingly correctly:

...then boom!

Dec 23 '24 01:12 RussKie

I think the original post here from the OP was a bit different but had similar symptoms, in their case it was more related to the fact that the apphost package and the dcp package they were referencing was not in sync (leading to an attribute name mismatch). That is now fixed in 9.0 as we make sure those versions match now.

Can someone with the issue around devdrive please share an exact series of repro steps so that we can take a closer look at it?

Jan 16 '25 22:01 joperezr

@DamianEdwards do you have a devdrive setup?

Jan 17 '25 05:01 davidfowl

@davidfowl I do but I just set the NUGET_PACKAGES environment variable to D:\packages\nuget where D: is my dev drive. I'm not doing any folder-level mounting. I seem to recall @bradwilson hit this or a similar issue at some point with mounted dev drive volumes too.

Jan 18 '25 01:01 DamianEdwards

TBC I don't believe this is a Dev Drive problem, but rather a problem when redirecting your nuget packages location to another location via a symlink. If you mount a Dev Drive as a directory on an existing volume, then you'll end up with a symlink, but it's not the Dev Drive that's the issue. You can redirect any folder to another via a symlink.

Jan 18 '25 01:01 DamianEdwards

I opted for a junction point (made via mklink /J) from C:\Users\bradwilson\.nuget to E:\NuGet so I didn't have to suffer with things that don't properly support NUGET_PACKAGES and/or symlinks.

Jan 18 '25 02:01 bradwilson

I have a junction too, but for me it fails.

> dir /AL /S C:\Users\user

 Volume in drive C is Windows
 Volume Serial Number is F07C-1234

 Directory of C:\Users\user

13/08/2024  12:46 PM    <JUNCTION>     .nuget [D:\NuGet]

Jan 28 '25 06:01 RussKie

I don't use Aspire, so perhaps the issue is with Aspire as opposed to NuGet or .NET. I have not experienced any issues with any other dotnet tooling (including Visual Studio) while using a junction point.

Jan 28 '25 07:01 bradwilson

Should also mention that I do not set NUGET_PACKAGES.

$ dir env:\NU*

Name                           Value
----                           -----
NUMBER_OF_PROCESSORS           32

Jan 28 '25 07:01 bradwilson

Should also mention that I do not set NUGET_PACKAGES.

I don't either:

PS D:\> dir env:\NU*

Name                           Value
----                           -----
NUMBER_OF_PROCESSORS           20
NugetMachineInstallRoot        D:\NugetCache

I don't use Aspire, so perhaps the issue is with Aspire as opposed to NuGet or .NET. I have not experienced any issues with any other dotnet tooling (including Visual Studio) while using a junction point.

As I stated above, I suspect this is a dcp-related issue.

Jan 28 '25 21:01 RussKie

@karolz-ms

      {"ExitCode": 1, "error": "could not determine installed DCP extensions: CreateFile C:\\Users\\Tibold\\.dcp\\ext: The system cannot find the file specified."}

I blame golang 😄

Jan 29 '25 00:01 davidfowl

I can confirm this is most likely a DCP issue and should be a pretty easy fix. We are using an API that is documented to not follow symbolic links (incl. junctions on Windows). We just probably to call another API to get to the target path before looking for extensions.

Jan 29 '25 01:01 karolz-ms

TBC I don't believe this is a Dev Drive problem, but rather a problem when redirecting your nuget packages location to another location via a symlink. If you mount a Dev Drive as a directory on an existing volume, then you'll end up with a symlink, but it's not the Dev Drive that's the issue.

I just ran into this problem. I have a Dev Drive (in a separate partition) mounted at C:\Code and NUGET_PACKAGES set to C:\Code\Cache\NuGet. Under this configuration, Aspire won't start.

In Disk Management, I added the drive letter D: to the Dev Drive partition, then set NUGET_PACKAGES to D:\Cache\NuGet. (No part of this path is a symlink.) Aspire now loads.

(Not sure if this will work for those who have a Dev Drive in a VHD.)

Feb 07 '25 04:02 bgrainger

FWIW, the issue was fixed (🤞), if all goes well, it'll be available in the next release. (And if not, then in the one that follows).

Feb 07 '25 05:02 RussKie

I know I'm late to the party. 🙈

My workaround for this issue was the following target in the Aspire host project.

    <Target Name="FixAspire" DependsOnTargets="SetOrchestrationDiscoveryAttributes" BeforeTargets="GetAssemblyAttributes">
        <!--Aspire not finding extensions path workaround-->
        <ItemGroup>
            <AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
                <_Parameter1>DcpExtensionsPath</_Parameter1>
                <_Parameter2>$(DcpExtensionsDir)</_Parameter2>
            </AssemblyAttribute>
        </ItemGroup>
    </Target>

Just in case it's still useful for some. 😇

Feb 20 '25 12:02 tibold

A little update - I still had troubles running Aspire even after the fix. It turned out that the dcp wouldn't work for the directory junctions (i.e., created with mklink /J) that pointed to a different drive; for junctions located on the same drive - no errors. The workaround is to use directory symbolic links (i.e., created with mklink /D).

Mar 16 '25 23:03 RussKie

aspire aspire copied to clipboard

Aspire does not launch

Is there an existing issue for this?

Describe the bug

Expected Behavior

Steps To Reproduce

Exceptions (if any)

.NET Version info

Anything else?

aspire
aspire copied to clipboard