How to deal with released shared libraries in .NET?

Question

This is the SVN structure:

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

ProjectA and ProjectB will supply the final product, and each of them can have its own release life cycle. Both projects use the same shared libraries from ProjectCore . ProjectCore will also have its own release life cycle. In ProjectA and ProjectB we want to reference the libs of ProjectCore . ProjectCore-libs were added to SVN after the successful ProjectCore release life cycle. ProjectCore-libs files are added to the References folder.

Having done this, we will release (freeze) our ProjectCore assemblies as a component that has been fully tested. So, we have several releases of Core-lib:

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

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

Approach 1

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

In the ProjectA and ProjectB solutions, we will add a link to this unique folder: ./trunk/Common/References/RLS_Core_X_XX .

Approach 2

Add ProjectCore -libs to SVN under the same References/Core folder. In case it had an "older" version, this will be a commit.

In the ProjectA and ProjectB solutions, we will add a link to: ./trunk/Common/References/Core . We use the external properties of SVN to determine which version of Core-lib should be used for ProjectA and ProjectB .

In both approaches, the developer clearly needs to decide which version of Core-libs he wants to use in his project. The rule supports the same Core-libs if you do not need to update due to lack of functionality. Approach 1 : Editing in a project solution. Approach 2 : edit external properties.

Which approach is preferable?

Answer 1

The first thing that seems natural is to use the recommended folder structure ( branches , tags , trunk ) for each project separately . This also applies to the overall project, especially if you have releases that are referenced by these two end products. Since these projects will be developed separately, you should be able to create separate tags and branches.

As soon as you do this (and since it is your requirement to include all references in the form of prefabricated assemblies), it would be nice to copy the released assemblies to each subfolder of Reference projects separately.

Thus, whenever you create a branch, you have an exact snapshot of the version you need, and it does not depend on the development of regular files.

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 

Answer 2

I like approach 1, as it should be faster and easy to switch between different versions

Answer 3

Both solutions are pretty much equal, so you need to consider deploying. Assuming version control is enabled on your .NET assemblies, you must free the correct libraries when you deploy the application.

So, I would make it explicit - solution 1 - referenced a directory with the version name lib in it and did not try to "reuse" the same link directory. Then you will find out which set of DLLs for delivery, and you will not be mistaken. (what could you do if you updated your project without the option to "Use external", some people do it. In .NET, if you accidentally rebuilt with the "wrong" DLL, you will fall into the world of adherents).

The disadvantage is that you will need to update the project links when updating, but this is not a big problem when searching and replacing inside project files.

Answer 4

As others have said, everything is exactly the same, and it needs to be well documented. But I would recommend placing ProjectCore releases not as a version with a subfolder in the trunk folder. Instead, I created branches for each version so that you get the following structure in ProjectCore:

 /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 contact ProjectA with ProjectCore using an external folder below ProjectA, which links to the specificC branch of ProjectCore, or if you change the link path in the .csproj file that goes beyond the ProjectA folder structure (one level above) so that the link is just a matter of taste .

I would depend on this answer about how well developers like the subversion external property function. If most of them do not know this or how exactly it works, this will confuse them and lead to errors. In this case, take a direct approach by placing the path in the .csproj file. If every developer knows and uses external elements, use this.