Take the 2-minute tour ×

I have been involved in a number of MVC.NET and c# desktop projects in our company over the last year or so while also managing to kept my nose poked into other projects (in a read-only learning capacity of course).

From this I've noticed that across the various projects and teams there is a-lot of functionality that has been well designed against good interfaces and abstractions. Because we tend to like our own work at times, I noticed a couple of projects had the exact same class, method copied into it as it had obviously worked on one and so was easily moved to a new project (probably by the same developer who originally wrote it)

I mentioned this fact in one of our programmer meetings we have occasionally and suggested we pull some of this functionality into a core company library that we can build up over time and use across multiple projects. Everyone agreed and I started looking into this possibility.

However, I've come across a stumbling block pretty early on. Our team primarily focuses on MVC at the moment and we have projects mainly in 2.0 but are starting to branch to 3.0. We also have a number of desktop applications that might benefit from some shared classes and basic helper methods.

Initially when creating this DLL I included some shared classes that could be used across any project type (Web, Client etc) but then I started looking at adding some shared modules that would be useful in our MVC applications only. However this meant I had to include a reference to some Microsoft Web DLL's in order to leverage some of the classes I was creating (at this stage MVC 2.0).

Now my issue is that we have a shared DLL that has references to web specific libraries that could also possibly be used in a client application. Not only that, our DLL referenced initially MVC 2.0 and we will eventually move onto MVC 3.0 for all projects. But alot of the classes in this library I expect to still be relevant to MVC 3 etc

Our code within this DLL is separated into it's own namespaces such as:

  • CompanyDLL.Primitives
  • CompanyDLL.Web.Mvc
  • CompanyDLL.Helpers etc etc

So, my questions are:

  1. Is it OK to do a shared library like this, or if we have web specific features in it should we create a separate web DLL only targeted at a specific framework or MVC version?
  2. If it's OK, what kind of issues might we face when using the library that references MVC 2 in a MVC 3 project for example. I would be thinking that we might run into some sort of compatibility issue, or even issues where the developers using the library doesn't realize they need MVC 2.0 libraries. They might only want to use some of the generic classes etc

The concept seemed like a good idea at the time, but I'm starting to think maybe it's not really a practical solution. But the number of times I've seen copied classes and methods across projects because they are proven tested code is a bit unnerving to be perfectly honest!

UPDATED: Further to Bernards answer which I have taken on board and seems good advice. However I want to create some shared classes that will probably be useful in both MVC 2 and MVC 3 projects. However my shared assembly will have to reference one of the MVC frameworks in order for me to create my shared classes in the first place.

So further to expand on my Q2 above.

  1. If I wanted a MVC 3 web solution would I have to have a shared CompanyDLL.Web.Mvc3 project that would then specifically be referencing MVC 3? Would that mean copying over all the code from my CompanyDLL.Web.Mvc2 solution to this new Mvc3 shared project?

It seems I'm missing some fundamental designing skills in the creation of shared assemblies and building and referencing against different framework versions. Or it might just be as simple as we suck it up and create a CompanyDLL.Web.Mvc2, CompanyDLL.Web.Mvc3, CompanyDLL.Web.Mvc4 etc etc libraries...

share|improve this question

1 Answer 1

up vote 5 down vote accepted

Create separate shared libraries for your different platforms (desktop and web). Whatever both of these libraries will need should go in a separate shared library. Thus, you could split these libraries up as follows:

  • Company.Core: Used by all libraries. Contains generic code, helper classes, etc. that are not specific to any platform. References no other shared libraries.
  • Company.Core.Desktop: Used by desktop applications. References Company.Core library.
  • Company.Core.Web: Used by web applications. References Company.Core library.

This allows you to change the web technology being used without affecting the desktop technology being used. This also allows you to add more platforms in the future (e.g. Company.Core.Mobile).

Ensure these libraries are unit tested and never again copy code between projects.

share|improve this answer
Thanks Bernard for the advice. What about issues with referencing different versions of Microsoft libraries in the shared DLLs? –  dreza Mar 26 '12 at 2:57
Do you mean different versions of the same libraries? MVC 2 vs. MVC 3? –  Bernard Mar 26 '12 at 3:30
Yes, this is exactly what we did in the same circumstance. Perfect. –  gahooa Mar 26 '12 at 3:31
@Bernard. Yes. I would expect our shared library to reference MVC 2. But what if a new project that uses this library wants to use MVC 3. I'm not even sure if that's a problem but something I don't know the effects of –  dreza Mar 26 '12 at 5:29
+1; I'd be pretty sure that unless you are using VERY specific features of MVC releases, they are designed to be forwards compatible for the most part. –  RichardW1001 Mar 26 '12 at 21:15

Your Answer


