If you are like me and you have a similar problem of having to share common in-house library code between various Visual studio solutions and you are using SVN for your source code control, then SVN Externals might be a good option to consider.
In my scenario, I had a class library which contains a lot of utility classes that are shared amongst different applications I write. Before starting a new project, I would typically create a Solution Items / bin folder in the solution directory of the new project and would place the compiled library dll in this folder which gets checked into SVN repo along with the application code. This approach sort of worked but had the following pain points:
- Before starting a new project, I had to get the latest version of the library code from the repo. Compile it and grab the dll and place it in the solution items folder of the new project.
- When I added more functionality to the library code, the existing solutions could not benefit from it.
- I could not debug the library code from within the application solution, unless i used Reflector Pro to decompile the library.
Found out about the SVN externals options and it has helped me great deal in addressing all the above issues, so I thought it might be worthwhile sharing.
Lets say you have a very simple library solution as follows:
and it is checked into a SV repo as follows:
AppOne and AppTwo folders have 2 different applications that need to share the Utility class in the MyLibrary solution. Both these applications are already checked into the repo in their respective folders.
To add The library code as an external link to AppOne, I had to right click on the AppOne folder, choose properties and the following:
To add the library project link, I had to:
and the Working copy Subverion properties window looks as follows:
Now all that is left to do is right click on AppOne working copy folder and choose SVN update and the Library code would be checked out into AppOne working directory.
One of the last things to do is to open the AppOne solution in Visual studio and add the library project by choosing the Add Existing Project option and checking the entire solution back again.
After the solution is checked in this is how the repo browser looked like. It clearly shows MyLibrary.Common with a shortcut icon.
The beauty of this approach is that as soon as I make some changes to the library solution, it is immediately reflected in AppOne when I update my working copy.
This is how AppOne solution looks like.
and any changes made to the Library code from within AppOne would reflect in the Library solution as well.