none
To Share or Not To Share .NET DLLs RRS feed

  • Question

  • The Build Manager (Me) and an Architect Lead are going back and forth on how to implement his common DLLs.  Our current setup is 20+ individual .NET websites of which some are compiled and some are not (just the raw code out deployed).  This is just for one environment (QA) and one of our clients. So when he updates his DLLs he wants them deployed to each individual bin folder location, where I want the .NET web sites to reference one shared location and where the DLLs are deployed to instead of potentially hundreds of bin locations every time the DLL changes.  GAC is also out of the question.  What do you all think is the best way to go? Any other details about our setup let me know.
    Friday, November 6, 2015 6:19 PM

Answers

  • "where I want the .NET web sites to reference one shared location and where the DLLs are deployed to instead of potentially hundreds of bin locations every time the DLL changes.  GAC is also out of the question."

    Maybe you should ask this in the ASP.NET forums to see what other people that have ran into the same situation have done. AFAIK it's kind of complicated to convince ASP.NET to load dlls from places other than bin and GAC.

    Anyway, it's all a matter of trade offs. If each site has its own dlls then the overall memory usage will be higher because each site loads its own dll copies. That would suggest that using shared dlls would be a better choice but doing that may lead to another problem - you may need to restart all sites when the shared dlls are deployed. If each site has its own dlls then you can deploy one site at a time and perhaps you can even skip some sites - maybe you fixed a bug that affects only a small number of sites and there's no need to change all others sites.

    Personally I prefer the non shared dll variant, I think it's safer and more flexibile to have the entire contained in a single directory. IMO the shared dll variant should be used only if specific drawbacks are identified with the non shared approach - increased disk/memory usage, increased deployment times etc.

    Friday, November 6, 2015 7:13 PM
    Moderator

All replies

  • "where I want the .NET web sites to reference one shared location and where the DLLs are deployed to instead of potentially hundreds of bin locations every time the DLL changes.  GAC is also out of the question."

    Maybe you should ask this in the ASP.NET forums to see what other people that have ran into the same situation have done. AFAIK it's kind of complicated to convince ASP.NET to load dlls from places other than bin and GAC.

    Anyway, it's all a matter of trade offs. If each site has its own dlls then the overall memory usage will be higher because each site loads its own dll copies. That would suggest that using shared dlls would be a better choice but doing that may lead to another problem - you may need to restart all sites when the shared dlls are deployed. If each site has its own dlls then you can deploy one site at a time and perhaps you can even skip some sites - maybe you fixed a bug that affects only a small number of sites and there's no need to change all others sites.

    Personally I prefer the non shared dll variant, I think it's safer and more flexibile to have the entire contained in a single directory. IMO the shared dll variant should be used only if specific drawbacks are identified with the non shared approach - increased disk/memory usage, increased deployment times etc.

    Friday, November 6, 2015 7:13 PM
    Moderator
  • Thank you for you reply.  We've discussed some of the trade offs you mentioned.  Architect brought up it being more flexible as not all sites will need every change, but sometimes they all will.
    Friday, November 6, 2015 7:41 PM
  • I agree with Mike, we don't need to share dll to protect our project security as usual.

    Tuesday, November 10, 2015 5:30 AM