Skip to content

Conversation

@ericstj
Copy link
Member

@ericstj ericstj commented Sep 23, 2021

We don't have any way to suppress validation rules in our installers (or provide any other parameters to the WiX tools). I'm a bit surprised we decided to write our own wix.targets rather than rely on those that shipped with wix, but I'm not going to change that here.

I'm adding some pass-through properties so that we can define our own additional arguments to the common wix tools we use to build installers.

I specifically needed this to suppress ICE80: This 32BitComponent CCCCCCC uses 64BitDirectory DDDDDD. Our product explicitly has a design where it will store it's installation location (which may be a 64-bit directory for the 64-bit product) in the 32-bit registry hive. I hit this when moving the registry key to the host, we didn't hit it in the SDK since the SDK "hid" this from the ICE validation by laundering the directory as a property instead. I could workaround it by laundering through a property but that's unnecessary runtime complexity. Better to just suppress the overzealous build time validation.

@ericstj
Copy link
Member Author

ericstj commented Sep 23, 2021

Actually after writing this up I realized the ICE wouldn't likely be looking at the registry value, instead it was looking at the component directory. So I can fix that by changing it. I still think this is a valuable addition but I no longer need it for the the reason I opened this PR.

@jkoritzinsky
Copy link
Member

jkoritzinsky commented Sep 23, 2021

For reference, we added our own wix.targets because initially Wixproj projects couldn’t be built with the .NET SDK. When I made the new Installers targets, I kept it as it was because it made it much simpler to keep a simple entry point for all of our installers.

@ericstj
Copy link
Member Author

ericstj commented Sep 23, 2021

initially Wixproj projects couldn’t be built with the .NET SDK

I see. That still appears to be the case. Tried to hack it with /p:WixTargetsPath="C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix.targets" /p:WixInstallPath="C:\Program Files (x86)\WiX Toolset v3.11\bin" but MSBuild fails with

error MSB4062: The "GenerateCompileWithObjectPath" task could not be loaded from the assembly C:\Program Files (x86)\WiX Toolset v3.11\bin\WixTasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

I do appreciate that we don't require desktop MSBuild for building runtime installers. I suppose there's minimal complexity in these targets since they just plumb some items to the exes. Thanks for sharing the history.

@joeloff
Copy link
Member

joeloff commented Sep 29, 2021

@ericstj I noticed you were running with 3.11. We should be using 3.14. I think today, ASP.NET is the only repo that builds using a proper .wixproj - that was partly for what you mentioned, but also because I liked using VS + intellisense

@ericstj
Copy link
Member Author

ericstj commented Sep 29, 2021

I see, I just installed the latest a while back from here:
https://wixtoolset.org/releases/
image

I think moving the installer SDK onto some common targets / tasks is interesting but isn't the goal of this PR. I believe this PR is still interesting today (even though I don't need it imminently).

Can folks who own this make the call of merge/close?

@ericstj ericstj merged commit 6eb4672 into dotnet:main Sep 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants