Shared Library – Creating Shared Library for Desktop and Web Projects

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…