Is it possible to update the version number(AssemblyVersion("1.0.2.1")) insdie AssemblyInfo.cs outside visual studio???(Maybe using a script or a batch file)
I have used UpdateVersion in the past to update the version number as part of a build script before. If you use subversion you can also use SubWCRev.exe from TortoiseSVN to update the version number to include the SVN revision number.
It can also be done from MSBuild..
Check out the AssemblyInfo task here:
MSBuild tasks
We use it from CruiseControl.net it's very straightforward to use.
I used to have a PowerShell script that would write the version number out to "AssemblyVersion.cs", like this:
// DO NOT EDIT
// Generated by UpdateVersion.ps1.
[AssemblyVersion("1.0.2.1")]
The version number was updated in all projects/assemblies at once this way. The canonical number was stored elsewhere.
It's trivial to write, but varies depending on your exact needs, so I won't try to post it here.
You can simply use any search and replace tool or write one yourself.
For the current porject (that is built with msbuild) I'm using a custom build step (self written as it is small and simple) that searches for AssemblyVersion and replaces that in the AssemblyInfo.cs files.
Related
I want to raise the assembly version number of a project by using a check in policy. How can I get the assembly by using CheckedPendingChanges? I get the filename but I don't know how to extract generically the assembly out of it so that I can manipulate the version number and to check it out.
this.PendingCheckin.PendingChanges.CheckedPendingChanges
I'm open minded for other approaches to raise the version number of a project where some code changes are inside.
If you want to go with this approach, you could look for all .csproj (or whichever project format relevant to you) that contain that filename (you will need to care for relative vs absolute paths).
I would prefer the build system to be responsible for versions, triggered on specific paths to identify the project . I prefer an assembly version format like yyyy.MM.dd.revision. II have an example lying around for programatically stamping all assemblyinfo.cs files in a solution with a custom version through msbuild, which could be adapted to your needs. I will find it and post it when I reach home.
By default a Visual Studio C# Library/Console etc project comes with an AssemblyInfo.cs file that does not include AssemblyInformationalVersionAttribute. TeamCity allows patching this attribute if found in AssemblyInfo.cs using AssemblyInfoPatcher.
Problem
A zero effort way of including AssemblyInformationalVersion for TeamCity.
Possible Solutions
Use a GlobalAssemblyInfo.cs file and link to each project, downside: each new project will have to be linked, frustratingly annoying if (often) forget to create link
Add AssemblyInformationalVersionAttribute to all templates in Common7\IDE\ProjectTemplates\CSharp\, downside: do it on each devs machine, mainly overkill
A first build step that runs a script based on this SO answer and creates links on all .cspprojs, downside: will have to check back in for patching step, overly complicated
Reason
The AssemblyInformationalVersion is useful because you can put any text there - I like to put the git hash of the commit used to build the assembly in it
Have you a better idea?
I like the idea of automatically versioning my builds but I'm not sure what the right way is to get the AssemblyInfo.cs change back into source control (or should it not go into source control?). Is this something the CI server should be committing automatically for each build?
Using Bamboo at the moment.
We are using Teamcity as our CI server, and it comes with a feature called AssemblyInfo patcher
What this does, is temporarily add the teamcity build number in Assemblyinfo.cs, build generate the artifact and then revert the change. This way the generated artifact has the same version as the build number.
Source control can have the assemblyinfo.cs version entry as the current revision the developers are working on, with '*' as the build number. This can be updated after every release.
Edit 1:
Since you are using Bamboo, here is a link that describes one way of setting the build number in the generated artifact in bamboo, without having to check-in the AssemblyInfo.cs.
I'm sort of confused by your question. If you want the changes to persist you'll have to commit AssemblyInfo.cs after it gets edited by the build job. However, most build systems attempting to solve these problems do not persist the changes. They simply check out the file and edit the local version before kicking off the build task.
How do I programmatically increment a given version's number to the next version of the highest one?
For example if I have a file Program.exe with the following version numbers :
Program.exe 1.0.0.0
Program.exe 1.0.0.4
Program.exe 1.1.0.76
Program.exe 1.0.0.66
The next version number in this case would be 1.1.0.77
What's the easiest way to implement that?
Thanks for any help in advance
Use a version control solution, like Subversion or git, and/or a build tool.
Certainly a version control solution will provide functionality to insert version information into the source code as it is committed via a magic string you include in your source like $Rev$, which you can then use as a build number.
Here's a blog post showing how it's done with Subversion.
If you're trying to do that to set the program properties (not just in the source code as Brabster suggested), you could set visual studio to automatically change the build number. The problem is that the number is not sequential. Check out this link to see how easy it can be done.
Also check this post.
If you want an auto incrementing number that updates each time a compilation is done, you can use VersionUpdater from a pre-build event. This has the advantage of more control than the default numbering mechanism described on MSDN.
Your pre-build event can check the build configuration if you prefer so that the version number will only increment for a Release build (for example).
I always use AssemblyInfo Task (http://code.msdn.microsoft.com/AssemblyInfoTaskvers). Though it does not support the feature you want, it is an easy way to manage version numbers.
Check out this article on Codeproject that covers a Visual Studio addin to manage the version number of a project.
Hope this helps.
In C++ projects there is the possibility to set a custom build step for files. Is there a similar functionality in C# projects? I couldn't really find anything.
One idea would be to create a second project (makefile or c++) and move the files there.
MsBuild should work for you although it might take some time to figure out how it works. It appears that you can setup a step that runs prior to building each .cs file by separating each .cs file into its own build group.
In MSBuild script for compiling each .cs file into an EXE, Dino Chiesa comments:
By using the %(CSFile.identity)
scalar, we run this task once for each
file. The converse would be
#(CSFile.identity). That would run
the compile once, for all files,
compiling them all together into a
single assembly.
Also, these links might help:
Custom build step for C# files
Master Complex Builds with MSBuild
No custom build step for individual files with C# projects. You could probably hack something together with MSBuild...
Look at the BeforeBuild and AfterBuild targets in your csproj file.
I think you are on the right track with your comment about multiple projects. Combine this with the fact that you can include multiple projects within a single Solution and you may have your answer. I use this functionality to build several components at a time and it works quite well.