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.
Related
i have developed the windows application in visual studio 2010 with C#. i am using visual source safe 2005 as the version controller. in my application have about us forms which contains the build version no and build date. my client asked me in every build the version no and date update automatically. currently i am updating manually. help me in this issue.
This has nothing to do with SourceSafe per se, since it's only used to store the code, it doesn't build nor act upon it.
You can create an automatically incrementing version number for your assemblies by using the [AssemblyFileVersion("1.2.*")] attribute and by specifying a wildcard.
If you want to include a build date, you'll need to use a pre-build task in your .csproj file which will update the date inside a .cs file before the code is built.
Alternatively you can use a post-build task to create a xml or text file containing the build date (and even version if you want to), then when you need to display the information, you can pull it from said file.
A RegexReplace task might help you out here... Or the UpdateFile task. Be weary of the hosted environment when using a task to patch .cs files just before build. The MsBuild Community Tasks can be your friend here.
Normally "continuous package integration" involves source control, a build server, and participating teams fetching updated packages as often as they like. But I'm looking for a more extreme version of this story - without CM - that happens entirely on a developer's machine, all in one swoop. A more detailed description of what I want goes like this...
Using Visual Studio 2010 or 2012, assume a "foo.csproj" application that implements a plugin system. Each plugin represents a nuget package and has a corresponding Visual Studio project. Each of these projects is part of the same VS solution that contains the base application.
I want the following development story:
Change source code for a plugin.
Build solution, or perform a debug-launch, which causes msbuild to...
rebuild the changed plugin(s)
nuget then packages and uploads each plugin to a local repository (which can be just a subfolder of the VS solution)
rebuild the base application.
refresh the base application's nuget-plugin dependencies, which were just updated in prior steps. Notes:
This assumes MSBuild magically knows not to perform this last step until all plugins are built, packaged, and uploaded.
The "foo" application could itself use nuget.core to refresh the packages, but in this case I'm assuming that the VS build process did this step.
I would like to know if this story is common enough that there are "common" (msbuild?) scripts for this.
My own guess of how this should be handled is as follows:
All plugin projects are placed in a common "Plugins" folder somewhere in the VS solution folder structure.
The base application "project dependencies" are configured with references to all the plugin projects.
Note: I don't like the idea of managing these project dependencies manually.
The base application "foo.csproj" has a build step that scans the "foo.csproj" XML for dependencies it has in the "plugins" folder, and initiates the nuget packaging and deployment for each.
The base application then initiates the nuget "update all". Hopefully this is possible even though msbuild already mid-stride in execution.
In short, the base application is able to instantly consume plugins that have been altered. This is done without check-ins, a build-server, or manual and arbitrary requests to update plugin packages.
If pre-existing scripts do not already exist for this story, then I'll make my own. But I'd still like to know:
Can step 2, immediately above, be converted to something generic? That is, how can I convince msbuild not to build the "base application" until all projects in a particular folder have already been built? Remember, I'd like not to manage the project dependencies manually.
Is there anything flawed with this overall approach?
I would be particularly interested to know if there is an already existing nuget-visual-studio integration that assists with this story that I may have overlooked.
That's quite a long question to answer, so not sure I'm covering everything in this one; I'll do my best. First, your scenario is not uncommon. The first 2 steps of your planned approach seem OK to me (you're free to choose the location of the plug-in projects).
One thing's for sure: you'll have to manually define the build order, because your solution has no idea of knowing whether the projects consuming (NuGet) plug-ins have a dependency to the projects containing the source code for those plug-ins. Instead of using the built-in Build Order dialog in Visual Studio, take a look at this post on the MSDN blog for a correct way of doing this (or you might end up with something that works locally but not on the build server).
The key MSBuild elements in the referred post are the following:
<ProjectReference Include="... foo.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Now, as for the packaging, deployment and consumption of those plug-ins:
Each plug-in project should trigger package creation and publication in a post-build step. This post on my blog contains ZIP-download with quite lot of MSBuild stuff you can use to get started. E.g. I version, package and publish the NuGet package for a class library in Release builds. I'm using the NuGet command line tool to pack (command reference) and push (command reference) the package.
The consuming application project(s) should run NuGet.exe update <packages.config> (command reference) in a pre-build step.
Also pay attention you're NOT running builds in parallel.
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.
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.
I have a DBPro (DataDude) project inside my solution to manage and version the database schema of my application. I use TeamCity 4.0 for continuous integration.
To be able to build a .dbproj, MSBuild tasks and their respective assemblies have to be installed, other .dbschema and .xsd dependencies put in place. The easiest solution is to install VS2008 TS: Database Edition on the build server.. something i'd love to avoid. I have started putting the files in place one by one bot got bored after the build failed on some missing XSD files installed by VSTSDB.
Has anyone found an easy way to avoid installing VSTSDB? A community-made 'redist' installer that puts the right files in the right place and the right assemblies into the GAC? The topic is pretty hard to google so I am hoping to tap the stack overflow knowledge base :)
I am aware of the Deploy folder and vsdbcmd.exe but I would like to build (and deploy).
No. Not according to this post by Gert Drapers
The question is if you are able to build the db using command line (like devenv.exe with some arguments)? If so I see no problem installing the dev environment and executing through a command line task in MSBuild on the build servers. I do the same thing for MSI installers in the projects I manage.