CODEWITHSUNDEEP
tfsmsbuildwix
grinder22
grinder22

Reputation: 573

WiX bootstrapper UI not compiling from TFS build definition

I have a WiX bundle installer in my solution. It consists of several MSI projects and the bootstrapper UI project. When built all at once everything works fine.

With a new requirement to authenticode sign everything, I am trying to split the assembly compilation from the installer compilation, so I can sign in between.

I am trying to do this with two separate build configurations. One that builds only the application assemblies, and another that builds only the installer projects. They both are working properly when I run them by hand from visual studio.

The problem is when I try to call them from separate tasks in a TFS build definition. The assemblies, including the bootstrapper UI, all compile successfully in the first task. But in the second installer only task, the WiX project will try to recompile the referenced bootstrapper UI project and fail with missing type or namespace errors.

I've tried including and removing the boostrapper UI project from the installer only build configuration. I get the same errors in either case. It's the wixproj itself that is kicking off the underlying bootstrapper UI build.

Upvotes: 0

Views: 83

Answers (1)

daughey
daughey

Reputation: 749

Ok, I think this is what you're trying to do, please correct me in the comments and I can refine the answer accordingly.

It sounds like you have a single solution that when built in one Configuration (say, CODE) it will only compile the .net projects and in another configuration (say, PACKAGE), it builds only the WIX projects. I think this separation is part of the problem.

From your description it also sounds like the wix projects have project references to the other code projects (for payload harvesting most likely - but at the very least, establishing build dependency order).

Any project (wix or code) that references another project will automatically cause that project to build - in the absence of solution configuration it will default to using the same configuration as the primary project. This means that if project A has a configuration called CODE and project B references with a configuration called PACKAGE references it, then building project B will cause A to try to build with configuration PACKAGE - if it doesn't have this configuration then it (successfully) won't build and project A will then fail to find the dependencies it expects.

In your solution, you should have two configurations, one of which is a superset of the other. So your CODE configuration for building only code is a subset of the PACKAGE configuration for building your wix projects. When you set this up in configuration manager and build the solution then you guarantee that the projects build with the correct configuration instead of inferring a configuration from the primary.

Then instead of two build steps in your TFS build you can do it as one. If you still need to split it (because you digitally sign the assemblies in between), then know that msbuild does incremental builds by comparing timestamps of inputs to outputs. This means that if you build project A then digitally sign it, building project B (that references A) will attempt to build project A but it will determine that the output of A is newer than the input and not replace the assembly. Ultimately this means it's safe for you to build your solution under configuration CODE, sign the assemblies then build the solution again under configuration PACKAGE (which is a superset of CODE) without the signed assemblies being replaced.

On a related note, the wix targets file has hook points to sign the bundle as part of the wix project build. That may be better than trying to use PowerShell to sign it after the fact.

Upvotes: 0

Related Questions