We're developing a new project that is to be deployed on a large number of client sites. The project contains a web-based GUI as one of it's "access points". Speed of the web interface is a priority for this project, second only to security.

In the past, we've always created "web sites" in Visual Studio, which, when published, results in one dll and one aspx file for each page within the system. However, I am aware that you can actually create a "web application" and have it compile everything down to a single dll.

To me (based on no real data, just gut feeling), compiling the site as a single dll sounds like it would be better for both security and speed (if only marginally).

What are the considerations we should look at, and are there any obvious pitfalls we should be aware of when choosing the method that's right for us?


2 Answers 2


If it is a large application, there should be natural areas of division in your business logic (software tiers, if you will) which can go in their own DLL's.

It would be nice if the core website functionality could go into a single DLL. It eases deployment concerns, and is a natural unit anyway. One DLL per page seems excessively granular.

  • sorry - I should have mentioned in the question that the website is purely a presentation layer; All BL AND DL are held in separate assemblies, but your second-part is good reasoning :)
    – Sk93
    Commented Sep 21, 2010 at 8:11

apply the concept of "separation of concerns" if possible, meaning the businesslogic could be in dll, data access layer another and ui for another ...

this might come in handy if you happen to lose the source code ... when decompiling the dll might be easier.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.