Unable to repair .NET 5 SDK with error "Failed to find payload: AspNetCoreSharedFramework_x64"

[augustoproiete]

Running dotnet-sdk-5.0.100-win-x64.exe to perform a repair.

[1BB4:146C][2020-11-12T13:06:58]e000: Error 0x80070002: Failed to find payload: AspNetCoreSharedFramework_x64 in working path: C:\Users\augustoproiete\AppData\Local\Temp\{482F5E84-80CE-4DA0-A5AB-6EBF3622BB3D}\AspNetCoreSharedFramework_x64 and unverified path: C:\ProgramData\Package Cache\.unverified\AspNetCoreSharedFramework_x64
[1BB4:146C][2020-11-12T13:06:58]e000: Error 0x80070002: Failed to cache payload: AspNetCoreSharedFramework_x64
[2EB8:1088][2020-11-12T13:06:58]e314: Failed to cache payload: AspNetCoreSharedFramework_x64 from working path: C:\Users\augustoproiete\AppData\Local\Temp\{482F5E84-80CE-4DA0-A5AB-6EBF3622BB3D}\AspNetCoreSharedFramework_x64, error: 0x80070002.
// ...
[1BB4:1BA4][2020-11-12T13:07:50]e000: Error 0x80070643: Failed to run maintanance mode for MSI package.
[1BB4:1BA4][2020-11-12T13:07:50]e000: Error 0x80070643: Failed to execute MSI package.
[2EB8:3110][2020-11-12T13:07:50]e000: Error 0x80070643: Failed to configure per-machine MSI package.
[2EB8:3110][2020-11-12T13:07:50]i319: Applied execute package: AspNetCoreSharedFramework_x64, result: 0x80070643, restart: None
[2EB8:3110][2020-11-12T13:07:50]e000: Error 0x80070643: Failed to execute MSI package.

---

Full log: dotnet-sdk-5.0.100-win-x64-repair.log.zip

[Dotnet-GitSync-Bot]

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.

[augustoproiete]

@blowdart FYI, I created the issue in the aspnetcore repo after seeing that a very similar issue (dotnet/runtime#517) was moved to the aspnetcore repo (#19536).

[blowdart]

Hah. We don't build the SDK, so I moved it here.

[blowdart]

@joeloff Where would be the best place for this?

[joeloff]

Move it to the installer repo. There should be log files for the MSI in the %temp% folder

[joeloff]

@augustoproiete Do you have the log from the initial install, before you tried to repair?

[augustoproiete]

@joeloff I'm not sure I do as I never installed the .NET 5 SDK myself... It got automatically installed with upgrading Visual Studio to v16.8.0 (and since then I also upgraded VS to v16.8.1). But I can look for them if you can tell me where to look for them, and possible file names.

[joeloff]

I see, so you installed VS (which installed the SDK), then downloaded and ran the standalone installer?

Was the 16.8.1 update applied prior to this failure?

[augustoproiete]

I see, so you installed VS (which installed the SDK), then downloaded and ran the standalone installer?

Correct.

Was the 16.8.1 update applied prior to this failure?

I don't think it was, but can't be 100% sure as the 16.8.1 update came out around the time I opened this issue. If there's a log I can check, let me know.

[joeloff]

Thanks @augustoproiete Let me dig a bit further and see if I can repro this. It might be a simple issue like just deleting the cache folder for the ASP.NET Core MSI, but I noticed that it tried to use both the user local and machine cache, so I want to be sure before suggesting any actions.

[joeloff]

I've been able to reproduce this. The problem is with one of the installer file names that's different in the standalone bundle compared to VS (the files are binary matches). In this scenario, SEC REPAIR kicks in and can't resolve the installer source. Even if you place the installer in the SEC REPAIR exclusion list, it will resolve to the correct cache path, but then fail to resolve the filename.

Right now, installing the 5.0 SDK through VS, then applying the standalone installer and doing a repair from the latter will not work. There might be a way to do fool the installer by editing some other registry keys, BUT, when you repair VS it will be in the same situation and then fail to repair.

I'm going to move the issue to ASP.NET Core and we can get this addressed for the next release.

[joeloff]

@wtgodbe Can you take a look. The problem is that when the shared wixlib is built, the ASP.NET Core runtime MSI is renamed to a generic, non-versioned name, e.g. AspNetCoreSharedFramework-x64.msi.

Previously this wasn't a problem because the same wixlib was consumed by the SDK which also went into VS. We should instead not rename the file, but keep the original filename of the MSI, e.g. aspnetcore-runtime-5.0.0-rtm.20526.5-win-x64.msi

This will also be an issue for 2.1 and 3.1 when it comes to VS2019

[wtgodbe]

Unfortunately don't have the bandwidth today, and I'm OOF until after thanksgiving - I can take a look when I get back

[joeloff]

yeah, that's fine. If I get a chance before then I'll submit a PR

[augustoproiete]

Great news! Thank you so much @joeloff for getting to the bottom of this so quickly!

[jayobrien]

I have the same issue installing to visual studio desktop application. Target Framework would not give 5.0 64x as an option after I installed it successfully separately from VS. I clicked on Install other Frameworks and it asked me if I wished to repair 5.0. I clicked on repair and received the message.

[wtgodbe]

#28298