I have to update the build number in assembly version of assemblyinfo.cs file.
I have written a custom tasks which updates all the assmeblyinfo.cs under a solution before starting build. But when i change this file and try to build then some of my dlls which has reference of other dlls not able to compile as they dont find the specific version assembly. I have some files which uses strong name assembly also. Not sure how to update their version. I have tried setting specific version to false,but still same error is coming.
Can you anybody tell me the good way to update the assemblyinfo.cs with incremental build number?
P.S. i am using NANT tasks for automating by builds.
There's a good NAntContrib task called Version that should do what you're looking for
Related
Is there a simple way to set the TFS Build Number to be an Assembly Version during build?
I've seen many examples of the other way around (i.e. a build number updates the assembly version).
We already use the SharedAssemblyInfo implementation from here, so we would like to leverage this setup during the build process.
Currently using TFS 2012 with Release Management template (ReleaseDefaultTemplate.11.1.xaml).
Without modifying the build process template? No. Even then, the build number is set prior to compilation (or, IIRC, even syncing the code from source control), so you're in for a wild ride trying to get the behavior you want.
I'm just looking at streamlining the nuget packages that are coming out of my build system and I'm stuck on how to only package the files that are required.
I have several configurations sharing a Root VCS checkout. I have a configuration that runs a debug build with unit tests. I also have a release configuration that does a release build, this configuration then also uses the TeamCity OctoPack plugin to create the nuget packages.
What I want to achieve is the building of nuget packages that don't contain the *.pdb and *.xml documentation files as these aren't required for the release deployment.
I've looked through this page on the OD site:
http://docs.octopusdeploy.com/display/OD/Using+OctoPack
And according to this page OctoPack should only package up the required files by default. I'm not entirely clear on how or what needs to be done to get around this problem as it doesn't appear to be working as described.
It seems that one solution would be to provide a nuspec file for the projects I'm looking to deply but I'm also wondering if there is something I'm missing before I head off down that route.
I also have some MEF plugins that are copied in post build events and these aren't included in the nuget packages when in fact they are needed for the application to run. I think I need to get explicit with a nuspec file but would like to confirm this.
What is the simplest way of achieving what I need?
Assuming you're running the later versions of OctoPack, in your release build you can set a system parameter system.DebugType = None which will get passed to the OctoPack build scripts and prevent the PDB's being created.
This simply overrides the setting defined in your csproj msbuild file (assuming C#), so you can use it wherever you want to prevent PDB's being created at the build configuration level (not just OctoPack). I generally prefer this approach as it prevents side-effects in your build from changes by developers in the project file.
As for the xml files, I haven't actually tried this, but you can try a similar approach and create a system parameter system.DocumentationFile = "" to blank out the output.
If you really want to make sure that the files have been removed there are a couple of ways you can do this. Modify your deployment process to:
Execute your own custom PowerShell script in that removes the files
Include a script module from the Octopus Library to the same. Check out the File System - Clean Directory from the Octopus Library
I have created a Visual Studio Deployment Project for my application. We are a using subversion to manage version numbers and I've got versionInfo.cs file which contains the version number. I want to give the version number I have in my application (versionInfo.cs) to the Version Property of the setup project. I am not sure how to it... Do I need to create a custom action? Or what's the best way to do that.
Thank you!
As for me, setting version is a responsibility of build process. So, you don't need a custom action - it is a part of installation logic and runs at install time. Instead, teach your build engine to put correct version to your installation package (e.g. read it from VersionInfo.cs and put to vdproj file).
Finally I fixed the issue.
I've setup Cruise Control build server and added Nant script to change the version in the setup project.
Thanks,
Charith
We have a couple of projects configured in cc.net. Each of these projects has following items in it's working directory (svn):
source
lib
db scripts
SSIS package(s)
We would like to know if there is a way to find out if there are any modifications in the subdirectory containing the SSIS packages? This would allow us to do a full build (including execution of package). We don't want to do this with every build since package execution might take some time...
Our other option is to create a cc.net project that does the complete builds at night time.
Does anybody have a nice solution to this problem?
I would use the SvnVersion task from MSBuild Community Tasks to identify the latest revision on the SSIS package subdirectory. Then compare it to one you've stored in a file somewhere in your working directory or elsewhere.
If it's different, pass a property to your main MSBuild task with a flag instructing to build and execute the SSIS packages. Once that's done, update your revision file with the new new revision number for the SSIS subdir.
I'm trying to setup my VisualStudio project to set the assembly version based on the latest subversion revision number as described on this page. But the version number always seems to lag one revision.
I've split out the assembly version attribute into a separate file, VersionInfo.cs, that is updated with a pre build event.
I'm using the following code to display the version number in the title of my form:
System.Reflection.Assembly assem = System.Reflection.Assembly.GetExecutingAssembly();
this.Text = "My Program Version: " + assem.GetName().Version.ToString();
Here's an walk through of what's happening.
I commit my project so that it is at the latest revision.
Using TortiseSVN I use show log to see that I'm at revision 55
I build my solution.
I then open VersionInfo.cs and see that the pre-build event correctly overwrote this file as
[assembly: System.Reflection.AssemblyVersion("0.1.55.*")]
Yet when I run the program the title bar displays and old version 0.1.52.20486
Next I open the project file in notepad, and change something, such as adding a blank line, and then save the file.
VisualStudio shows a notification that the project file has changed and prompts me to reload the project which I accept
Now when I build and run the program the form shows version 0.1.55.20645
I make a change to something in the project, and commit to SubVersion.
TortiseSVN confirms my working copy is now at revision 56.
I build my project and VersionInfo.cs is correctly updated to
[assembly: System.Reflection.AssemblyVersion("0.1.56.*")]
I try running the application again and the forms title shows 0.1.55.20750 rather then 0.1.56.xxxxxx
Also I've noticed that even if I rebuild/rerun my application the build number (the last number in the version number) is also not updated. It was my understanding that the asterisk would be replaced my a new number at each build.
Any one have any idea what's going on?
I haven't worked with the specific tool you are using but the tool I am using requires you to do an update on your sandbox after your commit. Has something to do with the tool using the revision number retrieved by the last update, not the last commit.
When you checkin a file, the revision number is incremented as you know. The problem is, you do not know what that revision number will be when you checkin - you only find out after checkin.
So, if you take the latest revision number, build your project, then checkin - the number used will always be out of date. What you really want is to be able to checkin, then get the revnum of the commit you've just performed, and then build your project with the correct version number.
Obviously this is not possible.
There is a way round it - use a CI system that builds your project immediately after checkin (through a post-commit hook). These will checkout the latest version you've just added, update your version.cs file, then build. The disadvantage is that your version.cs file will never contain the correct version number (unless the CI system then checks just it in again)
The best way to handle this is when you do your build.
I use Jenkins as my continuous build server instead of relying on doing a manual build on my system. If you don't use something like Jenkins (Hudson, Atlassian Bamboo and CruiseControl are three other popular Continuous Build servers), you should. This way, your official builds are not dependent upon a particular developer machine.
If you do use Jenkins, you can now use Nant or even Ant to help you manipulate your build. We are doing this now with Jenkins and Ant.
What I do is use msbuild.exe to build my project using Jenkins. Before I do a build, I use Ant to retrieve the Subversion revision number (actually, we use Jenkin's build number, but the theory is the same) to modify the assembly file with the correct version. Then, I do a build itself. The results is the correct Subversion revision number (err.. in our case the Jenkins Build Number) in the assembly file when it's built.
Come to think of it, you can probably do what you're doing now to set the Revision in the Assembly file. Jenkins will then build the project with the correct Revision number in the assembly file. You download the built package, and you'll see the correct version number in the title bar.