version numbers
-
this isn't directly c# linked as it can be applied to a lot of other languages, but there you go. when developing applications what do people normally name their versions as? major.minor.revision or also build number etc. i'd be interested to hear the standard or if there is one at all. also how do you cope with making patches (if you need to! ;)) surely you wouldn't have to release a new program each time and send it?? can't you have some some of file that updates the original? cheers, surgeproof ------------------------------------------------------- looking for hosting? ithium is good.
-
this isn't directly c# linked as it can be applied to a lot of other languages, but there you go. when developing applications what do people normally name their versions as? major.minor.revision or also build number etc. i'd be interested to hear the standard or if there is one at all. also how do you cope with making patches (if you need to! ;)) surely you wouldn't have to release a new program each time and send it?? can't you have some some of file that updates the original? cheers, surgeproof ------------------------------------------------------- looking for hosting? ithium is good.
As far as version numbers go, that kind of depends on how you build the app. What I prefer, is to have a nightly build process with version numbers that are
<major>.<minor>.<months><days>. Any builds outside of this would be the same, appending.<24hr time>, or some other unique identifier. The<months>and<days>represent how many months and days you've been working on the<major>.<minor>version. If I'm not using a scheduled build, I usually just do<major>.<minor>.*, which lets .NET decide what the rest should be. For larger apps, or those with frequent changes, that don't have scheduled builds, I'd do<major>.<minor>.<revision>.*. Michael Flanakin Web Log -
As far as version numbers go, that kind of depends on how you build the app. What I prefer, is to have a nightly build process with version numbers that are
<major>.<minor>.<months><days>. Any builds outside of this would be the same, appending.<24hr time>, or some other unique identifier. The<months>and<days>represent how many months and days you've been working on the<major>.<minor>version. If I'm not using a scheduled build, I usually just do<major>.<minor>.*, which lets .NET decide what the rest should be. For larger apps, or those with frequent changes, that don't have scheduled builds, I'd do<major>.<minor>.<revision>.*. Michael Flanakin Web Logthanks, this helps. any ideas about the upgrade/patch routine? and also, do you name all the version yourself or incorporate it into the code? can't you type something like version.major in your code? once again, thanks. surgeproof. ------------------------------------------------------- looking for hosting? ithium is good.
-
thanks, this helps. any ideas about the upgrade/patch routine? and also, do you name all the version yourself or incorporate it into the code? can't you type something like version.major in your code? once again, thanks. surgeproof. ------------------------------------------------------- looking for hosting? ithium is good.
You specify the version of the assembly using the
AssemblyVersionAttribute. You can also increment the version of only the file - keeping the assembly version, which is what is used for Type references, the same to facilitate easier updates - by using theAssemblyFileVersionAttribute. For instance, .NET 1.0 uses the assembly versions 1.0.3300.0, but the file versions (as of SP2) are 1.0.3705.228. If you examine your MANIFEST in your assemblies that target 1.0, you'll always see assembly references to versions 1.0.3300.0 for .NET 1.0 (1.0.5500.0 for 1.1). All this is to facilitate side-by-side installation of both the .NET Framework versions and applications that use these versions. In many cases, applications can work on newer frameworks for which they were compiled so long as you don't use obsoleted functionality and don't use reflection to access private members (you may get lucky and it may still work, but it isn't gauranteed). To learn more about versioning your apps - including how to redirect assembly bindings to newer or older assemblies, read the following articles:- How the Runtime Locates Assemblies (Step 1 especially)[^]
- Redirecting Assembly Versions[^]
- Creating a Publisher Policy[^]
Microsoft MVP, Visual C# My Articles
-
You specify the version of the assembly using the
AssemblyVersionAttribute. You can also increment the version of only the file - keeping the assembly version, which is what is used for Type references, the same to facilitate easier updates - by using theAssemblyFileVersionAttribute. For instance, .NET 1.0 uses the assembly versions 1.0.3300.0, but the file versions (as of SP2) are 1.0.3705.228. If you examine your MANIFEST in your assemblies that target 1.0, you'll always see assembly references to versions 1.0.3300.0 for .NET 1.0 (1.0.5500.0 for 1.1). All this is to facilitate side-by-side installation of both the .NET Framework versions and applications that use these versions. In many cases, applications can work on newer frameworks for which they were compiled so long as you don't use obsoleted functionality and don't use reflection to access private members (you may get lucky and it may still work, but it isn't gauranteed). To learn more about versioning your apps - including how to redirect assembly bindings to newer or older assemblies, read the following articles:- How the Runtime Locates Assemblies (Step 1 especially)[^]
- Redirecting Assembly Versions[^]
- Creating a Publisher Policy[^]
Microsoft MVP, Visual C# My Articles
thanks, this helps! :) surgeproof. ------------------------------------------------------- Science without religion is lame, religion without science is blind. --Albert Einstein The pioneers of a warless world are the youth who refuse military service. --Albert Einstein A question that sometimes drives me hazy: am I or are the others crazy? --Albert Einstein
-
thanks, this helps. any ideas about the upgrade/patch routine? and also, do you name all the version yourself or incorporate it into the code? can't you type something like version.major in your code? once again, thanks. surgeproof. ------------------------------------------------------- looking for hosting? ithium is good.
I'm not sure what the best solution for patches is. I would think that, if you have a modularized application, where you might have a bunch of DLLs and/or EXEs, you could have a patch that would replace whatever needed to be updated. Other than that, I'm not sure. I've never done a patch process before. Most of the stuff I've worked with has been either small Win Forms or Web Forms, which don't use patches - they just deploy the new version. And, as far as setting the version, I'm not sure. I didn't do that part. I want to say that there was something that was based off of either the source control or build tool. NAnt is supposed to be a good build tool. I haven't played with it myself, but am hoping to get a chance to give it a good look. Michael Flanakin Web Log