show/hide this revision's text 2 italics - elaborated on the crux of my question

Background: This pertains specifically to building DLLs to extend AutoCAD. Every 3 years they change the binary compatibility, generally also changing the version of the .NET framework they compile it on. Sometimes they also change method signatures, DLL entry points and add/remove functions.

This means that I need to maintain different Project settings, references (Visual Studio project files), perhaps compiler preprocessor directives to build different versions of the same plugin from, essentially, the same code. As of now I need 3-6 different versions, depending on what methods I call. Generally 3 is enough. ... oh, and there's 64-bit in recent versions but that shouldn't be a problem if I build for "any cpu".

The core development process (Parent) would be against the latest version. When that is ready for a release I would build all the different versions for that release. All of the different versions would pull the code from the latest (core) version.

I will (probably) build each version on a specific machine with all of the versions on it. Just for kicks, I may also set up a separate VMs, specific to each version of AutoCAD for testing.

In either case, I would like to make this as easy as pulling the appropriate repo, building it, running the unit tests and trying it out in debug mode. If there is a problem in a specific release I may modify the code a little, perhaps with compiler directives and push that back to the core repo.

I saw this question but I'm note sure if it helps me since I have no intention of merging the separate branches / repos back together.

This question is probably the closest to answering my question but it also relates to ultimately merging everything back together of one build.

Question(s): What is the best way to maintain the specific-version build repos in sync, apart from the project configs, references etc. My initial thought was named branches but Kiln warns against those.

Is there a way to keep the repos in sync on the Kiln website or is it a better idea to simply pull-push the code locally at release-build time? -EDIT- Duh, the In / Out tab for the repo on the Kiln site..

I can see that maintaining the project file references is going to be the tricky bit. This is really the crux of my question. How to maintain the version-specific parts of the VS project file while incorporating code changes, adding, deleting files etc.

Any workflow suggestions for this are more than welcome.

show/hide this revision's text 1

Best practice to maintain different build configs for the same code

Background: This pertains specifically to building DLLs to extend AutoCAD. Every 3 years they change the binary compatibility, generally also changing the version of the .NET framework they compile it on. Sometimes they also change method signatures, DLL entry points and add/remove functions.

This means that I need to maintain different Project settings, references (Visual Studio project files), perhaps compiler preprocessor directives to build different versions of the same plugin from, essentially, the same code. As of now I need 3-6 different versions, depending on what methods I call. Generally 3 is enough. ... oh, and there's 64-bit in recent versions but that shouldn't be a problem if I build for "any cpu".

The core development process (Parent) would be against the latest version. When that is ready for a release I would build all the different versions for that release. All of the different versions would pull the code from the latest (core) version.

I will (probably) build each version on a specific machine with all of the versions on it. Just for kicks, I may also set up a separate VMs, specific to each version of AutoCAD for testing.

In either case, I would like to make this as easy as pulling the appropriate repo, building it, running the unit tests and trying it out in debug mode. If there is a problem in a specific release I may modify the code a little, perhaps with compiler directives and push that back to the core repo.

I saw this question but I'm note sure if it helps me since I have no intention of merging the separate branches / repos back together.

This question is probably the closest to answering my question but it also relates to ultimately merging everything back together of one build.

Question(s): What is the best way to maintain the specific-version build repos in sync, apart from the project configs, references etc. My initial thought was named branches but Kiln warns against those.

Is there a way to keep the repos in sync on the Kiln website or is it a better idea to simply pull-push the code locally at release-build time?

I can see that maintaining the project file references is going to be the tricky bit.

Any workflow suggestions for this are more than welcome.