I think most people here understand the importance of fully automated builds.
The problem is one of our project is now using an integrated Visual Studio Setup project (vdproj) and has recently been ported to Visual Studio 2008. Unfortunatly, those won't build in MSBuild and calling devenv.exe /build on 2008 just crashes, apparently it does that on all multi core computer (!!!). So now I have the choice to either rollback to .Net 2.0 and 2005 or simply ditch Visual Studio deployement, but first, I'd like a second opinion.
Anyone knows of another automated way to build a .vdproj that will not require us to open the IDE and click on stuff?
WiX was what I had in mind when saying we would ditch vdproj. Do you have any experience with it, good things, caveat?
The low cost solution is to switch to using ClickOnce, which you can automate using MSBuild. But if you still need to create a Windows Installer package, you will need to convert your project to WiX (pretty straight foward) and build that with your solution.
This will get you started:
Automate Releases With MSBuild And Windows Installer XML
I've used WiX a little bit before, and generally I found that it's great once you figure out what to do but there is a steep learning curve. If you spend a solid day going over the WiX tutorial you should be be able to get 80% of your setup working.
WiX Toolset Tutorial
I had the same requirement and ended up using what is suggested in these two links
David Williams Blog
MSDN article
Basically, since Team Build, by itself, will not build the setup projects for you, this approach has you add a new build step after the regular build is complete. This step fires off a second build by launching the devenv.exe. The IDE will build your setup files. The extra build is a bit costly but we only needed it for builds that were going to be pushed out. The Daily build at most would need this customization our CI build does not need to build setup files each time.
After that you execute some Copy commands, once again build steps that show up in your Team System build results, to move the setup files to a network share etc.
It feels a bit like a kluge at first, but it does work, it is also a full-fledged part of the automated build in Team System so it worked for my Continuous Integration goals.
Related
I have a .net poject (wpf, excel and asp.net site), I also have a build machine for the purpose of continuous integration. For continuous integration to work, I need to be able to build the project. So, what I have done so far is install visual studio on a build machine and things will build fine, but I dont really have that option, so I was wondering what do I need to run from the visual studio setup, just to be able to build projects, meaning I am pretty sure some of things like f# in this case or MVC frameworks are not something that I need. Is it possible to run a few of the executable or just customize the install and if so what are the mandatory things that I need to select to basically boil down to having a solution be able to build and not have the ide installed?
Thanks
MSBuild is the component that builds your solutions. You can have a look at this question to run it with minimal installation:
Installing MSBuild 4.0 without Visual Studio 2010
Is there a good guide on how to do this with these two exact pieces of software? I have found a lot of generalized CI setup guides, but none involving these two exact components.
TFS makes setting up a continuous integration server very simple. You will first need to create a new TFS project. Then you need to configure Visual Studio to use your new project. Finally, you can setup a build for the project within TFS. There is a pretty good blog post about how to do it. The important step is setting the build trigger:
You can set various build triggers, including a continuous schedule. Obviously, you can get much more complex with the build definition. Deployment options, config options, but hopefully this will be enough to get you started.
Why should one go for Windows Installer XML (WiX) when we have in built .net MSI installer?
It would take me hours to rant about everything I hate about VDPROJ. I won't because in my (expert) opinion it's already settled law that VDPROJ sucks. If your install is so simple that you haven't noticed any problems, then be my guess and stick with it. But if you already find yourself fighting the tool trying to get it to do things it doesn't do, then take my advice and dump it fast for WiX.
10 things I hate about VDPROJ
No MSBuild Support. Sure, you can call devenv from the command
line but it's not as good.
No exposing of the critical concept of
a component. Every file/reg key is a keyfile of it's own component.
No effective way to fully exclude automatic dependency scanning.
Shortcuts are always Advertised
No way to describe a service.
No way to describe many things which leads to overuse of custom
actions.
No way to fine control the scheduling / execution of
custom actions. Too abstracted.
Abstraction is wrong. Deferred
CA's are scheduled with Impersonation which breaks on Vista.
Various limitations lead you down a path of massaging the built MSI
during postbuild to get around all the limiations. Results in a
very poor build automation hacks.
Merge Module directory tables
are authored incorrectly.
100 other things suck that I'm not
remembering right now.
The introduction of WiX tutorial gives the basic idea about WiX advantages comparing to other setup development tools (including VS setup projects):
declarative approach
unrestricted access to Windows
Installer functionality
source code instead of GUI-based
assembly of information
complete integration into application
build processes
possible integration with application
development
support for team development, both
in-house and third-party
free, open source
Hope this helps.
Visual Studio deployment packages can only be built by visual studio. They cannot be built using plain MSBuild command lines, which makes them less than ideal for e.g. build servers.
All the above answers have included most of the annoying features of Visual studio setup projects (.VDPROJ), one thing that most people have missed.
.VDPROJ file format is such that, and if we make a small
change to one single entry it completely rewrites all the entries
within which makes it impossible to merge changes from 2 different
branches.
Some of us don't want to use / can't use the .NET installer.
Some of us don't want to have to install Visual Studio to distribute a program, written in, say, Borland Delphi. WiX and .NET have nothing to do with one another.
WiX provdes a much more complete feature set than the .NET installer.
We are currently evaluating different applications that interface with Visual Studio 2008 (C#) and Subversion to do automated builds of our core libraries. We are hoping to have nightly builds performed and either email the list of changes made to each developer or have the latest versions be pushed to each workstation. What has been your experience with these tools and what are some recommendations?
Suggested software
Cruise Control .NET
Hudson
TeamCity
Suggested articles
Continuous Integration: From Theory to Practice 2nd Edition (CC.net)
Automating Your ASP.NET Build and Deploy Process with Hudson
Cruise Control.net (ccnet) does everything you are looking for. Its pretty easy to use, just make sure if you are going to run it as a service, you give it an account and don't make it run as network service, that way you can give it rights on intranet boxes and have it do xcopy deploys.
It has all kinds of email modes, on failure, on all, on fix after failure, and many many more.
Hudson is the easiest continuous-integration / daily-build tool I've seen. Not sure if it meets all your requirements.
Take a look at the JetBrain's (guys behind ReSharper) TeamCity
I've used cc.net with nant and msbuild with great success, would highly recommend it.
At my last employer I set up a buildserver with cc.net. Expect at least one or two days work to set it up. I used cc.net together with nant and msbuild. These projects have a lot of overlap in functionality so it might be a good idea to think about how you want to set everything up.
The setup I eventually settled with was cc.net on the server to retrieve the project from subversion and fire off the nant scripts. nant was used to call msbuild to build the visual studio .sln files and do all the other build steps like running tests etc.
I had a quick look at teamcity too. On first sight it looks a lot better than cc.net but I didn't have time to try it out yet. It's certainly worth checking out.
I use CC.Net along with SubVersion and MSBuild to accomplish this. Here is a great guide for implementing this which I followed on found very helpful.
A couple of tidbits about working with cc.net and msbuild. If you are building C/C+= projects, msbuild is, um, unreliable at least with VS 2005 (and perhaps earlier). I have not tested with VS 2008. We found that sometimes msbuild would work properly, sometimes not. In trying to solve the problem, we found vcbuild.exe which seems to work well in place of msbuild when building C/C++ solutions.
If you are using trac for issue tracking, the bitten plug-in works well. It's not platform specific (we run it on both Windows and Linux at work, with msbuild/mstest and make/gcc/cpptest respectively).
I am using hudsons Jenkins for getting daily build. It really very easy to setup and maintain. And it have a lot of plugins which full fill our requirements.
I'm working in a team environment where each developer works from their local desktop and deploys to a virtual machine that they own on the network. What I'm trying to do is set up the Visual Studio solution so that when they build the solution each projects deployment is handled in the post-build event to that developers virtual machine.
What I'd really like to do is give ownership of those scripts to the individual developer as well so that they own their post build steps and they don't have to be the same for everyone.
A couple of questions:
Is a post build event the place to execute this type of deployment operation? If not what is the best place to do it?
What software, tools, or tutorials/blog posts are available to assist in developing an automatic deployment system that supports these scenarios?
Edit: MSBuild seems to be the way to go in this situation. Anyone use alternative technologies with any success?
Edit: If you are reading this question and wondering how to execute a different set of MSBuild tasks for each developer please see this question; Executing different set of MSBuild tasks for each user?
If you are using Visual Studio 2005 or later, project files are MSBUild files. Inside the MsBuild file, there is an "AfterBuild" target. I would recommend using this to do your deployment tasks, instead of the Post Build Event.
By using MSBuild tasks, you are more prepared to move into a Continuous Integration system like CruiseControl.NET, or Team City.
I'm not sure why all of your developers have their own virtual machines, it would seem at some point you'd want a central location where all developers work is built to ensure the code from all developers will integrate and build (this is a reason for using Continuous Integration systems). I'm sure you can find a way that CruiseControl.Net or Team City or one of several other choices can help you in this scenario. But as far as getting the initial setup, use MSBuild.
i'd look into MSBuild or ANT