Deeply nested project references are missed

[jorge-barreto]

First of all, I want to thank @chrisoldwood for this great tool.

Context

I was recently put into a position where I had to migrate a complex legacy .NET 4.8 system to be built in AWS CodeBuild. Long story short, I found it impossible to install the Microsoft Visual Studio Installer Projects build system in the CodeBuild environment. This led me to explore other solutions, eventually landing on vdproj2wix. Corporate concerns prevented me from modernizing to any other installer system, and so I landed on an automated solution where we generate wix files on the fly at build time and use them to generate the MSIs which are then deployed to our servers.

Issue

This worked well, but I quickly realized that there were some shortcomings in the tool. In truth, these shortcomings emerge from the way that vdproj files are designed, but that is neither here nor there. In short, I found that deeply nested project and package references were not accurately captured by the tool, leading to incomplete installers. I can't share the original code due to license concerns, but here is a brief, simplified sketch of the dependencies:

InstallerProject.vdproj
|
├─ BaseProject.csproj (WinExe Application)
|
├── CoreLibrary.csproj
│ ├── Cryptography Package
│ ├── PGP Encryption Library
│ └── Utility Libraries
│
├── Data.csproj
| └── AWS SDK Libraries
│
└── Infrastructure.csproj
  ├── CoreLibrary (shared dependency)
  └── AWS SDK
    ├── Core SDK
    ├── Secrets Management + Caching
    ├── Parameter Store
    └── Authentication Services

Passing InstallerProject.vdproj to vdproj2wix produced an MSI which was missing the AWS SDK references, as well as the crypto references in the CoreLibrary.

Proposed Solution

I implemented a function, Get-ProjectReferences, which, given a project file, will recursively trawl the referenced projects in order to generate a more complete wix file. I also updated certain aspects of the script to ensure that it works with the latest wix version 4.

I'm not sure if this is a use case which you (@chrisoldwood) want to cover in vdproj2wix, but I am happy to contribute my code if so. I will open up a PR with the relevant diff so that it can be reviewed, if there is any interest.

[chrisoldwood]

I'm not sure if this is a use case which you (@chrisoldwood) want to cover in vdproj2wix, but I am happy to contribute my code if so. I will open up a PR with the relevant diff so that it can be reviewed, if there is any interest.

That sounds like a very useful addition and I'd be happy to accept a PR. I haven't used it myself since I originally wrote it way back in 2011 but the fact people still run across it means I'm happy to continue supporting it.

The most important thing for me to accept a PR is that it comes with some kind of test .vdproj file (like I added to the Tests folder) which I can use to validate future changes. Obviously you can't (and shouldn't) provide your real-world file, but if you could create a bare-bones example with the relevant extra section(s) that would be brilliant, plus whatever you added code-wise for Get-ProjectReferences.

Ideally the WiX v4 fixes would be a separate PR too so that I can update the existing test cases or see if I need to add a -wix-version switch or something. (I'm still using v3.11 for my own tool MSIs but maybe this is the impetus I need to upgrade 🙂.) However, I appreciate that might be a lot of extra effort, so feel free to submit a single PR and I can hopefully pull out what I need from there.

Thanks for taking the time to write-up such a detailed issue.