I want to be notified when a build has been completed\failed in visual studio and I DO NOT want to use pre\post build steps, I want an external process or VS plugin that will count the number of builds.
So is there anyway to achieve this using something like WMI or other such technology?
I'm not interested in third party libaries, I want to write a plugin for visual studio.
There isn't. You can either use the pre/post build steps, or make an add-in. For the latter look for EnvDTE.BuildEvents. Let me know if you need a sample.
Any particular reasons you don't want to use the pre/post build steps, you can pretty much do anything with them, i.e. send mail, increment the file version information in AssemblyInfo etc.
The TFS PowerToys for 2008 or 2010 includes a build notification tool.
I am using this free VS plugin for Build status.
You can find it here.
Related
I'm running Visual Studio 2010, VisualSVN and TortoiseSVN.
Each time I use webdeploy to deploy the website, I'd like it to commit all of my files to SVN. What's the best way to accomplish this?
Visual Studio does a build when you hit the publish button. You can create a build configuration in VS2010 that executes commands after a successful build. You should install the command line SVN client and use that to execute a commit. Call the SVN command line client from the Build Configuration.
A more common approach would be to commit your change to the version control system instead of using WebDeploy. Then have a build server get the source from version control and incorporate the changes into the server. CruiseControl.NET is a good tool for doing that.
You should investigate https://github.com/loresoft/msbuildtasks which once installed and integrated into your project file, offer support for creating custom msbuild actions.
With it installed you can create 'SvnCommit' actions and associate it with a beforebuild or afterbuild target in your project file.
probably this is not the answer you are looking for - but I do not think you can get this out-of-box. I would suggest you to create a visual studio plugin and integrate it with SharpSVN (subversion client API) to achieve what you want.
UPDATE:
as #maddoxej mentioned, post-build action might work as well. However, I find it's easy to miss what configuration is selected - and press F5. And committing to SVN by accident is not generally a good thing.
Another option I thought about could be VS macro. Just record a macro which clicks deploy and then commits to SVN.
The answers that suggest making the check-in a build action is slightly flawed because the publication process will presumably increment a published build number as part of the publication process. This will modify the source code which will then need checking-in.
C# / VS2010
What is the easiest way to obtain a build number? I have noticed that when I PUBLISH a project, there is this publish version. Is there an equivalent to do something similar when just building - and not publishing.
Goal: I want to display an automatically updated version / build number in the application, so I need be able to fetch it at runtime - and of course somehow generate it.
Of course, I could write a little batch file doing things (pre-build). But isn't there something already available...
How to make Build Number in VS 2010 http://msdn.microsoft.com/en-us/library/aa395241.aspx
Also Build Version Add-In for Visual Studio http://autobuildversion.codeplex.com/
use the version-number from your source-control-system. you can use a build task to get that number from the source-control and insert into the appropriate files.
Is there a free tool that allows us to create / edit the msbuild projects and automatically integrates with TFS?
I found:
1 - http://www.attrice.info/msbuild/
2 - http://www.finalbuilder.com/home.aspx
By cons they are not free (Licensing Website; unlimited exceeds $ 3,500)
MSBuild is free because it comes with the framework 3.5 but I found it annoying that whenever I have changes to make in my build, I am forced to change the MSBuild build file (xml ) by hand!
In the 2010 release of TFS\Visual Studio ALM introduced Window Workflow as an "option"(I use quotes since not sure exactly how to describe WF\MsBuild but more info here SO3004671)... but since you mention framework 3.5 perhaps you mean that use are using TFS 2008.
Note Finalbuild does much more that just deal with MsBuild, it has many other 'tasks' that be added to a FinalBuilder script. Also another option along the same lines as FinalBuilder is VisBuildPro. I believe there is a trial version of either you could test out.
As for cost you probably don't need a site license at least to start with. Really you probably just need as many as the # build machines you have and\or the number of people creating build scripts (depending upon where they do their work).
I have created builds in the past that are mainly using TFS as the method to schedule or kick off a build and get the source (and do the build reporting) but then do the rest of the work a FinalBuilder script.
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
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.