Source Code Control shared Libraries/Assemblies
-
I am working on a series of projects that will share several libraries/assembies. Some projects will be part of shared solutions, some will not. I am looking at the best way to setup my SCC server (TFS 2010). My current thought is have a shared Assemblies folder that each project has a branch of. The problem is after a while (months, years, ect.) that Assemblies folder will get pretty big, as well as contain several versions of DLLs. How do you guys go about doing this? I've seen suggestions to have each project have it own Assemblies folder, but I would really like SCC to have the Assemblies folder out of project level as well. Any ideas? P.S. Sorry if it doesn't make too much sense, I am over tired and took a sleeping pill for good measure.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
-
I am working on a series of projects that will share several libraries/assembies. Some projects will be part of shared solutions, some will not. I am looking at the best way to setup my SCC server (TFS 2010). My current thought is have a shared Assemblies folder that each project has a branch of. The problem is after a while (months, years, ect.) that Assemblies folder will get pretty big, as well as contain several versions of DLLs. How do you guys go about doing this? I've seen suggestions to have each project have it own Assemblies folder, but I would really like SCC to have the Assemblies folder out of project level as well. Any ideas? P.S. Sorry if it doesn't make too much sense, I am over tired and took a sleeping pill for good measure.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
I don't know anything about SCC, but it sounds dreadful. Are these third-party DLLs? If so, I agree with keeping them together.
-
I am working on a series of projects that will share several libraries/assembies. Some projects will be part of shared solutions, some will not. I am looking at the best way to setup my SCC server (TFS 2010). My current thought is have a shared Assemblies folder that each project has a branch of. The problem is after a while (months, years, ect.) that Assemblies folder will get pretty big, as well as contain several versions of DLLs. How do you guys go about doing this? I've seen suggestions to have each project have it own Assemblies folder, but I would really like SCC to have the Assemblies folder out of project level as well. Any ideas? P.S. Sorry if it doesn't make too much sense, I am over tired and took a sleeping pill for good measure.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
Have a separate project in source control that contains nothing but common dependencies, and include that in all the other projects (either by a direct reference mechanism if TFS supports that, or just by checking it out adjacent and referencing things by ../ paths).
-
I am working on a series of projects that will share several libraries/assembies. Some projects will be part of shared solutions, some will not. I am looking at the best way to setup my SCC server (TFS 2010). My current thought is have a shared Assemblies folder that each project has a branch of. The problem is after a while (months, years, ect.) that Assemblies folder will get pretty big, as well as contain several versions of DLLs. How do you guys go about doing this? I've seen suggestions to have each project have it own Assemblies folder, but I would really like SCC to have the Assemblies folder out of project level as well. Any ideas? P.S. Sorry if it doesn't make too much sense, I am over tired and took a sleeping pill for good measure.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
Expert Coming wrote:
Any ideas?
Depends on what you mean by "projects". I work on 'deliverables'. Each of those represents a discrete business grouping of functionality which can and does include groupings like the following 1. One or more dlls. 2. A single executable (console or windows service) 3. Several executables. When each is delivered it is labeled in source control (vendor does not matter), built from that label, and only that label, and then delivered as a single module/release. Each deliverable is independent from the others and the expectation is that each can have their own project timeline, etc. Since the deliveries are independent each deliverable MUST be contained within itself. That requirement means that if a single deliverable is using some sort of "shared" functionality (such as a library dll) that that shared functionality MUST be represented as its own deliverable. This is true whether I produce the shared code or if I am using a 3rd party library. That is the only way to insure that the code is written to match what it will be delivered with and tested against the same.