Hello,
We're starting new projects among several developers but want to create our common code in a separate DLL/Project that the other applications inherit. Take for example Software Update code, calling a web service for example. We want all of our main forms to inherit the MyCompany.BaseForm so it has the same underlying methods which can be changed in one place. However, we have multiple separate and unique applications being built.
How do I structure repositories, folders, etc. so that I can have multiple developers working on multiple applications that also access the base class in their .NET 2005 Solution? Think of a hub/spoke image, the hub being the base class and the spokes leading out to all the separate applications in development.
I'm looking for a SGV best practice, whitepaper, or any tips on how best to organize Vault to best handle this type of scenario.
Thank you.
Suggestions for organizing new .NET Solution...
Moderator: SourceGear
Tips
I can give you my 6 cents on this...
It seems as though you have a mini-framework - a set of reusable code that you want to leverage in multiple applications. I would assume that this is versioned separately from the applications it supports - i.e., your Expense Report app could be on version 1 of your framework (we'll just use that word for lack of a better term), whereas the Project Management app could be on version 1.3. In essense, you simply have another application. I don't think SourceGear has to care about how this "application" integrates with your others - that's a VS.NET problem.
So, I would structure my source control repository like:
/company/sourcecode
/framework
/trunk
/branches
/v1
/v2
/v3
/app1
/trunj
/branches
/v1
/v2
/v3
As far as Visual Studio, you have to think about how often developers who update projects will be changing the framework. The chances are pretty good you don't want someone writing an Expense app changing your framework code ad-hoc, even if you have continuous integration and unit testing (and there's a rosy place for you in development hell if you don't), b/c it could be difficult to manage those changes across apps (think about when you have 10 apps with 5 versions each). As such, you probably wouldn't want your Expense App solution to contain the Framework project - but rather the Framework binaries. Treat your framework as a separate deliverable, a separate project - if you can, even dedicate a developer or two just to maintaining THAT, so that the framework can evolve and have new features that your apps can consume. So you'll have to store your Framework binaries in source control under /trunk/bin, and vXXX/bin, which is fine.
Does this help?
It seems as though you have a mini-framework - a set of reusable code that you want to leverage in multiple applications. I would assume that this is versioned separately from the applications it supports - i.e., your Expense Report app could be on version 1 of your framework (we'll just use that word for lack of a better term), whereas the Project Management app could be on version 1.3. In essense, you simply have another application. I don't think SourceGear has to care about how this "application" integrates with your others - that's a VS.NET problem.
So, I would structure my source control repository like:
/company/sourcecode
/framework
/trunk
/branches
/v1
/v2
/v3
/app1
/trunj
/branches
/v1
/v2
/v3
As far as Visual Studio, you have to think about how often developers who update projects will be changing the framework. The chances are pretty good you don't want someone writing an Expense app changing your framework code ad-hoc, even if you have continuous integration and unit testing (and there's a rosy place for you in development hell if you don't), b/c it could be difficult to manage those changes across apps (think about when you have 10 apps with 5 versions each). As such, you probably wouldn't want your Expense App solution to contain the Framework project - but rather the Framework binaries. Treat your framework as a separate deliverable, a separate project - if you can, even dedicate a developer or two just to maintaining THAT, so that the framework can evolve and have new features that your apps can consume. So you'll have to store your Framework binaries in source control under /trunk/bin, and vXXX/bin, which is fine.
Does this help?