How to deal with released common libs in .NET?

Question

This is the SVN structure:

/trunk
    + ProjectA
    + ProjectB
    + Common
        + ProjectCore
        + References

ProjectA and ProjectB will deliver an end product and each can have their own release life cycle. Both projects make use of the same common libs from ProjectCore. ProjectCore will also have its own release life cycle. In ProjectA and ProjectB we want to refer to the libs of ProjectCore. The ProjectCore-libs were added to SVN after succesful release life cycle of ProjectCore. The ProjectCore-libs are added to the References folder.

By doing this we release (freeze) our ProjectCore builds, as a component which was fully tested. So we have multiple Core-lib releases:

RLS_Core_1.00
RLS_Core_1.01
RLS_Core_2.00
RLS_Core_3.00

Since we add the released libs (dll's) to SVN, ProjectA and ProjectB can refer to them. What is the best approach to do this?

Approach 1

Add the ProjectCore-libs to SVN in a new folder under References named RLS_Core_X_XX.

In the solution of ProjectAand ProjectB we add a reference to this unique folder: ./trunk/Common/References/RLS_Core_X_XX.

Approach 2

Add the ProjectCore-libs to SVN under one and the same folder References/Core. In case there was an "older" version in it it will be a commit.

In the solution of ProjectAand ProjectB we add a reference to: ./trunk/Common/References/Core. We use the SVN externals properties to define which revision of the Core-libs must be used for ProjectA and ProjectB.

In both approaches the developer explicitely needs to decide what Core-libs release he wants to use in his project soution. The rule is keep the same Core-libs unless you have to upgrade because of missing functionality. Approach 1: edit in project solution. Approach 2: edit in externals properties.

What approach is preferred?

This certainly looks like a situation where a DVCS might be useful. — CodesInChaos, Feb 28 '12 at 11:17

vgru · Accepted Answer · 2012-02-29T10:35:31.837

1

First thing which would seem natural is to use the recommended folder structure (branches, tags, trunk) folder for each project separately. That goes for the common project too, especially if you are going to have releases referenced by those two end products. Since these projects are going to be developed separately, you should be able to create individual tags and branches.

Once you've done this, (and since it's your requirement to include all references as built assemblies) it would be a good idea be to copy released assemblies into each projects Reference subfolder separately.

This way, whenever you create a branch, you have the exact snapshot of the version you need, and it's independent from the common stuff development.

In other words:

/RepoRoot
    + ProjectA
        + branches
        + tags
            + v1.0
            + v1.1
        + trunk
            + references (includes 3rd-party and ProjectCore)
    + ProjectB
        + branches
        + tags
            + v0.8
            + v1.2
        + trunk
            + references
    + ProjectCore
        + branches
        + tags
            + v2.0
            + v2.1
        + trunk
            + references

edited Feb 29 '12 at 10:35

answered Feb 28 '12 at 10:51

vgru

49,838
16
120
201

I like the idea of a trunk/tags/branches for each project. Can someone summarize the pros and cons of this? This would help me in convincing my team members. I already found this [article](http://stackoverflow.com/questions/573695/folder-structure-for-many-projects-in-one-svn-repository) – Nick V Feb 28 '12 at 14:11
@NickV: I will update my answer later, I'm not near my computer right now. – vgru Feb 28 '12 at 14:45
This second [article](http://stackoverflow.com/questions/152328/how-do-you-structure-your-svn-repository) is in fact answering my question. – Nick V Feb 28 '12 at 15:25
Copying the released assemblies into each projects subfolder separately. SVN technically speaking, I expect an add for each project. Will the SVN server store these assemblies only once on the hard drive or for each add. – Nick V Feb 28 '12 at 16:06
@Nick: if you do a SVN copy command, then it's same as branching. Server knows that it's the same file rev. and only stores a reference. If you do a plain file copy + svn add, then you get a full copy. For example, with tortoise svn you would right-drag the file and select "SVN copy here" in the context menu. – vgru Feb 28 '12 at 20:40
A short summary. 1) ProjectCore assembly is build. 2) The assembly is added to svn (svn add cmd). 3) The added assembly is copied to all ProjectX/References folders (svn copy cmd). For step 2), the add, I propose to do this to a folder "assemblies" on the same level of the Projects. Just to have a placeholder, one and the same add-location. – Nick V Feb 29 '12 at 10:14
You can do that (step 2), but I don't think that's necessary. If a `ProjectCore` has a new release, put it inside its `tags`, that's where it belongs. And then put whatever assemblies you need into your `ProjectA` Reference folder (third-party or your own, doesn't make a difference). Hierarchically, release dlls don't seem to belong on this top level. But of course, there is also no reason why you shouldn't do it anyway (it's the matter of your in-house conventions). – vgru Feb 29 '12 at 10:31
(Also, I just realized this was downvoted. Would someone care to explain their problem with this answer?) – vgru Feb 29 '12 at 10:33
let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/8345/discussion-between-nick-v-and-groo) – Nick V Feb 29 '12 at 12:35

score 0 · Answer 2 · answered Feb 28 '12 at 10:48

0

I like Approach 1 as it should be faster and easy to switch between different version

answered Feb 28 '12 at 10:48

Simon Wang

2,843
1
16
32

score 0 · Answer 3 · answered Feb 28 '12 at 10:57

both solutions are pretty much equal, so you need to consider deployment now. Assuming you have versioning enabled on your .NET assemblies, you must release the correct libs when you deploy your app.

So, I would make it explicit - solution 1 - reference the directory with the lib version name in it, and don't try to 'reuse' the same references directory. Then you will know which set of dlls to deliver, and you won't get it wrong. (which you could do if you updated your project without the 'use externals' option, some people do this. In .NET if you accidentally rebuilt with the 'wrong' dlls, you'll end up in a world of reference hell).

The disadvantage is that you will need to update your project references when you update, but this isn't too much of a problem if you search+replace inside the project files.

score 0 · Answer 4 · answered Feb 28 '12 at 11:09

As the others already said it's all quite the same and it just has to be documented well. But i would recommend to put the releases of the ProjectCore not as a version named subfolder of the trunk folder. Instead i would create branches for each release so that you get under ProjectCore a structure like this:

/RepoRoot
   + ProjectCore
   + trunk
       + ProjectCore
   + branches
       + RLS_Core_1_00
       + RLS_Core_1_01
       + RLS_Core_2_00
   + ProjectA
       + trunk
           + ProjectA
       + branches
           + ProjectA_3_57
           + ProjectA_3_78

If you link within ProjectA to ProjectCore by using an external folder below ProjectA that links to a specifc branch of ProjectCore or if you change the reference path within the .csproj file going outside of the ProjectA folder structure (one level above) to link is just a matter of taste.

I would depend this answer on how well the developers are comfortable with the feature of the subversion external property. If most of them don't know this or how exactly it works it will confuse them and leads to errors. In this case take the direct approach by putting the path into .csproj file. If every developer knows and uses externals take this.

Just for clarity; the requirement is to link the Core-binary and not the Core-source (ProjectCore). This is not my requirement - personally I like source references more. — Nick V, Feb 28 '12 at 12:21
@NickV: In that case simply also add below your branches/RLS_Core_XXX/ also the bin/release folder, so that you have both sources and binary. In my eyes it's always important to also have access the the sources, in case of providing hotfixes. — Oliver, Feb 29 '12 at 09:07

How to deal with released common libs in .NET?

4 Answers4