Harvesting a .csproj with heat.exe in Visual Studio 2008 and WiX(v3) - wix

I found that Wix v3 uses a tool (heat.exe) to "harvest" information into WiX fragments. Either I am looking in the wrong location, or this is thinly documented.
What is the best way to auto-generate a WiX fragment (likely using heat.exe) for a complex folder structure that contains media files:
Of varying types (ico/png/xaml/etc)
That may change regularly (names/locations/adds/removes)
That are classified as "Content" and included in a .csproj
such that they can be built into an installer via WiX and would withstand upgrades and patches with decorum?
Background Information
I found heat.exe, which seems to solve the autogenerate WiX fragment requirement
In getting the "dir" harvester working, I noticed the "project" harvester (commandline help)
Media is already in C# project file, and so noted that "-pog:Content" might do very well
Cursory search found out of date documentation that didn't mention "project" harvester
Realized entire project installer could probably done with "project" harvester, but was unsure how well this was supported, and what the pitfalls were.
Saw the generation of "PUT-GUID-HERE" and realized that autogeneration of guids would likely have upgrade/patch implications.
Realized that there must be people who use these tools for similar purposes and could probably point me in the right direction.
It was (fairly) pointed out that v3 is not yet "done" (thus the scarceness of documentation and tutorials). The sense that I get now is that it is non-trivial to automate this in my build scripts, and the tools are growing right now to ease this.

In my experience John Robbins' Paraffin solves alot of the issues with tallow.exe (heat.exe in v3). I'm not sure if Paraffin plays nicely with v3, but it might be worth checking out.
FYI, I've used Paraffin in a build process and it allowed me to remove the previous 2-3 step cleanup process that involved a powershell script.

For the upgrade implications of auto-generated setups, read this. The take-home message:
Windows Installer doesn’t let you
remove components in a minor upgrade
It is hard to guarantee that components continue to exist if you generate your setup automatically. Therefore you have to chose between auto-generation of components and the ability to do minor upgrades.
If you have some auto-generated components, then just stick to major upgrades. You can use this sample by Rob as an example.

Thanks for the background, I wasn't aware that they were working on a new version of Wix. According to the project page, it isn't RTM yet, so that may explain the problems you're having. I hope to hear from the WIX developers in one of the replies.
I can't help you use the under-development heat.exe features. However, I have been in your situation and my solution was to create a tool that took directory and file information as input and generated valid wix project files as output. A .vsproj file is just an XML file, and you can use XSL, C#'s LINQ, PowerShell, or a number of other tools to do the work. I personally have used (pre-LINQ) C#/XMLDOM to parse VS project files for this purpose.
Good Luck,
Dave

For documentation, check out the help file that is installed with WiX - WiX.chm provides the most up to date information (along with the command line -help option).

Related

Install file with the same name on different OS's

I have a question about the rules organizing resources into components.
What I want to do is the following; There are two files (both 64bit) with the same filename but in different source locations and with different component GUID's;
C:\data\win7\driver.sys
C:\data\win10\driver.sys
I want both included in the installer and when the installer runs decide depending on the OS which of these two files will be installed in the same location:
C:\Program Files\MyProgram\driver.sys
Is this a violation of the rules regarding the components? (the main one applying would be the first one I would say:)
"Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies."
https://learn.microsoft.com/en-us/windows/desktop/Msi/organizing-applications-into-components
Actual Answer: Yes, installing different files to the same absolute path is indeed a violation of the MSI component rules - in
theory. As you have discovered reading the documentation. However,
seeing as only one file will make it onto the box, it is all semantics
really, there will never be two files installed. Still, the MSI will
probably not validate - you will see validation errors.
I am not sure of the technical implications, but could you make the
file name different based on OS? Then you simply put the files in
separate components and use different component GUIDs and condition
the component for installation or not. Full compliance instantly.
With all that said, it seems driver files are to be installed using
INF-files in standalone packages in the future. Please read below.
Component Rules, Pragmatically: This is a well-known problem indeed. I have this old answer that might be helpful: Change my component GUID in wix? It describes how the component rules work in practice, and how the idea is that you reference count an absolute path, and not a file per-se. Please read it to make it clearer. More links in this answer.
Driver Installation: We are supposed to know how to do this, but the rules keep changing (and another answer). Essentially drivers are to be distributed via Windows Update, or at least via a standalone package without the need for an installer in the future (until Microsoft change their mind again?). Windows Hardware Dev Center dashboard. As far as I understand the installation is INF-based (as before).
Question: Are you sure about that installation location? What does the documentation say? I thought sys files should go primarily to the Windows folder? Or the WinSxS folders (side-by-side win32 assemblies). As you understand driver installations confuse us all.
Windows 10 Detection: It appears to be a challenge to detect Windows 10 due to the new "evergreen versionlessness" of Microsoft. I have this old answer written up to summarize my current understanding of it: Windows 10 not detecting on installshield. Deployment tools such as Advanced Installer does the job for you and detects Windows 10 with simple measures. Not sure what Installshield does. The linked answer lists a few approaches to detect the version yourself - not sure which is the saner approach. Please read (and also please report any interesting findings when you have a successful package).

How to install previous releases of wix toolset

