Good Strategy for sharing project dependencies/resources across multiple projects/boxes/developers?

Question

Hi all,

I work in a small developing team with 3 developers and none of us are really 'uber elite programmers' but we get by pretty well for our company. One thing that has been constantly recurring is we keep using the same resources in multiple projects. One example being the fckeditor control, however it stinks to constantly add this folder to every project (I've got the control set-up in my toolbox, but it won't be able to find the code unless you have the folder in there). This also applies with constantly recurring master pages and controls.

Now we have made some steps for improving this, including making a 'back end' project where we put our shared functions, and made a CDN for images and scripts. But I still run into issues. For instance all developers must make sure they have the latest version of the back end project checked out, and built. Also when you add a reference to that .dll, the paths have to be the same between developers, otherwise it breaks the reference.

Now I just found out you can add a project reference, which will make the back end project build anytime I build the front-end project, but again you still have to make sure you have the latest version checked out. But I wonder what else I could do? Things I find annoying are making sure the relative locations of the back end project to the front end project has to be the same, and making sure they have the latest version of the back end checked out.

Are there better ways to do this? Also the back-end project is a class library, but how can I share resources like a user control? I tried putting a user control in a normal project, and then adding that project as a reference, but it doesn't give you access to the control in the file list like I am used to for dragging into a page.

Edit: Using VisualSVN 2.0 and Visual Studio 2010

Answer 1

AFAIK, User Controls cannot be shared between projects, as they contain HTML/ASPX which is bound to a particular web application. For this purpose, Custom Controls exist, because they can be compiled down to MSIL an used by any other .NET projects.

Same issue with Master Pages, however with MasterPages if you are seeing you have "common logic" used across all Web Applications, why not create a BaseMasterPage custom control (extending from MasterPage - no markup), and stick that in your custom control library as per above? Thing to remember is MSIL can be re-used, HTML/ASPX cannot.

Web Application frontend controls are not designed to be shared between different web applications.

Try and stick common functions, simple controls in class libraries and share that amongst your developers. Use a meaningful namespace as well (CompanyName.Common.Controls), this should help in avoiding those path conflicts.

As for "making sure developers have latest copy of build", well that's a given. I am unaware of a way to "automatically update the references" in everyone's solution.

Why not setup a small Windows tray icon applicatiojn which notifies when a check-in was made to that common project? Then the developers can grab the assembly.

We do this for build notifications (checkins, build success/fail, etc).

Answer 2

Caveat: From the perspective of one unfamiliar with asp.net and custom / user controls, as I am doing winforms development with out of the box .Net controls... Also, from a tortise and ankh SVN user rather than Visual SVN... The following works for code files; I'm not sure about how user controls work.

I put code for commonly used functions and libraries in seperate projects under thier own source control directories, as you mentioned above.

Then, for each new project, I add an svn external dependency for each library project I want to call. Using the svn:externals property, applied to the trunk directory of the front-end project, will cause the library project to be checked out / updated to its own subfolder whenever the front-end project is updated. Changes made to the library may also be commited when the project is committed.

Each line in the property allow you to load one library prokect. Lines look like:

I use tortise svn to edit the properties (details in tortise help); ankh SVN interprets then correctly. No experience with Visual SVN, you may be able to edit properties from Visual svn, or could use the svn command line.