I want to have these Versions in a format
like this.. {Major}.{Minor}.{Build}.{patch}
how to set this in the assembly info patcher in team city?
so that it will automatically increment the versions for each time it builds...
i want some guidance and help in this...?!?
TeamCity can version assemblies for you with the AssemblyInfo Patcher build feature. To take advantage of this:
Create a build parameter called %Major.Minor%. Set this manually to some value, e.g. 1.0.
On the General Settings tab, set the Build number format to %Major.Minor%.%build.vcs.number%.%build.counter%.
On the Build Steps tabe, scroll to the Additional Build Features at the bottom of the page. Add an Assembly Info Patcher build step. It will default to using the %system.build.number%, which you've defined in step 2.
This will result in all of your assemblies being versioned with the %system.build.number%, which includes the Major and Minor version, the VCS revision, and TeamCity's incremental build number.
Using the File Content Replacer build feature suggested by Paul, we eventually ended up with the following versioning scheme in our project:
http://www.meadow.se/wordpress/generating-semantic-version-build-numbers-in-teamcity/
A little bit complicated to setup but we're happy with the results.
/Emil
Regarding the question from Emil G about keeping the first numbers of the version from AssemblyInfo, it's currently not possible: https://youtrack.jetbrains.com/issue/TW-20475
Would be nice, though.
/Emil Å
It's now possible to be done through the File Content Replacer (available since TeamCity 9.1): https://confluence.jetbrains.com/display/TCD9/File+Content+Replacer
Related
I'm looking for a formal definition of version number formats for .NET Core project.json files.
version
Visual studio creates a default version number of "1.0.0-*". I would love for this to mean the * gets updated on successive builds (it doesn't). The build version number is 1.0.0. What does the * mean and what are the legal possibilities?
dependencies
I expected the dependency numbering to follow the nuget versioning rules given that KPM is basically a nuget front-end, but it doesn't appear to support bracket numbering (eg "[1,2)") - I get "not a valid version string" when I try anything other than a blank or x.x-* format.
Outside of the source, does anyone have a link to a formal definition?
I'm not sure what's wrong with looking into the source for a definition. I think that's the most accurate place to search, especially now that vNext is hosted on GitHub.
Looking at the exception described, we're pointed to SemanticVersion.cs.
In the method TryParseInternal, it's fairly obvious why you're running into issues when attempting to declare min/max versions that way. There is simply no handling for [,] or (,) built into that method.
If we look into the regular NuGet version specification, it's obvious that TryParseVersionSpec does have this handling built in.
As for documentation specifying acceptable formats, you'll probably have to wait until it's out of CTP status. If you believe it's an issue, you should document it in GitHub. The contributors are very responsive to these types of issues. Personally I'm not sure if there's a need for setting a maximum version of a dependency when it's deployed with your build.
Need To Set Version Information on the existing .dll
I need to add these to dll
1.File Version
2.Product Version
Tried this free version.
does not work
any Idea ?
There is a tool named verpatch that does exactly that.
After you download it you can run it from command line as below:
verpatch your.dll /pv "product.version" /va "file.version"
There are many other flags that can be used to add extra information.
Try:
verpatch /?
There is Resource Tuner Console from Heaventools Software.
Resource Tuner Console is a command-line tool that enables developers to automate editing of different resource types in large numbers of Windows 32- and 64-bit executable files.
See specifically the Changing Version Variables And Updating The Version Information page for greater details.
I've created a tool for this purpose because didn't find anything that is enough easy to use and easy to automate. Developers find it useful.
I'm sorry if that might seem as a self-ad but I know how annoying is to sync versions...
I once had TeamCity + WiX + MSBuild Community Tasks working. Now that I've upgraded to WiX 3.5, I can't remember how I had configured it. :) As I was poking through TeamCity, I came across the "AssemblyInfo Patcher". I thought, "Great! This will make my life much easier!". I used %build.vcs.number.1% for the format and built my installer.
While the patcher did pull in the vcs number, it used it for the major number in the version. So instead of 1.0.0.xxxx, it made the version xxxx.0.0.0.
I looked through JetBrain's documentation site and came up with nothing related to changing this to a more appropriate setting. I also looked for regex support, but didn't find anything.
Can anyone suggest a good solution, or should I just go back to trying to configure my original set of tools?
The assembly info patcher only patches the complete version string at once. But the system variable build.number can be generated from the "general" page of the build configuration, like this:
When you specify %build.number% as your AssemblyInfo version, it will pick up the combined number from your General settings page.
Try including the full intended version number as part of your format:
1.0.0.%build.vcs.number.1%
Hmmm haven't seen AssemblyInfo Patcher but you can do it manually using MsBuild and Regex:
http://jonalb.com/post/2010/10/04/Automatic-Versioning-using-TeamCity-an-MSBuild.aspx
I've a repository containing snapshot artifacts with timestamps.
I want to create an assembly, that contains the dependencies. This works fine. But the artifact names contains the timestamp. So i wonder how to remove the timestamp from filename for the assembly only.
I've used this dependencySet:
<outputFileNameMapping>${artifact.artifactId}-${artifact.version}.${artifact.extension}</outputFileNameMapping>
But version seams to contain already the timestamp. So is there any chance to get a 1.1.1-SNAPSHOT instead of 1.1.1-20100323.071348-182?
I'm using version 2.2-beta-4 of maven-assembly-plugin.
Could you try the following for the outputFileNameMapping:
${artifactId}-${baseVersion}.${extension}
According to issues like MASSEMBLY-67, MASSEMBLY-91:
Using ${baseVersion} for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use ${version} for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.
Update: After feedback from the OP, the exact syntax is (wasn't totally sure of this):
${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}
I faced a similar issue when trying to build a bundle with the assembly plugin which contained a folder with the version number (I'm packaging WSDLs and XSDs).
The workaround I found is quite simple, I put the actual version number in a property (e.g. 1.0), which makes it available in the bundle.xml file for the assembly plugin, and set the pom version's to:
<version>${service.version}-SNAPSHOT</version>
This way the content of my package isn't influenced by the SNAPSHOT marker, in particular it isn't modified when doing the release.
I know there are many questions out there regarding this same information. I have read them all, but my brain is all turned around and I don't know which way to go. Plus the lack of documentation really hurts.
Here is my scenerio. We are trying to use WIX to create an installer for our application that goes out to our dealers for our product information. The app includes about 2000 images and documents of our products and a SQL CE database that are updated via Microsoft Sync Framework. The data changes so often that keeping these 2000 as content files in the app's project is very undesirable. The app relies on .NET Framework 3.5 SP1, SQL Server CE 3.5, Microsoft Sync Framework 1.0 and ADO.NET Sync Services 2.0.
Here are the requirements for the app:
The dealers will be given the app on a CD every year for any updates (app or data updates).
The app must update itself from the internet to get any new images, documents or data.
The prerequisites must be installed if they do not exist on the client machine.
The complete installer should be generated from an MSBuild script with as little human interaction as possible (we don't want to be manually updating the 2000+ file list).
What we have accomplished so far is that we have a Votive project in our solution. We have manually specified the binaries in a .wxs file. Web have modified the .wixproj file to use the HeatDirectory task to gather our data (images and documents and database) from a specified location (This is broken and giving an ICE38 error). This seems all right, but still is a lot of work. We have to manually update our data by running the program in release mode and copying it to the specified directory.
I am looking to see what other people would do in this situation.
How would you arrange your solution with regards to the 2000+ data files? Would you create a custom build script that gets the current data from the server or would you include them as content files in the main project?
How would you get WIX to include all of the project output (including the referenced assemblies) and all of the data files? If you have any complete samples, that would be great. All I have found are little clips here and there and not an entire example from start to finish.
How would you deal with the version numbers? Would you put them as a constant in the build script and reference them through the $(var.VersionNumberName)? Would you have the version number automatically picked up from the project being deployed? If so, How?
If there is any better information than what I am finding, please include. I have read numerous articles, blogs, Stackoverflow questions, the tuturial, the wiki, etc. Everything seems to be in bits and pieces. The tutorial is nice, but doesn't explain anything about MSBuild and Votive. I would like to see a start to finish tutorial on using MSBuild and Votive and all the WIX MSBuild targets. If no one knows of a tutorial like this I may put one together. I have already spent the entire week gathering info and reading. I'm new to MSBuild as well, so if anyone has any great articles on MSBuild, please include them.
The key is to isolate the different types of complexities into separate merge modules and put them altogether into an MSI as part of the build. That way things that change often can change without impacting things that hardly change at all.
1) For the data files:
We use Paraffin to generate the WiX and hence the merge modules for an html + Flash based help system consisting of thousands of files (I can't convince the customer to go to CHM).
Compile these into a merge module all by themselves.
2) Assemblies: assuming that this is a set that changes less often just make a merge module by hand or with WixEdit with the correct files and dependencies.
3) For the version number there a lot of ways to manage this depending on your build system. The AssemblyInfoTask is pretty straight forward way to make sure all your assemblies are versioned appropriately. The MSBuild Extension Pack has some versioning stuff if you are using TFS.
I had a similar scenario and was unable to find a drop in solution so ended up with the following:
I wrote a custom command line program called wixgen.exe for generating wxs manifest files. It is pretty specific to our implementation in that it only knows how to create 2 types of wxs files. One for IIS Website/Virtual Directory deployments and another for Windows Service deployments.
Each time a build is triggered by our continuous integration server a post-build task runs wixgen with the right args to generate a new manifest.wxs for the project being changed. It automatically includes all the files needed for the deployment. These builds also version the dlls using a variation of the technique at: http://richardsbraindump.blogspot.com/2007/07/versioning-builds-with-tfs-and-msbuild.html
A seperate build which is manually triggered is then used to build the wixproj projects containing the generated wxs files and produce the msi's.
I would ditch the CD delivery (so 90's) and got with ClickOnce. This solution seems to fit well since you already use the .NET framework. With ClickOnce you should be able to just keep updating the content of your solution and make updates available to your heart's content. Let me know if you need, sample ClickOnce deployment code.
You can find more ClickOnce information here.
Similar to dkackman's answer, you should seperate your build into several components, isolating build components to be built seperately.
I come from a mainly Java background, however for building MSIs and NET executables we use maven; with the 'maven-wix-plugin' plugin for building the installers, and using the NMaven plugin for compiling any NET code. However, as we're only performing very basic development in NET, with most development in Java, we don't need too much complexity from the NMaven plugin (which is probably a 'good thing' (TM) as it's only at version 0.17).
If you're a purely NET house, you could also look into Blydan (http://www.codeplex.com/byldan), which seems to be the focus of development there at the moment (it's the same team for NMaven and Byldan).
If you do want more information on NMaven or Byldan raise another question and I'll give as much info as I can (which is not a huge amount, as stated I only do very limited NET development).