I'm using heat.exe to generate WiX file fragments.
I've done this via adding a post build step to my web site project in visual studio, such that every time a build is done, any new files in the web project are picked up and new wxs file fragments are created. These file fragments are copied directly into the wix setup project, such that when the setup project is built, it will include all the newly added content files into the msi.
I noted last time I looked that every time heat.exe regenerates the wxs file fragments, it creates new guids (but apparently not new component ids).
At any rate, I'm very new to WiX/heat, so the question is - should I be autogenerating the wxs files every time, e.g. how will this effect things in production when new versions of the website are released and installed/uninstalled? are there any reasons why I should not be autogenerating and including these file fragments on every build?
There are two main lines of thought on this sort of scenario; which one you follow depends on which risk freaks you out more. Do you worry more that you may not include some changes which become necessary in the future because nobody tells you and you didn't update your one-time generation, or do you worry more that two .msi files created with results from autogeneration will not upgrade well not let you know if important files go missing?
Personally I tend towards believing that autogeneration results in harder-to-fix problems, so I would suggest generating these only when you know something has changed, and then verifying the differences are what you expect.
Related
I would like to create a script that will update files in the (default) install location with files from the source location where needed, based on the .wxs files that I have. I need to get this info from the wxs files, because the installation dir structure differs from the source location dir structure.
This would speed up my development cycle by not requiring a complete MSI uninstall/install when I have only recompiled one DLL for instance.
Is there functionality available in the Wix toolset that can give me a list of corresponding source and destination paths or would I have to implement everything including parsing of the Wix XML files myself?
I did not see anything relevant in the List of Tools section of the Wix documentation.
Alternative Approach: I would suggest using the commercial file and directory syncing and comparison tool Beyond Compare to copy files to the destination directory with ease if this is just for QA. I guess you can use post build steps too, but Beyond Compare is very nice and reliable. It has the features you need for just about anything related to comparison of files and folders (not affiliated). You can let the application just sit there and you can do a full comparison on the fly whenever needed. Essential software for deployment people. Alternatives exist of course (list).
I am new to WiX, but need a complicated scenario!
I manage a modular web application containing multiple WCF Library (i.e. module), and need to put every module as a feature in the final setup.
So I managed a WiX Setup Library for every module which genrates .wixlib files, and a single WiX Setup who references the .wixlib projects, and also will be a one-to-one relation between modules (i.e. .wixlib) and features in the final setup.
The problem arises when there is same files shared among .wixlibs, due to similar File/#Id and Componend/#Id which will be there for those shared files.
P.S: I have used WaX as engine to build .wxs files, which simply uses file name as File/#Id and Component/#Id in the .wxs files.
I beleive there could be two possible workarounds (I could achevei non of them!)
Some way to force WaX generate randome File/#Id and Component/#Id for every file.
The could be a way in Lit.exe (who builds .wixlib) to append a random id to File/#Id and Component/#Id while compiling and generating final .wixlib files.
Any sort of help will be appreciated.
I’m writing an MSI for using WiX 3.0 and I’m trying to figure out how to make it include all but some files from a directory without having to manually specify each and every attribute. Similar to a dynamic pickup in installshield.
An old installer I’m looking at for reference (which uses WiX 2.0) does the following:
A makefile to call a script that will copy all the necessary files to a separate directory structure that emulates how the final product should be installed.
another script to insert the attributes for each of the files in this temp folder to a partially completed wxs file.
WiX runs
I want to avoid this step and was wondering if there were some commands or pre-processor directives to achieve this WiX itself?
Also the 1st step above spits out some generated files (from a tool) which is then included into the wxs file. Is there a way I can emulate that as well?
You need to specify each file.
However, you can use Heat.exe to automatically generate a wxs file you can include as part of your build process.
I cheaped out with a non-solution, and zipped up the directory and it's files in the build script. The advantage of your current method is that MSI is aware of the files and they could potentially be key files (and thus patched/upgraded and/or repaired).
I'd look into saschabeaumont's suggestion about using heat. clearly a better solution
At my current client, we are using CruiseControl.Net for continuous integration. We are building website projects using MSBuild.
The issue that I have run up against is the following: We want to move all code and associated DLLs with every release. However, we also have (sometimes) hundreds of megs of files and images that are unchanged. In the CC.Net world, I will probably split these in to two different builds, one for a site and the other for static content.
What I would like to know is if anyone knows of an MSBuild or CCNet plugin that will allow me to do a binary diff on my static content? I'd like to be able to know if an image has chnaged or been added and then package only the changed/added content up and push them to a QA environment.
I did that with svn logs and MsBuild tasks.
Every time I Deploy the website, I save somewhere the revision number (basically in a flat file).
Then at the next Build-Deploy, I will do a svn log to see the diff between the latest release and now. Then my MsBuild Task takes the svn log xml output, parses it and outputs in another file the interesting static files added/modified/deleted.
Then the usual tasks come in and process only the modified files instead of every file.
That was a huge piece of work (above all with internal logic : our "static" contents are dynamically generated for each environment, each partner and each theme) but it was worth it.
Either way, you can try using a ChecksumCopy, but I don't know if it's less expensive...
Ok, so I've got a somewhat complicated problem with my build environment that I'm trying to deal with.
I have a solution file that contains multiple C# projects which is built by a NAnt script calling MSBuild - passing MSBuild the name of the solution file and a path to copy the binaries to. This is because I want my automated build environment (CruiseControl.Net) to create a folder named after the revision of each build - this way I can easily go back to previous binaries for any reason.
So idealy I have a folder layout like this
c:\build\nightly\rev1
c:\build\nightly\rev2
c:\build\nightly\rev3
...
c:\build\nightly\rev10
etc.
The problem that's arisen is I recently added the latest version of the Unity IoC container to my project, checking it directly out of MS's online SVN repository. What's happening is I have a Silverlight 3 project that references the Silverlight version of Unity but I also have other projects (namely my Unit testing project) that reference the standard (non-Silverlight) version of Unity.
So what happens is since MSBuild is dumping everything into one single folder the Silverlight version of the Unity assembly is overwriting the non-Silverlight version because they have the exact same assembly file name.
Then when CruistControl runs my unit tests they fail because they don't have the proper dependencies available anymore (they try to load the Silverlight specific Unity assembly which obviously doesn't work).
So what I want to do is:
keep my desired output directory
structure (folder\revision)
I don't want to have to manually edit
every single proj file I have as this
is error prone when adding new
projects to the solution
Idealy I would like MSBuild to put everything into a folder structure similar to this:
nightly\revision1\project1
nightly\revision1\project2
nightly\revision1\project3
...
nightly\revision2\project1
nightly\revision2\project2
nightly\revision2\project3
etc
I can't modify the Unity project to give it a different file name because it comes from another SVN repository I cannot commit changes to. I found a similar question posted here and the suggested solution was to use a "master" MSBuild file that used a custom task to extract all the project file names out of the solution then loop over each one building them. I tried that but it doesn't build them in the order of their dependencies, so it fails for my project.
Help?
Firstly I would always have the build server delete the old working copy and check out a fresh copy to avoid any problems with stale artifacts from the previous build.
Next I would have nant or msbuild build the solutions as before with the artifacts from each build going to their local working output folders.
After that I'd move the artifacts from their working paths to their output paths, this shouldn't require digging through the project files since you can just tell msbuild/nant to copy working\project1\bin\release\**\*.* to artifacts\project1\.
The script that does this should ideally be stored along with the source with the main file, e.g. build.nant or build.proj in top level of the trunk.
For third party libraries I would simple include the DLLs directory in your repository. Nothing worse than writing some code and having a third party dependency break your build because of changes on their end.
Simply document the versions of the libraries you are using, and if you must update them, you'll have a better sense of what breaks the build before you even check it in.
Also, doesn't CC.Net automatically handle the providing of releases based on revision? I'm using TeamCity and it keeps a copy of the artifacts of every build.
I highly recommend reading JP Boodhoo's Automating Builds with NAnt blog series. That's been my starting point and have made lots of changes for my own taste. I also highly recommend checking out the builds of many open sources projects for examples. I've learned a lot from the builds of the Castle/Nhibernate/Rhino-Tools stack.