ICE105: nnnn contains msidbCustomActionTypeNoImpersonate execution option. This is invalid for a per user application.

[twest820]

Hi, I've a .wxs which I've updated to use Scope="perUserOrMachine" as it's supported both per user and machine-wide installs for years. This results in the following four warnings from target WindowsInstallerValidation, which seem to be two warnings each raised twice. Even if I up the logs to diagnostic level there's no indication of what 3137 and 3649 are referring to.

1>obj\x64\Debug\Foo.msi : warning WIX1076: ICE105: 3137 contains msidbCustomActionTypeNoImpersonate execution option. This is invalid for a per user application.
1>obj\x64\Debug\Foo.msi : warning WIX1076: ICE105: 3649 contains msidbCustomActionTypeNoImpersonate execution option. This is invalid for a per user application.
1>obj\x64\Debug\Foo.msi : warning WIX1076: ICE105: 3137 contains msidbCustomActionTypeNoImpersonate execution option. This is invalid for a per user application.
1>obj\x64\Debug\Foo.msi : warning WIX1076: ICE105: 3649 contains msidbCustomActionTypeNoImpersonate execution option. This is invalid for a per user application.

How do I diagnose the cause of these warnings and clear them?

Components are installed to the standard directories ProgramFiles64Folder and ProgramMenuFolder, same as the handful of perUserOrMachine examples I can find, so some confusion of user versus machine wide actions seems possible. However, I'm not seeing values in the standard folder enum which work like HKMU does for registry keys.

[nirbar]

Check the custom actions and ensure none has Impersonate="no"

[twest820]

There aren't any custom actions in the .wxs. Impersonate isn't specified.

[barnson]

If you're using extensions, they might add some. Use the Orca tool from the Windows SDK to check the CustomAction table.

[twest820]

No extensions either. The .wxs is here.

[barnson]

netfx:NativeImage is an extension and installing to the GAC is a per-machine operation.

[twest820]

Yep, that's it, thank you. While the .wxs dates back to .NET 4.0, the installed code is now .NET 6.0, meaning dropping ngen might be an option. But I'm also not finding anything in the WiX documentation about ReadyToRun and, from what I can discern, it seems likely dotnet publish is intended to do its own thing separate from Windows Installer packages.

So, if ngen remains relevant, is there a way to ngen in a per user-machine wide install agnostic way? Not spotting anything on this in its docs, the ngen section for .NET detection and installation, and am not having luck with documentation on WiX v4 conditionals or even how to pick up which type of scope (per user or machine) the install's running under. Lots of WiX v3 hits and content back to 2006 to filter out, though, so I might be missing something.

Or, if ngen should be dropped, is there a reasonably turnkey alternative for hoisting JIT that works in an automated way? Don't have resources to develop and maintain low level, custom build steps or custom actions.

[robmen]

from what I can discern, it seems likely dotnet publish is intended to do its own thing separate from Windows Installer packages.

Nope. That is how you build your .NET (Core) applications for distribution (aka: before you package them into an MSI).

if ngen remains relevant

Only for .NET Framework (see below).

way to ngen in a per user-machine wide install agnostic way

Not as far as I understand it. NGen requires the assemblies to be in the GAC, a per-machine resource.

reasonably turnkey alternative for hoisting JIT that works in an automated way

That's more of a question for the .NET team than us. From the WiX documentation you linked to, there is a link to MSDN about NGen that says:

Note: Ngen.exe compiles native images for assemblies that target .NET Framework only. The equivalent native image generator for .NET Core is CrossGen.

[twest820]

Thank you for the reply! Unfortunately GitHub won't let me mark more than one answer.

That's more of a question for the .NET team than us.

Actually both .NET and Visual Studio, I think, if WiX is hands off here. Last I checked the Visual Studio folks were pretty set into publishing being a manual process, which works but is a bit tedious as one does a release build, runs tests, then manually kicks off however many publishes are needed, waits for those to repeat the release build, and then manually builds the WiX installer. On the .NET side the assumption I encountered was one would be scripting against dotnet build, dotnet publish, and whatnot, which is ok for projects large to have at least one person part-time in a build engineer role but often isn't sustainable in small projects. Maybe there's less of a disconnect now but, if so, I'm not having luck finding documented solutions which pull the two together. Most of the hits I get are for modding VS projects to call dotnet publish as a post build step.

If I'm understanding correctly, I think what this amounts to from a WiX perspective is, instead of saying ngen this binary, the .wxs should pick up the ReadyToRun build of the binary from $(var.Project.TargetDir)\publish\<target runtime>. Potential build sequencing fragility around Visual Studio's manual approach to publishing aside, does that sound like a best practice implementation? There doesn't seem to be a turnkey way to tell WiX to pick up a publishing profile.

NGen requires the assemblies to be in the GAC, a per-machine resource.

Since ngen's .NET 4.x specific and nothing older than .NET 6.0 is now recommended for new development I think it's a legacy aside at this point. But, FWIW, I suppose for projects still on .NET 4.7 or 4.8 it'd conceivably be nice to have a way to mark NativeImage as an action to omit in the per-user install case. Seems like a fairly niche case though.

[robmen]

You can add Publish='true' to a ProjectReference in a .wixproj and the WiX build system will publish the target project for you.