I'm trying to find a more meaningful way to handle versioning for my app and I came acrossed this KB article
http://support.microsoft.com/kb/556041
Basically it's recommending that the Assembly version be fixed, and the File Version be imcremented for each build. Now this makes perfect sense to me but for the life of me I can't seem to implement it.
The below snippet auto increments both Assembly version and FileVersion.
[assembly: AssemblyVersion("1.0.*")]
While this next one seems to set a fixed Assembly version of 1.0.0.0 and a fixed File Version of 1.0.*.
[assembly: AssemblyVersion("1.0")]
[assembly: AssemblyFileVersion("1.0.*")]
Incidentally, the Product Version in Details tab of the file properties reads 1.0.* now as well. Now I can fix the Product Version in the file properties with this...
[assembly: AssemblyInformationalVersion("1.0")]
But that doesn't help with my original task. Out of curiosity I tried the below and the File version changed to 2.0.*, so it is at least using it. It's just not auto incrementing.
[assembly: AssemblyVersion("1.0")]
[assembly: AssemblyFileVersion("2.0.*")]
So from what I can gather the only version number that auto increments is the Assembly Version, but on the off chance you haven't specified a File Version it gets set to the same as the Assembly Version.
Does anyone know of a way to auto increment the File Version while leaving the Assembly Version fixed?
Yes it's a bit silly, Microsoft seems to have got it the wrong way round. AssemblyVersion is used in the .NET assembly versioning system, so you should never auto-increment it, but AssemblyFileVersion is written to the file version entry in the file's version resource, so you might reasonably expect it to always auto-increment by default.
I'm sure that there are some 3rd party build systems out there that can do this for you, but I just wrote a little command line C# app to do it, and it gets run on every project as part of our build process. It's very straightforward:
Read the AssemblyInfo.cs file line by line.
Do a RegEx search for the AssemblyFileVersion line, capturing all four version parts into separate capture groups. You could parse it yourself, but a regex will do all the detecting and parsing in one go, so it seems silly not to take advantage.
Once you have the four integers, implement your own incrementing logic as you see fit.
Related
In AssemblyInfo.cs:
[assembly: AssemblyVersion("1.0.*")]
Will generates a 1.0.x.x four digits version number.
Which, if I use this nuspec metadata:
<version>$version$-test</version>
generates an error when packing:
The version « 1.0.5431.31092-test » does not follow semantic version control instructions
Is there a simple way around this?
Not possible, an assembly's version is stored in the System.Version class, that consists of Major, Minor, Build and Revision.
EDIT: I was a bit to hasty to answer. When you use the AssemblyVersionAttribute's constructor with a string containing an asterix, all four properties of a version will be generated. The only way to cause a version with lesser numbers is to specify the exact version number, without asterix, i.e "1.0.1". See: http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.assemblyversionattribute(v=vs.110).aspx
What you could do, if you want lesser numbers in the version and also generated version numbers, is to use an external tool altering version numbers in the pre-build step.
No post processing is necessary, NuGet is using [assembly: AssemblyInformationalVersion("")] as a package version, set it to whatever number of componets you please and be done with it.
P.S I strongly encourage you to also set AssemblyVersion as this is the one .NET actually uses, at least set it to auto increment
Some reading available here
Full example
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyInformationalVersion("1.0")]
Will generate a package Lib.1.0.nupkg containing assembly with 1.0.x.x version, version you will be dealing with is 1.0
Whenever you want to change nuget version, just change AssemblyInformationalVersion, not touch AssemblyVersion at all
the title probably doesn't make much sense as to what I am trying to achieve, its kind of difficult to explain in a brief bit of text.
I have created a project both in C# for Windows/Mono projects and an Android version of the library.
When I upload the library to my server for users to download and use in their own projects I want the library to have the following sort of name
MyLibrary_Version.1.0.dll for Windows
MyLibrary_Version.1.0.jar for Android
When the project is built and the library is referenced it is referenced using the name MyLibrary.dll or MyLibrary.jar.
I'm not sure how I can ensure that each project that is referenced by my library can work OK when it has a different name, i.e. include the version number.
This must be possible, as other companies who provide library do the same sort of thing but I can't see anyway how this can be done.
Thanks for any help you can provide.
Not sure this is the response your looking for, but here goes...
in your c# project in the properties folder, edit your assemblyinfo.cs file and add a version numberin there like..
[assembly: AssemblyVersion("1.2.1.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]
The * will increment the count by 1 each time you build.
When your app consumes the dll, you should be able to specify the matching version of the dll, in the assembly declaration for that dll in the app.config. (if using provider model)
Or through reflection in your code to return an error if the incorrect DLL is included in with App release.
If you go to:
Solution Explorer -- > Properties -- >(double click) Assembly Info
you will see some information about assemblies for your project. At the end of it there are some different versions for each assemblies that they are:
Major Version
Minor Version
Build Number
Revision
And I Understood that These are numbers of these:
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
but I don't understand the meaning.
When the project is built those values are baked into the dll so that when you view the dll's properties via the Windows File System you will see that version number.
Managing those numbers is a bit of a pain in the ass. In older projects you'll often see some ugly build scripts that do things like check out the files then increment the number then check them in then continue with the build... The most elegant solution I've seen is implemented by TeamCity (though there are probably similar products); it basically copies all of the projects files to your build server, then it edits it's local copy with values it maintains (you can alter or reset them in UI), then builds the project. This allows it to never touch source control while giving you good control over dll versioning.
They are whatever you want them to mean. You are free to use your own definitions for each section of the version number; beyond the fact that different numbers are different, there is no functionality driven off of this by the language.
AssemblyVersion is used in the strong name of the assembly(signing).
AssemblyFileVersion is displayed by Windows in the Version tab on the file properties.
AssemblyInformationalVersion is used in the assembly manifest for things like NuGet.
As far as how to version, I recommend Semantic Versioning, which uses a 3-part version number:
Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.
AssemblyVersion used for strong name of the assembly with sn.exe, but
AssemblyFileVersion display the version on the file properties.
I found a free program on the web that was .NET 4.0, but had to copy over the code to compile VS2008. I'm thinking the way cultures is handled must be different in the versions of .NET.
I'm getting this error:
System.Resources.MissingManifestResourceException: Could not find any
resources appropriate for the specified culture or the neutral
culture. Make sure "A.B.C.Resources.ExceptionMessage.resources" was
correctly embedded or linked into assembly "A.B.C.csproj" at compile
time, or that all the satellite assemblies required are loadable and
fully signed.
It's a C# .dll (class library), and I'm calling it from a Console Program.
It does have a strong-key file assigned to it.
It's blowing up on any statement like this:
return ResourceManager.GetString("XYZ");
It looks like all the resources are in English, and that's the only language I need.
I'm just looking for how to avoid the exception.
When I copied over files, and rebuilt a new VS2008 project, there was no hierarchical relationship in Visual Studio Solution Explorer for the resource file. For example, ExceptionMessage.resx and ExceptionMessage.Designer.cs were at the same level; whereas normally the Designer.cs file is indented under the .resx file. I'm not sure what that happened.
So what I did was create a new .resx file, and carefully copy over using NotePad and filemerge programs, pieces of the .resx file and .cs file. Then it worked fine.
I'm still not absolutely sure what the problem was, but I know this fixed it. Lost about 5 hours today on this issue.
It might be worth to compare the [assembly: AssemblyCulture("")] properties in the assemblies from both your version 4 and version 3 solutions.
The default is - I think - none.
MSDN documentation:
Putting this attribute on an assembly and using something other than
the empty string ("") for the culture name will make this assembly
look like a satellite assembly, [...]
Perhaps you need to define it explicitly OR it already is defined but should not be?
I've had this difficulty and found that the cause had to do with Assembly name and Default namespace from project properties. It helps to set them both the same, or something to that effect.
On the project I work on we encountered an odd error. This was caused by some funny manipulation of version numbers because of some odd branching we did. We have resolved the issue but I'm curious if I can get an explanation about the behavior msbuild is exhibiting. The same behavior was observed when building using Nant and Visual Studio 2008.
The Setup: Version numbers for assemblies are controlled by a common file that is linked into the properties of all the assemblies. This is done to keep them all in synchronization with each other. However, there are some assemblies we have that are pre-compiled and are only occasionally built. They are used for serialization and are partly generated from XSD's. Since serialization doesn't change that often they obviously don't need to be rebuilt that often.
The Situation: The version number in the linked file was updated. After this happened the pre-compiled assemblies were rebuilt because serialization changed. After this happened it was decided that a lower version number was needed. The common linked file was updated again, but to have a lower version number than it did before.
The Problem: After this last update to the version number the build stopped copying some of the dlls to the output directory of one specific project stopped working properly. We'll call this project A. A has a dependency on assembly B and assembly B has a dependency on assembly C and assembly C depends upon one of the pre-compiled dlls. This seems like a long chain, but this chain is key. The other key fact is that A does not have a direct reference to C. When A is built before lowering the version number C is copied into the output directory. This issue is, after the version number being lowered C no longer is copied into the output directory. There were three ways this problem could be corrected. If any of these changes are made then C is copied to the output directory properly.
Add a direct reference to C in A's project.
The version number is changed back or made to be higher than it was when the pre-compiled dlls were built.
Rebuild the pre-built assemblies with the version number update.
The third option was how the issue was resolved. My question is is this a bug with msbuild or the intended behavior? What would the purpose of this behavior be? Why instead of creating an error does it just not copy the dll to the output directory?
producing a newer assembly with a lower version is perhaps questionable. what happens when you need to make a newer one again?
basically if you make a new version of something, increase the version number; problem solved as you found in your second solution.
in answer to your question - it is intended behaviour that files with lower or same version numbers do not overwrite others