Installer/finalizer in c#

[kasperk81]

TODOs:
- [ ] get WixToolset.Dtf.WindowsInstaller (https://www.nuget.org/packages/WixToolset.Dtf.WindowsInstaller/4.0.6) uploaded to one of dotnet nuget feed and undo NuGet.config change

• adjust <FinalizerExe>$(ArtifactsDir)bin/finalizer/$(Architecture)/$(Configuration)/bin/finalizer.exe</FinalizerExe> in GenerateMSIs.targets
• manual testing

fix #43876

[joeloff]

What is the size of the EXE? We need to ensure that the static SDK does not exceed 250MB - that's historically been a tripwire when we see a noticeable increase in download failures, especially outside North America.

It would be good to ensure that the logging mechanism preserves the structure logging that dutil provides - we chose the C/dutil implementation specifically for size and the logging. The other obstacle is the WiX version. There are very hard requirements about the copy we're using currently and until we wrap up the v5 migration work, we'll probably have to sit on this PR.

As for the pending reboot change - we don't care about what the registry says too much. What the finalizer is doing is passing the exit code from the MSI packages back to the bundle engine if it removed any of them.

Do appreciate your initiative - we've talked about moving this to managed single file executable before

[kasperk81]

The AOT-published finalizer.exe binary for win-x64 comes in at 2MB. This setup skips the need for C++ and CMake in dotnet/sdk, making it way easier to debug and maintain the C# code, just like the rest of the repo. Plus, you can use dotnet run for quick local testing, which keeps the workflow nice and simple.

The version limitations are a bit of a drawback, but this is just an initial idea. We can fine-tune it down the line once those version issues are sorted out.

[joeloff]

The AOT-published finalizer.exe binary for win-x64 comes in at 2MB. This setup skips the need for C++ and CMake in dotnet/sdk, making it way easier to debug and maintain the C# code, just like the rest of the repo. Plus, you can use dotnet run for quick local testing, which keeps the workflow nice and simple.

The version limitations are a bit of a drawback, but this is just an initial idea. We can fine-tune it down the line once those version issues are sorted out.

This sounds very promising, thank you

[kasperk81]

@joeloff if you like to test this branch, download https://www.nuget.org/api/v2/package/WixToolset.Dtf.WindowsInstaller/4.0.6 at c:\temp\packages\ and run .\build.cmd -c Release. it'll be generated at $(ArtifactsDir)bin\finalizer\$(Configuration)\$(SdkTargetFramework)-win-$(Architecture)\publish\finalizer.exe

[joeloff]

@kasperk81 thank you for all the updates. I was out yesterday. Probably one or two more things to address. I'll try and do another pass later tonight

[kasperk81]

new error after merge from main

D:\a_work\1\vmr\src\sdk\artifacts\sb\package-cache\microsoft.dotnet.ilcompiler\10.0.0-alpha.1.25060.15\build\Microsoft.NETCore.Native.Publish.targets(80,5): error : Overriding System.Private.CoreLib.dll with a newer version is not supported. Attempted to use D:\a_work\1\vmr\src\sdk\artifacts\sb\package-cache\microsoft.netcore.app.runtime.win-x64\10.0.0-ci\runtimes\win-x64\lib\net10.0\System.Private.CoreLib.dll instead of D:\a_work\1\vmr\src\sdk\artifacts\sb\package-cache\runtime.win-x64.microsoft.dotnet.ilcompiler\10.0.0-alpha.1.25060.15\sdk\System.Private.CoreLib.dll. [D:\a_work\1\vmr\src\sdk\src\Installer\finalizer\finalizer.csproj]

@ViktorHofer any recent work that might explain it?

[ViktorHofer]

No idea. Given that this is an ilcompiler error, I would ask @MichalStrehovsky or @jkoritzinsky.

[jkoritzinsky]

My guess is that now you need a live ILCompiler instead of using the LKG one.

[MichalStrehovsky]

@ViktorHofer any recent work that might explain it?

This is from dotnet/runtime#109988. Looks like we're in a situation where CoreLib is newer than the compiler.

CoreLib must version with the compiler. These two out of sync would kind of work most of the time, but there would be updates from dotnet/runtime when it would break. So this is a good catch.

We need to use CoreLib that is in sync with the compiler. So either use live compiler, or a runtime pack that is the same version as the LKG compiler.

[jkoritzinsky]

I've put out a PR at #45973 that should change the SDK and installer builds to use a live ILC (and crossgen2 while I'm at it)

[kasperk81]

I've put out a PR at #45973

@jkoritzinsky that fixed windows build. resolved merge conflict

@joeloff can you run the test?

[kasperk81]

ping

[ViktorHofer]

just FYI, @joeloff is currently unavailable. cc @marcpopMSFT

[nagilson]

@/joeloff is available now but I think he has a large backlog of stuff

[kasperk81]

@jkoritzinsky new error after merging main

src\sdk\src\Installer\finalizer\finalizer.csproj(0,0): error NU1102: (NETCORE_ENGINEERING_TELEMETRY=Restore) Unable to find package Microsoft.NETCore.App.Runtime.win-x64 with version (= 10.0.0-ci)

it was building on Jan 19 #44611 (comment)