 |
General Programming »
Macros and Add-ins »
VS.NET Add-ins
Intermediate
License: The Code Project Open License (CPOL)
Versioning Controlled BuildBy Julijan SribarA Visual Studio add-in and command-line utility that automates versioning of .NET and VC++ projects |
C#, Windows, .NET1.0, .NET1.1, .NET2.0VS.NET2003, VS2005, VS2008, Dev
|
|
Advanced Search Add to IE Search |
|
|
|
||||||||||||||||
When a new project is created, Visual Studio generates an AssemblyInfo file inside it. This file, among other things, contains the AssemblyVersion attribute. Version information consists of four integer values: Major Version, Minor Version, Build Number, and Revision. The default pattern for version information generated by Visual Studio 2002/2003 is 1.0.*, i.e. Major Version is set to 1, Minor Version to 0, while Build Number and Revision are generated automatically. More specifically, during the build process, the Build Number is created from the number of days elapsed since January 1, 2000, whereas Revision is created from the current local time of the day. A similar rule applies for VB.NET projects and Managed VC++ projects, except that the project information files are named AssemblyInfo.vb and AssemblyInfo.cpp, respectively.
However, this automatism may sometimes be annoying. For example, if you want to assign the same version to several projects. Even if you rebuild all projects inside the same solution, they may obtain different Revisions. Moreover, if you want to rebuild an older revision from the versioning system, you will have to set the version manually.
Visual Studio 2005 generates the AssemblyVersion attribute in the form 1.0.0.0, by default (i.e. there is no wildcard in the version), and also adds the AssemblyFileVersion attribute. Note that the user can also include the AssemblyInformationalVersion attribute that is assigned to the Product version.
As suggested on George Shepherd's Windows Forms FAQ, a simple solution to synchronize versions among multiple projects is to extract version information into a single file and reference it from each project. However, that approach has one drawback: if an assembly is used in different solutions, you may end up having two different versions of actually the same assembly.
The purpose of this add-in is to help the user to manage and synchronize all these versions, especially for solutions that contain several projects. There is already a solution provided by Darriel Liu (Build Number Automation for Visual Studio .NET Projects) where he created a Visual Basic macro that modifies the AssemblyVersion, basically following the original approach by Microsoft. This solution is written in C#, and extends the original idea, providing GUI for more control, and enabling managing all three version types either independently or synchronized. It also provides a means of automatism to simplify versioning as much as possible.
Moreover, add-in supports Visual C++ resource file versions (FileVersion and ProductVersion) in unmanaged projects and setup project versions.
Last but not least, command line utility does not only provide batch counterpart of the add-in but additionally extends the functionality to Visual C++ 6.0 projects.
This article first provides basic information on versions and how they are managed in this tool. Implementation details follow, including a description of specific techniques used. The reader familiar with versioning and not interested in implementation details may skip to the final section that provides the basic instructions for users.
This section deals in more detail with versions available in the .NET Framework, and describes the logic used in the tool.
As already mentioned in the introduction, there are three types of versions supported by the .NET Framework: AssemblyVersion, AssemblyFileVersion, and AssemblyInformationalVersion, corresponding to AssemblyVersionAttribute, AssemblyFileVersionAttribute, and AssemblyInformationalAttribute, respectively. The actual values of attributes are defined in the AssemblyInfo file (Visual Studio 2005 hides this file inside the Properties subfolder):
// ...
[assembly: AssemblyVersion("1.1.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]
[assembly: AssemblyInformationalVersion("1.2.1.0")]
// ...
Note that the content sample given is for a C# AssemblyInfo file; for other languages, syntax differs somewhat.
As the reader probably knows, AssemblyVersion is stored in the metadata table of the assembly built. It is used to uniquely identify an assembly when referenced from other assemblies. Moreover, the CLR uses this version when binding to strongly named assemblies (more details may be found in the book, "Applied Microsoft .NET Framework Programming" by Jeff Richter). AssemblyFileVersion and AssemblyInformationalVersion are informational only.
These values are incorporated into the assembly, and displayed on the Version tab of the compiled assembly properties window:
The file version displayed at the top of the pane corresponds to the AssemblyFileVersion attribute, and the other two attributes are displayed inside the "Other version information" group box. If any of the attributes are missing in the AssemblyInfo file, a value of another available attribute is assigned. For example, if only the AssemblyVersion attribute is defined, then its value is used for the file and product versions. If no version is defined, values are defaulted to 0.0.0.0.
If you check the descriptions of the AssemblyVersionAttribute, AssemblyFileVersionAttribute, and AssemblyInformationalAttribute classes in the .NET Framework documentation, you may notice that each of them contains a Version property (in the AssemblyInformationalVersionAttribute class, the property is named InformationalVersion). This property is a string, which could mean that it may contain any valid string and is not restricted to a dot-separated list of four integers. However, if you try to change the version strings to another form, the compiler will issue a warning or an error. At least one integer (i.e. Major version) must be supplied. Therefore, the following strings are valid versions:
1
1.2
1.2.3
1.2.3.4
A single asterisk may be used in AssemblyVersion only as a wildcard for the Build and Revision, or Revision only:
1.2.*
1.2.3.*
Interestingly, although there is a class Version in the .NET Framework that is meant to represent the assembly version, it is not used by any of the above mentioned version classes.
Although for managed C++ projects, an AssemblyInfo.cpp file (with the AssemblyVersion value) is created, its content is not displayed in the properties of the compiled code. As for unmanaged C++ applications, a resource file (*.rc) is used to store version information, instead:
// ...
VS_VERSION_INFO VERSIONINFO
FILEVERSION 1,0,0,1
PRODUCTVERSION 1,0,0,1
// ...
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "041a04b0"
BEGIN
// ...
VALUE "FileVersion", "1, 0, 0, 1"
// ...
VALUE "ProductVersion", "1, 0, 0, 1"
END
END
// ...
END
As you can see, the file and product versions appear at least twice: below the VS_VERSION_INFO block, and inside the StringFileInfo block. Moreover, the StringFileInfo block may contain more than one block, each for a different language selected. Also note that separators in versions may vary, depending on the localization settings.
It should be pointed out that for managed C++ projects, the version information block is not generated automatically in the resource file, but the developer must add it, e.g. in the Resource View window, or manually edit the content of the resource file.
In contrast to other project types, setup projects have only Product Version. It may consist of up to three dot-separated integers, and is stored in the project file (with a .vdproj extension) itself (and not in a separate file):
// ...
"Product"
{
"Name" = "8:Microsoft Visual Studio"
"ProductName" = "8:SetupProject"
"ProductCode" = "8:{1DC3B403-8041-43BD-BA39-588EDA4325E4}"
"PackageCode" = "8:{C2627176-ED8C-40B0-B9E2-095D4612A21C}"
"UpgradeCode" = "8:{1FD6C202-4297-4AAE-8C48-DDB81C44EC44}"
// ...
"ProductVersion" = "8:2.0.0"
// ...
}
As you may notice, the number 8 followed by a colon precedes the Product Version value. This number only indicates the type of data to follow (8 stands for string).
When the product version of the setup is modified from the Visual Studio environment, the user is asked to modify ProductCode and PackageCode. These codes (given as GUIDs) are used to identify an application during subsequent installations or upgrades. So, the tool that modifies the Product Version should be able to create new GUIDs for both codes.
The AssemblyInfo file is usually modified for the first time when a project is created: the developer enters information such as company name, copyright, and product description. After that, it is rarely modified, often only to change the version information. So, when a source code is modified after version change, the corresponding "file modified" timestamp will be more recent than the timestamp of the AssemblyInfo file.
When the user starts the tool from any of the four commands, the tool browses projects in the currently opened solution. For each file in a C#, VB.NET, VJ#, or VC++ project, the timestamp of when the file has last been saved is compared to the timestamp of the corresponding AssemblyInfo file. If there is a file with a more recent timestamp (which means that the source code has been modified after the previous version change), the project will be marked for version update. In the GUI, the project will be displayed with a check mark in the main application form with the next version proposed, the proposed version being created according to the tool settings. The user may change the selection or even modify the next version(s). After the build is triggered from the form, the application updates the assembly versions of all the selected projects and (re)builds the solution. Batch commands implement the same procedure, without interrupting for user intervention.
Depending on the configuration settings, the tool also includes Visual C++ resource files (that may contain ProductVersion and FileVersion ) in the numbering scheme: if a resource file contains version information, its timestamp is compared to the timestamps of all the files contained in the project. If the project (e.g. a managed C++ application) contains version info in both the AssemblyInfo and the resource files, the larger version is used as a reference.
It should be pointed out that if a Visual C++ project contains a resource file but no AssemblyInfo file, adding a new resource will always put the latest timestamp on the resource file, and the project will not be marked for version update. However, it is worth noting that adding a new resource usually modifies the resource.h header file that is saved immediately before the resource file. So, to circumvent (at least partially) the mentioned inconsistency, the reference timestamp (used to compare timestamps of other files in the project) is created from the resource file timestamp offset by one second.
Since setup projects consists of a single file, the timestamp comparison logic cannot be implemented for them - the user has to select these files for version update manually.
The download demo project is a VS2003/VS2005 solution with several distinct projects:
IDTExtensibility2 interface in order to create the add-in Originally, the solution was created on VS2002 for .NET Framework 1.x. With version 2.0 of the add-in, support for VS2005 has been added. This required some rearrangements (as described later in the section Migration to .NET 2.0) and the project Implementation has been duplicated (ImplementationVS8) to build the tool for the new environment. Note that Implementation and ImplementationVS8 share the same source code, using conditional compilation in order to distinguish parts of the code specific for different environments.
The greatest challenge in the project was to utilize the VS.NET environment automation since it is rather poorly documented and hard to debug. Besides, several custom controls and unique solutions have been employed. Some of them are described in the following sections.
The add-in established connection to Visual Studio Environment through the Connect class whose skeleton is automatically generated by the Add-in Wizard. The following methods of the class are used:
OnConnection: EnvDTE) object, and stores it for further use by the tool. OnDisconnection: Stores the current configuration and removes the toolbar and the menubar. OnStartupComplete: Updates the state of add-in commands. QueryStatus: Disables and enables add-in commands (using the state of the Build and Cancel Build commands as reference); for example, the add-in is disabled when there is no solution open or when the VS environment is in the process of compiling or building. Exec: Opens the GUI or executes one of the batch commands. The abstract SolutionBrowser is a base class for the "workhorse" VSSolutionBrowser, VS7SlnFileReader, VS8SlnFileReader and DswFileReader classes that manage project information. VSSolutionBrowser is used in add-in and utilizes Visual Studio .NET automation to browse the solution and gather all included project information. It handles project information, such as all project items relevant for version update, file save time comparisons, and VS environment settings. Command-line utility counterparts (VS7SlnFileReader, VS8SlnFileReader and DswFileReader) do the same job parsing corresponding solution (*.sln or *.dsw) files as well as included project files.
On tool startup, SolutionBrowser derived class browses the solution selected, and gathers information for each project: project type, full name (including path) of AssemblyInfo (and optionally, *.rc and *.vdproj) file(s) in which versions are stored, current values of all version types, and a flag indicating if the project has been modified since the last version update.
The AssemblyVersions class contains a set of ProjectVersions, each of them representing one of the version types. ProjectVersion is capable of comparing and incrementing versions as well as applying string patterns with wildcards. The ProjectInfo class contains project information actually displayed in the ListView. The AssemblyInfoStream, ResourceFileStream, and SetupVersionStream classes are derived from the abstract VersionStream class, and are responsible for retrieving and storing versions in the corresponding files.
The MainForm class represents the main window containing three tabbed ProjectsListViews (derived from the ListView class) of all the projects, with their current and proposed next versions, with one listview for each type of version. To avoid the well known problem of TabControl flickering when it is being resized, a control derived from UserControl has been used.
The main window contains several buttons on the right-hand side of the ProjectsListView to manage project selection, as well as buttons to trigger save and build actions. It also contains a VersionUpDown edit box in which the user can manually define a new version pattern to apply to selected projects.
ProjectsListView is a custom drawn listview control. Custom drawing was required to allow dynamic changing of item appearance: items are displayed in different colors depending on version availability and validity, or are displayed grayed when the item is not checked. Excessive flickering has been reduced by implementing the technique described in the article, Flicker-free ListView in .NET - Part 2.
A control derived from TextBox is embedded into ProjectsListView to allow in-line editing of the "to be version", as described in the In-place editing of ListView subitems article. It should be noted that the embedded TextBox with the default value of the Multiline property (false) has a finite smallest size. This size is larger than the size of the listview cell, which makes the appearance of the in-line editing control awkward. To fix this, EmbeddedTextBox is made multiline, and the OnKeyPress method has been overridden in order to capture the Enter key and avoid skipping to the next line.
ProjectsListView also overrides the OnItemCheck method to prevent checking items that do not have a valid version.
The VersionUpDown control is a user control consisting of two controls: VersionTextBox and SpinButton. The VersionTextBox is a control which imposes a restriction on the user whereby when entering the version, only a sequence of four integers, asterisk or plus characters, delimited with dot characters, can be used. The SpinButton is derived from the VScrollBar class.
VersionTextBox is derived from the TextBox, and overrides some of the event handlers to ensure specific behavior. OnKeyPress has to be overridden to prevent the user from entering anything but digit or asterisk. Moreover, four sections of the version sequence are virtually split into four blocks, each having its own Tab stop. To establish this, the PreProcessMessage method had to be overridden to handle TAB, HOME, END, BACKSPACE, DELETE, and ARROW keys.
To keep the internal tab order in synch with the dialog tab order (when the next control in the dialog is back-tabbed, the last block must be selected), two delegate instances are defined and added to the LostFocus events of the Next and Previous controls:
override protected void OnParentVisibleChanged(EventArgs e)
{
base.OnParentVisibleChanged(e);
if (TopLevelControl != null)
{
Control nextControl = GetNextTabControl(Parent, true);
if (nextControl != null)
nextControl.LostFocus += new System.EventHandler(
OnNextControlLostFocus);
Control previousControl = GetNextTabControl(Parent, false);
if (previousControl != null)
previousControl.LostFocus += new System.EventHandler(
OnPreviousControlLostFocus);
}
}
// searches for the next control that has a tab stop
private Control GetNextTabControl(Control ctl, bool forward)
{
do
{
ctl = TopLevelControl.GetNextControl(ctl, forward);
if (ctl == null || ctl == this)
return null;
}
while (ctl.TabStop == false);
return ctl;
}
// selects the last block
private void OnNextControlLostFocus(object sender, EventArgs e)
{
SelectionStart = Text.Length - 1;
}
// selects the first block
private void OnPreviousControlLostFocus(object sender, EventArgs e)
{
SelectionStart = 0;
}
In order to prevent the selection to be extended across delimiting dots, it was necessary to override the OnMouseDown, OnMouseMove, and OnMouseUp event handlers. Also, by overriding the WndProc method, the "Select All" command has been restricted to a single block, whereas the context menu, undo operation, as well as all clipboard related operations have been disabled.
The WindowAdapter class is used to pass the VS environment main window as an owner window of MainForm and PromptUnsavedDocumentsDialog when they are displayed as modal forms. The PromptUnsavedDocumentsDialog mimics the dialog that pops up if "Build and Run Options" on the "Project and Solutions" page of the VS Environment options is set to "Prompt to save changes...". Namely, to prevent the popping up of this dialog when the add-in has already started (thus blocking its execution), the application will first check for the unsaved documents, then pop-up PromptUnsavedDocumentsDialog, if necessary, and finally temporarily disable the saving of open documents.
The MessageFilter class is used to handle the 'Application is busy' and 'Call was rejected by callee' errors which often appear when calling Visual Studio automation and may prevent add-in to start at all (c.f. Fixing 'Application is Busy' and 'Call was Rejected By Callee' Errors article).
The AssemblyInfoStream, ResourceFileStream, and SetupVersionStream classes (derived from the abstract VersionStream class) are used to read current and save new versions. Regular expressions are used to locate, extract, and save new versions.
In .NET 2.0, the Framework Class Library has changed a bit. For example, the command bars have been moved from Microsoft.Office to the Microsoft.VisualStudio.CommandBars assembly, and the use of EnvDTE80.DTE2 is preferred over the old EnvDTE.DTE class. Although functionalities of the classes used have not changed significantly (most of them have been extended), the fact that some classes are moved to the new Framework assemblies makes previous versions of the add-in useless for the new IDE without code modifications.
Since the functionality of the add-in remains the same, regardless of the .NET Framework change, the code could be simply recompiled with a few minor changes in the source code and the references to the .NET Framework assemblies updated. But in such an approach, compatibility with previous versions of the VS IDE would be lost. To leave the source code compatible with the previous .NET Frameworks, conditional compilation statements have been inserted wherever necessary. Actually, in all cases except one, it was sufficient to insert:
#if VS8
using EnvDTE80;
using DTE = EnvDTE80.DTE2;
#endif
into every source file that used the DTE class.
Using the following conditional preprocessor directives has solved the problem of command bars being defined in different assemblies:
#if VS7
using Microsoft.Office.Core;
#elif VS8
using Microsoft.VisualStudio.CommandBars;
#endif
To generate two distinct assemblies from the same source code, the corresponding project file has been duplicated, both projects containing exactly the same source code, but defining different conditional compilation constants (VS7 and VS8 for VS 200x and VS 2005/2008, respectively) and referencing different .NET Framework assemblies. Of course, to distinguish versions, the outputs were named differently: BuildAutoIncrementVS7 and BuildAutoIncrementVS8.
In order to use one installation set and to have only a single add-in registration for all IDE versions, the code was split into parts common to both Framework versions and those specific to each version. The common startup code detects which Framework is currently active, and loads the appropriate main assembly. By utilizing reflection, the main class that implements the IAddin interface is searched for in that assembly, and an instance of that class is created. The IAddin interface is defined in the Common assembly. A somewhat simplified code is provided below:
int runtimeVersion = Environment.Version.Major;
Assembly assembly;
switch (runtimeVersion)
{
case 1:
assembly = Assembly.Load("BuildAutoIncrementVS7");
break;
case 2:
assembly = Assembly.Load("BuildAutoIncrementVS8");
break;
default:
return;
}
// in the main assembly find the type that implements IAddin
// interface and create an instance of it
Type[] types = assembly.GetTypes();
foreach (Type type in types)
{
if (type.IsClass)
{
if (type.GetInterface("IAddin", true) != null)
{
ConstructorInfo ci = type.GetConstructor(Type.EmptyTypes);
m_addin = (IAddin)ci.Invoke(new object[0]);
}
}
}
Methods in the startup module just forward calls to the appropriate methods of the main implementation class.
The application is also able to handle code under SourceSafe control: it will automatically check out items if necessary. However, to fully exploit this automatism, please note that SourceSafe must be configured so that the date and time on local files are set to the modification date and time when checked out (c.f. figure below) and not to the default "Current" value:
Also, you are advised to set "When checked-in items are edited" (in the Options dialog, Source Control category of the Visual Studio) to "Check-out automatically". Otherwise, you'll be prompted each time to checkout items manually. Moreover, in that case, it is pretty tricky to checkout items from the code since the call to the following method fails:
public static bool CheckOutItem(string fileName, DTE dte)
{
if (dte.SourceControl.IsItemUnderSCC(fileName) &&
!dte.SourceControl.IsItemCheckedOut(fileName))
return dte.SourceControl.CheckOutItem(fileName);
return true;
}
To avoid such situations, the idea provided by Catalin Stavaru has been implemented: items in the Solution Browser of the VS environment are selected programmatically and then the check-out command is issued. Readers interested may find the implementation details in the SolutionExplorerCheckoutHelper class.
After the installation, a menu named VCB as well as a new Versioning Controlled Build toolbar (c.f. figure below) will be added. They contain four items, as described below:
Depending on the selection in "Build and Run Options" ("Options" - "Environment" - "Projects and Solutions") of the VS environment, the actions 1, 2, and 3 will save all currently opened files first. The user can assign a shortcut key to any of the above actions (this was a requirement by several users).
In addition, VCB menu contains four additional entries:
When a GUI command is started, the add-in browses the currently open solution for all the projects and displays their current versions, if available. It also proposes the next version, according to the increment schema defined in the tool settings. Items for which a code change has been detected are displayed in green, and are automatically marked for update. Items for which no code has been detected or for which no valid version information is found are initially displayed grayed.
Versions are displayed on three tabbed listviews, each listview for one of the version types: AssemblyVersion, AssemblyFileVersion (i.e., FileVersion), and AssemblyInformationalVersion (i.e., ProductVersion). Tabs can be switched by clicking the appropriate button above the listview or by using the Ctrl+Tab key combination.
The user can check/uncheck items at their wish (only items with a valid version can be checked) - all commands will be applied to checked items only. Please note that, depending on the configuration settings, it could happen that a project is checked in one listview but not in the other - in such cases, only the checked version is processed.
With the "Apply to all tabs" check box, the user can control if GUI commands are distributed to all listviews (i.e., to all version tabs) or are applied to the currently visible listview only. It overrides similar settings in the tool configuration.
The textbox below the listview contains a pattern that can be applied to checked items in the listview. On add-in start, this textbox contains the largest "to be version" proposed. However, the user can change it to any valid version. Moreover, it is possible to use asterisk (*) or plus (+) character followed by optional integer in the pattern. An asterisk on any version position (Major Version, Minor Version, Build Number, or Revision) prevents that position from being modified. This could be useful, e.g. when the user wants to increment the Minor Version of several or all projects simultaneously but leave individual Builds and Revisions as they are. The plus character will increment the corresponding version position by integer provided or by one if none is provided. For example, "1.0.*.+2" pattern sets Major and Minor version to 1 and 0, respectively, leaves Build unchanged and increments Revision by 2.
When the content of the textbox is modified, versions in the listview are compared to the version pattern. If the pattern could lead to a version that is lower than the project's current version, the project is displayed in red, serving as a visual warning for the user.
After pressing the Apply button, the pattern in the textbox is applied to all the checked items in the listview. Note that actual versions in files are not changed until the user clicks one of the "command" buttons, as described in Applying Changes subsection below.
A group of four buttons is provided to increment only one of the version components of the marked projects. Other version components will not be modified unless if so configured (c.f. Settings section below). A Minor component is always reset to 0 on Major change.
For existing versions, it is possible to manually edit the proposed version: just click the version in the "to be version" column, or select the corresponding item and press the F2 button. The new version is validated, and only versions with at least two dot separated integers and an optional asterisk character are allowed.
It should be pointed out that new versions are not actually saved as long as the Save, Build, or Rebuild buttons are clicked. Save button just saves new versions into the corresponding files, while Build and Rebuild buttons additionally issue corresponding commands to the Visual Studio environment.
Batch commands are equivalent to Save, Build, and Rebuild All commands in the GUI, except that they are executed immediately, without user intervention. Versions for projects are incremented automatically according to the settings of the tool, as described below.
Command line-utility supports VC++ 6.0 DSW files as well as VS2002/2003/2005/2008 SLN files. It shares configuration settings with the add-in version, but user can override these settings with appropriate startup switches. Please check CommandLine.txt file included in the setup for a brief description and list of startup switches.
During command-line utility setup, corresponding menu with two items are added to Programs menu. "AutoVer" entry starts the command-line utility with /g switch, opening the same GUI as the add-in does.
Settings are stored in the Configuration.xml file, in the user's ApplicationData folder. This file also stores the size of the main form and the widths of columns in the list view. A configuration file with default values is created when the user starts Visual Studio for the first time after the tool has been installed. Since it is created in the user's profile, each user can configure the tool independently.
The settings dialog consists of four tab pages described in the following sections.
In the "General" tab page, the user can select which version (AssemblyVersion, AssemblyFileVersion, or AssemblyInformationalVersion) will be displayed in the main form on startup. Moreover, this default version will be the one processed by the "batch" commands corresponding to the last three buttons or menu items on the toolbar and menu, respectively. If "Apply changes to all version types" is checked, all version types will be processed independently, except when "For each project synchronize all version types" is checked. With "Allow arbitrary Informational Version" the user can manually enter freeform text (not conforming version pattern described at the beginning of the article) into corresponding listview entry as described in Modifying Versions Manually subsection. "Include VC++ resource files" includes processing of ProductVersion and FileVersion contained in the corresponding .RC files.
To include Visual Studio setup projects into processing, the "Include setup projects" option must be checked. There is also an option to automatically generate new ProductCode and PackageCode when the version of the setup project is modified.
Once again, it should be pointed out that since a setup project consists of a single .vdproj file, there is no way of checking for any changes, so the user must mark the setup project manually for version change.
The "Numbering scheme" tab page allows the user to fine-tune the automatic numbering scheme. Selecting the "By default, increment:" option, the user can choose which part of the version is incremented automatically. This could be useful for those who prefer to leave an asterisk for the Build and the Revision (as originally proposed by Microsoft) and increment the Minor only: the asterisk mask for the Build and the Revision will be left unchanged (except if the user selects one of the "Reset..." options below).
When the "Date & time based Build and Revision numbering" option is checked, the numbers for the Build and the Revision versions will be generated using the date and time rule mentioned at the beginning of this article, inserting actual integers instead of an asterisk. Numbers are generated every time on the tool startup, according to the current local date and time.
Reset options provide a finer control on what happens with less significant numbers when Major, Minor, or Build Versions are incremented. Note that the Minor Version number is always reset on Major increment.
If "Replace asterisk with component values" is left unchecked, asterisks in versions will not be replaced by integer values.
This tab allows the user to modify some display options: the coloring scheme used to highlight the listview items and how items appear in the listview. For color selection, a separate control presented elsewhere has been developed.
The Batch Commands tab provides additional control for batch commands. The user can also suppress the report dialog displayed when a batch command is executed.
This tab contains the path to SourceSafe command-line (required by VCB command-line utility) and path to IIS root folder. These values are usually detected on VCB setup so user need not to modify them.
This tab contains settings for printing versions and exporting them to file. It is possible to select versions and order in which they will be exported, define indentation depth (number of characters for exporting to file or line heights when printing). Also it is possible to select fonts for printer output. For CSV file output, there is an option to select separator; depending on localization settings comma character is not always recognized as a separator.
If you have any previous versions of this tool installed, it is recommended to uninstall it first.
There is a separate installation for all versions of Visual Studio .NET (i.e. 2002, 2003, 2005 and 2008) and a separate one for a system with VS2005/2008 only. The first one detects Visual Studio versions installed, and creates add-ins for all available versions. In some cases icons on the toolbar and menus of Visual Studio 2005 will not appear; nevertheless the tool is fully functional. If you experience any problem, please check if add-ins are allowed in Visual Studio settings.
This tool cannot be installed on Express editions of Visual Studio since they do not allow add-ins.
I'd like to thank Don Bailes, Carl Mercier, David Smith, and many others for testing the add-in and helping me to fix the bugs.
MessageFilter added to handle COM messages that often blocked the application, projects with missing AssemblyInfo file are displayed too, buttons to increment Major, Minor, or Build versions for selected projects added (Revision is incremented always by default), and a Save button that only saves updated AssemblyInfo files added. AssemblyVersion, AssemblyFileVersion, and AssemblyInformationalVersion (i.e. product version). Note: this version works with VS2002/2003 and VS2005. However, in some cases, icons on the toolbar / menus of VS 2005, for some unknown reason, will not be displayed. FileVersion and ProductVersion in resource (*.rc) file of C++ project do not contain all components (Major.Minor.Build.Revision), only existing components in .RC file are updated. GUI, Build, Rebuild, Save, Configure and About entries. If any of them exists, run following command from Visual Studio 2008 command prompt:devenv /resetaddin BuildAutoIncrement.Connect
This command will cleanup commands left.
General 
News 
Question 
Answer 
Joke 
Rant 
Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads.
|
PermaLink |
Privacy |
Terms of Use
Last Updated: 6 Jan 2008 Editor: Deeksha Shenoy |
Copyright 2004 by Julijan Sribar Everything else Copyright © CodeProject, 1999-2010 Web18 | Advertise on the Code Project |
.
It works fine for VS 2005, but will not load for VS 2008. I am pulling what little hair I have left out. I have tried the suggestions I found below, all to no avail.