I have prebuild events on the installer to rebuild the projects with the appropriate configuration etc.
If I right-click build/rebuild on the WiX (3.0) project in visual studio it all builds fine, but if I try to run MSBuild on the wixproj file the pre-build events will throw errors.
I can instead call Candle and Light on the wixproj but it won't run the pre-build events.
The prebuild events rely on the macros provided by VS and I'm not sure how to get around that other than creating another project and basically just use the prebuild event of the project which just screams hack.
Another problem is that I need to feed in a self-updating version number into WiX from the command line.
I was planning on using just a csproj to handle the version number and updating it and just shelling to the MSBuild and Candle and Light, but the problem is that I don't know how to access the solution directory from code other than hard-coding it in
We found it easiest to use a utility to edit the project itself and to dump all the pre-build and post build events before we build it with our autobuilder (in our case VisualBuild).
This leaves us with a nice and juicy build process that doesn't rely on any nasty hacks in the IDE and give us full control over where source comes from and where built components go to.
I'm using a different way that works well for me, which I described here.
I maintain the version number in a batch file, which just writes it into an environment variable
I create my release builds by running a batch file that first calls the "version number" batch file (so I have the version number in an environment variable called %VersionNumber%) and then executes an MSBuild project file
The MSBuild project file builds the solution, and I get the version number for the .exe in the .csproj file by reading it from the environment variable if it exists (and then I use MSBuild Community Tasks to create an AssemblyInfo file with the version number in a pre build event)
This means that the .exe has version 0.0 when built from Visual Studio, but Im fine with that because I create all my releases from the batch file.
To create a relase build with WiX setup, I execute another batch file, which just calls the "build" batch file mentioned above, and then calls the WiX utilities candle and light to build the actual setup.
candle uses this .wxs file to create the setup, where I again get the version number from the environment variable: $(env.VersionNumber)
the final .msi file created by light includes the version number in its file name because I pass the file name (including the environment variable with the version number) as an argument: -out release\msi\bitbucket-backup-%VersionNumber%.msi
It took me a while to figure all this out in the beginning, but now I release all my projects in a similar way.
Related
Is there a way to auto create a subversion log file when i build my project in visual studio? I'm using AnkhSVN to intergrate SVN into visual studio. I can manually run the svn log command to generate a log file but i'd like to auto create a release notes file every time i build the project.
I'm not familiar with Ankh. However, if you can write a log manually, try writing a batch script that will run the same command, then have VS run the batch file in from the build steps. You can find the build steps in the project properties.
I'm pretty sure this will work. I used the build steps in VS at one time to automatically call an exe that would generate 3D models that would be loaded by the main executable compiled by VS.
Here's a link to msdn that might help:
Specifying Custom Build Steps
Build events might be a better choise, they are in the same vein and there is a "Post-Build event" that is probably when you want to fire your script. I think you can also just run it as a standalone command if you don't want to have to run a batch script.
I have recently converted a mid-sized Visual Studio 2005 solution to Visual Studio 2010.
One of the projects contains files which are not C/C++ files and are compiled using a batch file running a custom build tool. The output of the custom build step is some C++ files, which must be compiled after that.
The output of the custom build step in the properties for the relevant files is correctly set to the generated C++ files.
The problem is that sometimes VS2010 tries to compile the generated C++ files before the files with the custom build step, which means in a clean build it fails to find the C++ files and fails. If I try building several times eventually it would compile the custom files and then the build will succeed, but this is obviously not a good solution for automated build.
In VS2005 there is no problem building this project, but VS2010 fails to determine the correct compile order from the outputs of the custom build step. Is there another way to force correct compile order in VS2010?
Visual Studio supports parallel builds, it can build more than one project at the same time. This will not work properly if it cannot properly see the dependencies between projects. A custom build can certainly be a troublemaker here. The number of parallel builds is configurable, setting it to 1 would be a very crude but effective workaround. Tools + Options, Projects and Solutions, Build and Run, "maximum number of parallel project builds" setting.
But don't do that, parallel builds can be a huge time saver. You fix this kind of problem by setting project dependencies explicitly. Right-click the project that uses the generated C++ files in the Solution Explorer window and click Project Dependencies. Tick the check box for the project that produces the C++ files. In case it is relevant to other readers, check this answer for a way to create a project that only does the custom build step and nothing else.
Visual Studio 2008 by default executes custom build tools first. The order can be changed via right click menu on project with command "Tool Build Order". This facility is not available in Visual Studio 2010. I do not know of a work-around.
Consider using Visual Studio 2010's "Properties >> Configuration Properties >> Build Events >> Pre-Build Event" as the place where you should issue command(s) to build source files that must be compiled first. In the Command Line field, call upon the cl.exe compiler or use a small external makefile to compile those files. Visual Studio will then compile the rest of your project following this initial step.
I resolved my problem when I noticed that my custom build step runs for only one file at a time. It runs for the next file on the next build etc.
The reason apparently is that my custom build steps are calling a batch file and VS2010 creates one temporary batch file to execute all custom build files.
The solution was pointed in this discussion:
http://social.msdn.microsoft.com/Forums/en-HK/msbuild/thread/ca392036-ebdb-4812-930e-f90aa445cca5
It is simply to prefix all calls to batch files with a "call" statement, thus not terminating the execution of the master batch file prematurely.
We're writing Python modules in C++ using Visual Studio 2010 Professional. We output Debug and Release modules in a different directory, and a configuration file for the Python part of our code determines which version is loaded.
During development in C++ I often switch between Release and Debug configurations. Sometimes I forget to update the Python config file, and then I build in Debug but the Release version is still being loaded.
What I would like is to automatically update the configuration file, so that when I switch the VS2010 Solution configuration from Release to Debug (and the other way around), the Python configuration file is automatically updated accordingly.
Update: the solution consists of roughly two dozen projects, and there is no single project that will always be built. I could use a pre-buld command, but I would have to add it to each and every project, which I'm trying to avoid.
Is this possible, and if so, how?
Kind regards,
Sybren
Visual Studio has pre- and post-build events. Those give access macro's that also give you the build mode (ConfigurationName).
You could update the Python config file in the pre-build command.
Things like
if $(ConfigurationName) == Debug
are possible.
In some projects I used this in combination with batch/cmd files that take the $(ConfigurationName) as a parameter.
After compiling a Visual Studio setup project: there are two files produced: application.msi and setup.exe
If I run application.msi, the new version is not rewritten to the old version. It is likely to run setup.exe for all of the cases. That made confusion if I give two files to the clients. How can I made just one file?
The Setup.exe file is a BootStrap file used to check for the prerequisites that you setup in your Setup Project's Prerequisites Dialog. The MSI package itself is what determines the applications installation parameters. You should have Remove Previous Versions as true and make sure that your application's Assembly version has been incremented by at least the Build Number, otherwise if you are updating only the Revision number it will not be over written. The Assembly Version information Format is as follows. Major.Minor.Build.Revision. Make sure that you also change your setup projects Version number also.
You can package the MSI with setup.exe into a single self-extracted archive and launch setup.exe after it's unzipped.
Every time I publish the application in ClickOnce I get get it to update the revision number by one. Is there a way to get this change automatically to change the version number in AssemblyInfo.cs file (all our error reporting looks at the Assembly Version)?
We use Team Foundation Server Team Build and have added a block to the TFSBuild.proj's AfterCompile target to trigger the ClickOnce publish with our preferred version number:
<MSBuild Projects="$(SolutionRoot)\MyProject\Myproject.csproj"
Properties="PublishDir=$(OutDir)\myProjectPublish\;
ApplicationVersion=$(PublishApplicationVersion);
Configuration=$(Configuration);Platform=$(Platform)"
Targets="Publish" />
The PublishApplicationVersion variable is generated by a custom MSBuild task to use the TFS Changeset number, but you could use your own custom task or an existing solution to get the version number from the AssemblyInfo file.
This could theoretically be done in your project file (which is just an MSBuild script anyway), but I'd recommend against deploying from a developer machine.
I'm sure other continuous integration (CI) solutions can handle this similarly.
Edit: Sorry, got your question backwards. Going from the ClickOnce version number to the AssemblyInfo file should be doable. I'm sure the MSBuild Community Tasks (link above) have a task for updating the AssemblyInfo file, so you'd just need a custom task to pull the version number from the ClickOnce configuration XML.
However, you may also consider changing your error reporting to include the ClickOnce publish version too:
if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
{
Debug.WriteLine(System.Deployment.Application.ApplicationDeployment.
CurrentDeployment.CurrentVersion);
}
I implemented this recently using some custom tasks. An issue I found with implementing this with ClickOnce is that all your DLL files are updated. This causes the ClickOnce update to download all the application files every update. This bypasses on of the nice features of the ClickOnce deployment where only the modified files are re-downloaded in an update.
Just something to think about when implementing something like this with ClickOnce.
Steps:
Use external incrementing version number (if you leverage a continuous integration server like CruiseControl.NET, then it comes from the build label).
Use GlobalVersionInfo.cs (file link-referenced by all projects in your solution) to hold the current version and update it on the build with the AssemblyInfo task from the MSBuild Community tasks.
Script Mage command-line tool from the .NET SDK to update the ClickOnce manifest, using the same version (see the -v and -mv switches).
BTW, a nice bonus is that, whenever you automatically publish a newer ClickOnce deployment version via the integration script, if you also specify the minimal version to mage.exe (same as version), then every user will be updated automatically on the next application launch.
You'll probably need to create a piece of code that updates AssemblyInfo.cs according to the version number stored in the .csproj file. (The ClickOnce deploy version is stored inside an XML tag.)
You'd then change your .csproj file to run this bit of code when Publish|Release build is performed. The MSBuild folks have blogged about how to perform custom actions during certain build types; check the MSBuild team blog.