1

I've been struggling to do this in a way that fulfills all of my requirements.

Here is what we have in our library:

  • Base classes for controllers and services
  • Business objects (stores, departments, etc)
  • Common Partial Views (Login, Error, etc)
  • Base class for HttpApplication
  • General common code (read an INI file, create a db conn, etc)

The one requirement that has been giving me trouble is as follows:

  • Lives in one place on a server. (i.e. copy local = false)

This breaks because:

  • The DLL containing the HttpApplication class must be in the same directory as the web apps dll to launch. I haven't found a way around that. I'm ok with duplicating this code in every app, but would rather not.
  • The shared views don't like to work if I use Assembly.LoadFrom() to load the dll from the shared location. (I've been using this method to precompile my views)
  • Any namespace shortcuts in web.config break at runtime with compilation errors because the web.config is parsed before the assembly is loaded.

My question to you folks is how do you handle your common code in a similar environment?

The GAC seems to be more trouble than its worth, and we want all of our apps to be using the same code, and not have multiple apps on multiple versions and have to maintain all of that. Are there design patters/best practices that can guide us in this regard?

Also, as a bonus, if you can solve any of the problems above, that would be great, too.

Thanks!

Edit: I guess a question that follows is whether or not we should even have a directory with the common dll(s) on the server, or if they should only be deployed as projects are deployed/updated?

IronicMuffin
  • 4,182
  • 12
  • 47
  • 90
  • 1
    Have a look here http://stackoverflow.com/questions/1235253/how-is-an-assembly-resolved-in-net. You can add your own stuff to find assemblies. Too much in one dll to my way of thinking as well.... – Tony Hopkinson Jan 16 '12 at 22:11
  • I'm going to put this as a comment rather than an answer because I don't really recommend it, but I _suppose_ (assuming you have the appropriate access on your server(s)) you could put junctions in your `bin` folder for the common DLLs out into one central place. Then you just drop the new DLL into the one central place all the junctions point to.. I'm not sure I like the idea of that at all, however. – rejj Jan 17 '12 at 14:37
  • That sounds rough, and junctions aren't necessarily used very often, right? Are you suggesting this to essentially trick .net into thinking the dlls are all in the same directory? – IronicMuffin Jan 17 '12 at 15:54

2 Answers2

1

Firstly, you will want to separate out what you're trying to achieve. Don't create 1 library that does everything or you will have a Big Ball of Mud. Don't be afraid to create several maintainable libraries to achieve what you're after. Is there a specific reason it needs to be stored in one location?

For example, several of the items you mention are MVC or web specific. If you have items that can be reused by MVC, create a class library that contains MVC base classes you inherit and reference them in your project. Use the single responsibility principle as much as possible.

Regarding the other items you mentioned, like database connectivity, if it's reusable, abstract it out in a data access class library and reference it. Other simple operations like reading an ini file or creating a file, create another library and abstract it to easy to use methods.

I prefer to copy the library dlls locally. You never know when you will need to make changes to the library, but you don't want all of your projects to stop compiling. When you're ready to implement a new version of the library, copy the dll in and recompile.

Bill Martin
  • 4,825
  • 9
  • 52
  • 86
  • The goal of one location was so that we could drop one file and everyone would get the update. I figured it was more of a DLL Hell when these 3 projects have one version, these 2 have the latest, and these 5 have an even older version, etc. – IronicMuffin Jan 17 '12 at 13:52
0

Not sure why all the hate towards the gac. It was designed to handle this specific problem. Install your common dlls to the gac and all apps can see them. Need to deploy a new one, just re-install it in one place.

Tiny Montgomery
  • 13
  • 5