I am sorry for this stupid question, but I really need to install version 3.9 of the Wix Toolset. I can only find version 3.10 and 3.11. There is a link on the website to download older archives (also for 3.9rc2), but in this 1.2Gb file I cannot find an installer.
Please do not tell me to install the latest version, I have my own reasons for 3.9 that goes beyond the scope of this question. Any help is truely appreciated.
I should leave this for the WiX guys to answer, but maybe you are very busy and just need to test something?
Building it yourself from the sources isn't an option is it? https://github.com/wixtoolset/wix3/releases (towards the bottom, click the blue image - it says "Show 5 other tags" here). Sounds painful to work that out...
The 3.9 binaries seem to be here (looks like R1): https://github.com/continuoustests/ContinuousTests/tree/master/Installer/ContinuousTests.WixInstaller/wix39-binaries, but not as an installer file. Maybe you just need to test something quickly? If so, obviously please accept your own risk here, I am not sure what these files really are.
I hope I haven't linked to something that is problematic, just delete the whole answer if this should be the case (i.e the binaries pointed to should not ever be used - for some reason, etc...).
I recently had a need to get the old wix38.exe installer for legacy project maintenance, and it was a pain. Tom Blodget's comment above was the key on how to find the required file from the CodePlex archive.
Because there are likely to be other people in the future who require access to these things, I've created a github repository https://github.com/CasaDeRobison/wixtoolset-codeplex that includes the state of the git repository from the CodePlex archive and also makes available the various files from those releases at https://github.com/CasaDeRobison/wixtoolset-codeplex/tree/master/archived-stable-versions
Hopefully others will find this useful as well so that we don't all have to collectively puzzle this out if we have a need for this older software.

BundleTransformer with LESS - Decent Example Exists anywhere?

I really like the idea of this BundleTransformer plugin from NuGet, and I see that they have LESS support. But ...
After weeks of trying, I cannot find any decent example of how to use it. The documentation is unclear, to say the very least. This is the closest I could find, which does not compile or work.
who-could-ask-for-more-with-less-css
Well, the simple answer is that I could ask for more.
Can someone please assist me with the simple task of creating a bundle that has .less files in it, that will run? I am completely lost.
I would suggest reading the wiki page for bundle transformer and also, as the wiki page suggests, make sure you are familiar with ASP.NET bundling and minification.
If you follow the examples of usage you should be up and running.
I know this is an older post but figured I'd chime in. The Bundle Transformer Codeplex discussion board (Feb 2015) mentions that BundleTransformer is no longer considered a modern client-side build tool and they are recommending you go with Gulp or Grunt - which both have support starting in Visual Studio 2013.3 via VSIX extensions and more baked in to VS2014. FYI -This Scott Hanselman post explains how to get up and going with Grunt and Gulp in Visual Studio. I think if you're using BundleTransformer for simple Less compilation it works fine, but doesn't allow you to do things like generate CSS Sourcemaps which make your browser's dev tools aware of the Less source files, which in my humble opinion is critical for using a CSS preprocessor - the ability to see the LESS line numbers of your source files in the styles pane.

Chaining an installer for an exe and msi

I have written a plugin for an application which has an installer as an executable. My plugin is installed using an msi, written in wix. We've now been given permission to distribute the two together. Ideally, this would be in a single file with two installations. Both parts would need to be updated seperately, particularly the main program, I have read that this restricts the methods of installation.
I'm having trouble installing the main program first, then the plugin. I have tried including this main exe in the wix as a custom action, but I'm worried that this will mess things up when either program needs updating. I have seen something called an MsiEmbeddedChainer but can't seem to find anywhere that describes how to implement it.
Any advice, or pointers of useful articles would be greatly appreciated.
Most of what you need to know is linked from the Not supported in Windows Installer 4.0 document, but it will likely still take a lot of trial and error. This blog post has a lot of interesting points to help with rough patches along the way. However let me warn you that my experience with InstallShield has shown that MsiEmbeddedChainer chaining is not as reliable as bootstrap chaining, at least in environments with Terminal Services.

Multiple IDE project files

We are currently working in a team where we use both Visual Studio and Code::Blocks, is there a way to replicate changes between those project files? So if one adds a file to the project file it will also get adjusted in the project file of the other IDE?
Please note: We want our project to work on multiple IDE's, platforms and compilers. Thus a general solution is welcome too.
I assume you're using a VCS? If so my intuition would be to write a script that syncs up your project files (based on modification date?) and run it as a checkin hook if any of the project files are changed in the commit.
http://wordaligned.org/articles/a-subversion-pre-commit-hook
Well this sounds like exactly the type of problem CMake was created to solve. There is definitely a learning curve which I blame mainly on the obtuse documentation but CMake is used in a lot of open source projects now, such as KDE, OGRE and many, many others so there are a lot of usage examples out there. There is also a basic tutorial here.
CMake uses it's own syntax (which is fairly complex though still easier than autotools in my opinion) which is used with project file generators, which supports make, visual studio, codeblocks, eclipse and possibly others. It also has a installer generator which can make NSIS installers, Mac OS X bundles and debian/red hat packages (and again, possibly others) which I find quite useful.