Versioning Solution
-
Hi, Is that possible to version a solution ?? If yes please help me out. We have 2 phases in our web application project. Now the 1st phase is over. 2nd phase is coming now. Now, the question is how I maintain 1st phase changes in the solution. Can I version the phase 1 solution ? Client is using phase 1 solution now. So any changes if they say we shd be in posn to incorporate not any phase 2 requirement. Please let me know how I go about this. I have an idea of maintaining two different solution in the VSS. But is that possible to have strong name and version it ? There are ASPX file also can I version it that also ?? Regards Srinath
-
Hi, Is that possible to version a solution ?? If yes please help me out. We have 2 phases in our web application project. Now the 1st phase is over. 2nd phase is coming now. Now, the question is how I maintain 1st phase changes in the solution. Can I version the phase 1 solution ? Client is using phase 1 solution now. So any changes if they say we shd be in posn to incorporate not any phase 2 requirement. Please let me know how I go about this. I have an idea of maintaining two different solution in the VSS. But is that possible to have strong name and version it ? There are ASPX file also can I version it that also ?? Regards Srinath
I'm not certain I'll have the exact answer you're looking for, but I'll mention a few things here (also not entirely certain I know what it is you are looking to achieve) ... If you're using VSS, lock your code down and branch the solution/project. You'll then have a version 1.x.x.x branch and a version 2.x.x.x branch; course, you have to name them yourself. In the application AssemblyInfo.cs file, you can specify the AssemblyVersion there. By default, it's specified as version ("1.0.*"), and the compiler automatically increments the minor build numbers. Once you've branched your code out, change that to ("2.0.*"); and so on ... Also, you can create an AssemblyKey file that's different for each release. This is also contained in the AssemblyInfo.cs file that's part of your main solution. Perhaps if you explained what it is you want to have happen, or not have happen, I could better point in the correct direction(?) ... maybe. Hope some of that information helped ... :confused: D.
-
I'm not certain I'll have the exact answer you're looking for, but I'll mention a few things here (also not entirely certain I know what it is you are looking to achieve) ... If you're using VSS, lock your code down and branch the solution/project. You'll then have a version 1.x.x.x branch and a version 2.x.x.x branch; course, you have to name them yourself. In the application AssemblyInfo.cs file, you can specify the AssemblyVersion there. By default, it's specified as version ("1.0.*"), and the compiler automatically increments the minor build numbers. Once you've branched your code out, change that to ("2.0.*"); and so on ... Also, you can create an AssemblyKey file that's different for each release. This is also contained in the AssemblyInfo.cs file that's part of your main solution. Perhaps if you explained what it is you want to have happen, or not have happen, I could better point in the correct direction(?) ... maybe. Hope some of that information helped ... :confused: D.
Why should he use a different key pair for each release? This, in effect, identifies you as the company. Maintaining version bindings between releases is done using the
<runtime>section of the .config file, or using a publisher policy assembly installed in the GAC. I mean, I agree with the rest of the stuff, I just don't get the latest direction. It's sort of like Authenticode; you buy an X.509 certification with the right extensions and sign your code with it. It identifies your company - much like assembly key pairs, except X.509 can be traced by easily to the source.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
I'm not certain I'll have the exact answer you're looking for, but I'll mention a few things here (also not entirely certain I know what it is you are looking to achieve) ... If you're using VSS, lock your code down and branch the solution/project. You'll then have a version 1.x.x.x branch and a version 2.x.x.x branch; course, you have to name them yourself. In the application AssemblyInfo.cs file, you can specify the AssemblyVersion there. By default, it's specified as version ("1.0.*"), and the compiler automatically increments the minor build numbers. Once you've branched your code out, change that to ("2.0.*"); and so on ... Also, you can create an AssemblyKey file that's different for each release. This is also contained in the AssemblyInfo.cs file that's part of your main solution. Perhaps if you explained what it is you want to have happen, or not have happen, I could better point in the correct direction(?) ... maybe. Hope some of that information helped ... :confused: D.
Douglas, Thanks for the solution. Let me explain you my requirement more elaborately. I have a solution which contains 4 projects. Now we need to freeze the current version(say i freeze to ver 1.0.0.1). There might be some requirement changes with respect to ver 1.0.0.1. Now there are set of new requirements coming up for the same solution. I dont want to touch prev version, I want to create a new version. Which can hold the new changes. So changes /bug fixes with respect to ver 1.0.0.1 should not tamper ver 1.0.0.2 (my second ver 2) Client shd be able to see changes w.r.t ver 1.0.0.1 after all they are god to us. :) hope you got my problem So please :) help me Regards Srinath
-
I'm not certain I'll have the exact answer you're looking for, but I'll mention a few things here (also not entirely certain I know what it is you are looking to achieve) ... If you're using VSS, lock your code down and branch the solution/project. You'll then have a version 1.x.x.x branch and a version 2.x.x.x branch; course, you have to name them yourself. In the application AssemblyInfo.cs file, you can specify the AssemblyVersion there. By default, it's specified as version ("1.0.*"), and the compiler automatically increments the minor build numbers. Once you've branched your code out, change that to ("2.0.*"); and so on ... Also, you can create an AssemblyKey file that's different for each release. This is also contained in the AssemblyInfo.cs file that's part of your main solution. Perhaps if you explained what it is you want to have happen, or not have happen, I could better point in the correct direction(?) ... maybe. Hope some of that information helped ... :confused: D.
Hi Douglas, Even if I version it, suppose I make changes in version 1, Can I replicate the same in version 2 during the release. Since version 1 goes for some changes I need to have those changes in version 2 only during the final release. hope you got it. hope I am not bugging you :) Regards Sri
-
Why should he use a different key pair for each release? This, in effect, identifies you as the company. Maintaining version bindings between releases is done using the
<runtime>section of the .config file, or using a publisher policy assembly installed in the GAC. I mean, I agree with the rest of the stuff, I just don't get the latest direction. It's sort of like Authenticode; you buy an X.509 certification with the right extensions and sign your code with it. It identifies your company - much like assembly key pairs, except X.509 can be traced by easily to the source.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Heath, Yes, this was my mistake and failure to properly explain Strong Name Key signing, thank you for pointing out this error. In hind sight, I'm not certain what I was trying to communicate regarding signing of his assembly ... it appears he's provided more information, so I'll have to review that before more information can be provided. Thanks again for pointing this out, D.
-
Hi Douglas, Even if I version it, suppose I make changes in version 1, Can I replicate the same in version 2 during the release. Since version 1 goes for some changes I need to have those changes in version 2 only during the final release. hope you got it. hope I am not bugging you :) Regards Sri
Sri, If I'm understanding you correctly, your concern is with having to maintain two different releases. Meaning, your client will have version 1.0.0 at their site while you're working on the next release 2.x.x ... during this time, the client could encounter bugs/design flaws, which you'll have to fix in their build and make a point release (1.0.1) and you want a way to replicate that 'fix' into your 2.x.x code ... There is a way to do this using VSS, however, it is often times more complex than just cutting and pasting your fixed code between the two releases. VSS provides a means to "share" branched code between releases. If the code segment is not different between your branches, then your "replicate my fix between versions 1.0.1 and 2.x.x" would work. HOWEVER, if you've modified that code segment already for your 2.x.x release, then that segment is no longer 'shared' and you would have to manually copy your fix between releases. You can find more information on this concept in the VSS help system (look at Shared code and Branching); you may have to read the help installed on the VSS server, since I believe branching is an VSS Admin function ... (you'll have to figure this out yourself). It is my personal opinion, however, that it is far easier, and a better practice, to make your fix in your version 1.0.x code base and then manually copy that fix over to your 2.x.x build. When you turn your code over to your QA group, they should regression test all those 1.0.x point release fixes you made, in the newer 2.x.x build, to ensure they are indeed fixed. Doing this, also helps ensure that (1) the bug was actually fixed as thought and (2) that newer code introduced in your new build has not directly affected your previous fix (not that this would ever happen ...) :rolleyes: That's my two cents, D.