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.
Related
I am building a C# adding for Excel. In order to debug it, I need to launch Excel.exe with a command line argument containing the Debug or Release path to the addin.
For example:
Start External Program: C:\Program Files\Microsoft Office\Office15\EXCEL.EXE
Command line argument "C:\Dev\Project1\Project1\bin\Debug\Project1-AddIn64.xll"
However, I would like to replace "C:\Dev\Project1\Project1\bin\Debug" with an equivalent of $(SolutionDir) for C++ projects in VS. Is there a way to do this ? If it is not doable, is there a way to get around this ?
EDIT: please support me and get this added in VS by voting up the following idea: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6350738-support-for-macros-in-debugging-command-line-argum
Indeed, the macros cannot be used in the Start Options | Command line arguments
I see two solutions:
As the current folder is set to the $(TargetDir) when you Start an application you could refer to the solution folder like this: ..\..\..\ if the External program accepts a relative path. (I am not quite sure why you would ever want to refer to the solution folder, referring to the output/target folder makes more sense to me)
In the Post Build event (unregister) and register the component the way the component should be registered when deploying it (a proper setup). This way you only have to refer to Excel in the Start Action. This also immediately adds the benefit of testing a scenario that is more similar to production.
It's not exactly a fix, but this may help some people. If you create your project from the project template "Visual C#/.NET Core/Console App" instead of "Visual C#/Windows/Console App", this feature is supported. When I put "$(SolutionDir)" in the Application Arguments field on the Debug tab of the Project Properties window, it is expanded at run time. Note that you will need Visual Studio 2015 Update 3 or later.
I guess you could make use of post-build event to read in your file. #HansPassant explained it in VS2010 - Project Macro Variables in Start Options Command Line Arguments.
A short quote:
A possible workaround is a post-build event that writes a file that you read in your program. Like echo $(ProjectName) > "$(TargetDir)cmdargs.txt
You could substitute cmdargs.txt to appropriate file you want.
You CAN use the macros in the Command fields. I used procmon.exe to see what VS was looking for and indeed i could use $(SolutionDir)\..\Debug\thetoolname.exe as my solution was not in the root.
Im using VS2019 so AFAIK it is supported from this version but it most likely is supported in lower versions. Just use procmon to check the path that VS is attempting to resolve.
i am finding some example source codes for the MSIEmbeddedChainer & MSIEmbeddedUI. wix v3.0 has <EmbeddedChainer> command, but there's no info of how to use (or probably incomplete implementation). i want to chain my msis. however, there are very little details to this topic. msi 4.5 has very nice features with MSIEmbeddedChainer & MSIEmbeddedUI. unfortunately, wix v3.0 doesn't seem to support at the moment. i see the wix announced that wix burn project started along with wix v3.6. but i think there are long way to go for this implementation.
there are some developers wrote their own codes for this MSI chains with wpf and c#/c++. i just want to have a sneak, so i have an idea how to code them too. again unfortunately, i don't see any...
can anyone help please?
Burn.exe in Wix 3.6 onwards provides this feature by using Chain element and MsiPackage. Have a look at this.
an MSI chainer is nothing more than a program that you write yourself that calls your MSI's in the proper order with the proper attributes and properties. The MSIEmbeddedChainer element is actually included in WiX 3.0 (I am actually using it in my current istallation. Sadly I am not the one writing the chainer, I am only doing the MSI's. Try checking the WiX page for the element EmbeddedChainer (without the MSI) and you should see all the available elements.
I have an asp.net/C# app that uses subversion for source control.
My app automatically increases it's AssembleVersion and AssemblyFileVersion on each build which works like a charm, and displays the build number in the administration side of the site.
We keep track of AssembleVersion and AssemblyFileVersion's when we do deployment, however, when an issue arises and we need to roll back to a certain version, we have no idea which revision to target in subversion.
I have few ideas:
Save AssembleVersion as comment in each file
Have a keyword in commit comments that get's replaced by AssembleVersion on each commit(still need to figure out how to do it)
Any help and suggestions will be appreciated
Updated:
option "1" is actually a stupid idea,cause this will mean that everytime i build, all files will be marked as updated and when i commit, every single file will be updated
When I build, I put that build number everywhere.
I put it in a tag in svn.
I put it in the Assembly metadata of every assembly I build.
I append it to the end of the filename in my installers.
I put it in the footer of each of my deployed webpages.
I put it in the footer of my reports.
I put it in the splash screen of my client side apps.
I put it in the welcome screen for my installers.
The only thing I don't put it in is my coffee, which I take black.
All of this lets a maintainer know at a glance exactly where the code came from for what they're seeing, whether they're viewing a webpage, or looking at the properties of one of the built assemblies in Explorer, or whatever.
How about using tags.
http://svnbook.red-bean.com/en/1.1/ch04s06.html
Tags aren't really useful if you happen to build often. Maybe find a way to update Assembly version based on the svn revision instead? Also include the branch name, because they share the revisions.
And you should be able to extract the assembly version in your ASP.NET pages and print it programmatically in a footer or something.
You could tag the Subversion trunk with the AssembleVersion or AssemblyFileVersion, whichever makes the most sense.
You could also keep track of the Subversion revision number the same way you currently keep track of the AssembleVersion and AssemblyFileVersion when you deploy.
Apply a tag to your source tree after you have updated the AssemblyVersion and AssemblyFileVersion.
You could "branch for release". Before creating a release build you could branch the trunk and then create a tag on the new branch with the release version number.
+ release tag
/
+--------------------- release branch
/
----------+----------------------------------------------------- trunk
This would allow you to keep track of all individual releases in SVN. It would also allow you to make isolated bug fixes on release branches that could be released as patches. The bug fix could then be merged back into the trunk.
+ + patch release tag
/ /
+-----------------+-+---- release branch
/ | merged fix into trunk...
----------+----------------------------------------------------- trunk
Tags/branches are definately the recommended approach here.
You can also (or additionally) include the svn revision number in your AssemblyInfo. One approach is to use the AssemblyInfo task from the msbuildtasks project at http://msbuildtasks.tigris.org
For more info, google msbuild svn revision assemblyinfo
You could then do without tags/branches, as you can always check out a specific revision, and/or create a branch from a specific revision.
Another option is to use last changed revision as your build number. This means each time you build you auto-tag. It's easy with hudson/jenkins since you have an environment variable SVN_REVISION. The problem is that revision number get very large and hallway discussions about 1.0.0.20456 vs 1.0.0.20489 are a mouthful.
Are there any good programs out there to compare to compile .NET assemblies?
For example I have HelloWorld.dll (1.0.0.0) and HelloWorld.dll (2.0.0.0), and I want to compare differences how can I do this?
I know I can use .NET Reflector and use the Assembly Diff plugin. Are there any other good tools out there to do this?
Ways to Compare .NET Assemblies suggests
Commercial:
NDepend
Free:
JustAssembly (only shows differences in API)
BitDiffer (same)
Reflector Diff Add-in (which you've already discovered, but not available anymore)
Existing compare tools like Beyond Compare (commercial) can do this by special configuration. Here's how to do this for Beyond Compare:
Go to Tools → Options
Click New.., select "Text format", click OK
Give it a name (say, EXE, or DLL), and specify the mask as *.exe or *.dll
Click on tab Conversion and select "External program (Unicode filenames)"
Under "Loading", specify the path to ildasm and add %s /OUT:%t /NOBAR (i.e.: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\ildasm.exe %s /OUT:%t /NOBAR)
Make sure to check disable editing.
Click Save, then Close
Restart BC and open two exe files to compare, it should decompile into ilasm automatically now.
You can also add syntax highlighting to this new format. I plan to send the syntax file to them so that it'll become available to share.
Two ways.
You could ILDASM and diff with classic tools.
Or you could use NDepends, which will cost for that feature.
[Piece to C# bloaters..]
I just had to compare two revisions of the same DLL, which had the same version (I needed to implement a small hotfix, and deploy the DLL in production, but I wanted to make sure that no other changes leaked into code). Ideally, I would want the Assemby Diff add-in to show me the difference, but it does not work (it thinks that I'm comparing a DLL to itself). So this is what I did:
Created two folders to hold disassembled source files.
Used the Reflector's Export option (from context menu) to generate source files from each DLL in the folders created in previous step.
Used the free DiffMerge tool to compare two directories; the tools showed me the modified files and the difference.
It's a bit kludgy, but seems to work. I wish the Assembly Diff add-in worked, though.
UPDATE: The latest version of the Assembly Diff add-in is supposed to fix the issue of comparing two versions of the same assembly. Give it a try.
The tool NDepend offers many features to compare compiled .NET assemblies.
First from the NDepend Start Page click: Compare 2 versions of a code base. This will let you provide older and newer versions of your assemblies.
Then after NDepend has analyzed both older and newer assemblies, you can use the panel Search by Change. It is dedicated to browse assemblies code diff. Notice that:
If source code is available, just right click an element and click Diff Source. In the NDepend options you can plug to NDepend any code diff tool (Visual Studio, Beyond Compare...)
If you don't have the source code and just only the raw assemblies, there is the option Compare older and newer version disassembled with ILSpy. ILSpy v7.0 and upper versions are supported. This menu works on assembly, namespace, type and method level and you can choose to decompile to C# or IL.
Notice also in the screenshot that a CQLinq code query is generated to browse the diff.
from m in Application.Methods
where m.CodeWasChanged()
select new { m, m.NbLinesOfCode }
Many others default diff queries and rules are proposed by default, that will let you browse .NET code diff in a smart way.
Types that used to be 100% covered but not anymore
API Breaking Changes: Methods
Avoid making complex methods even more complex
Avoid decreasing code coverage by tests of types
From now, all types added or refactored should respect basic quality principles
Avoid transforming an immutable type into a mutable one
Heuristic to find types moved from one namespace or assembly to another
Disclaimer: I am one of the developer of the tool.
One more option is LibCheck from Microsoft.
Pretty old console tool for just getting public API diff. I could not run without debugging and retargeting to a more recent .net version. However, it gave me very clear output and I am going to use it later.
Here is an article with screenshots.
Here's a thinking outside the box approach whcih works fine.
Dump your old and new assemblies with dnSpy, dotPeek or JustDecompile into projects.
Create a new Git repo and commit the old assembly code first.
In your local repo folder delete all the files/folders except for ".git" and paste the new assembly files.
Either commit the new changes and view changes on say Github or use a Git viewer like Fork. Easy code comparison for free.
Java has a nice one: Semantic Diff Utilities
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.