Hi,
If you distribute a .net web application, and you want a certain module of the application to be disabled, AND you don't want to ship the source with it, is it a reasonable solution to just not include the necessary .dll for that module?
I know you can do things programatically, but as long as you don't ship the .dll things should be ok right?
Reason being some .dll's require you to sell the product commercially, and if I want to give it away for free or as a demo I am stuck.
You have to go for plugin architecture. There's plenty of questions here on SO, as well as MEF which will be used in Visual Studio 2010, plus loads of DI/IoC containters which can aid in creating plugin-based apps.
You should be okay as long as the binary image you do ship doesn't actually need anything in the dll you're not shipping. That includes "does not expose functionality provided by the missing dll's".
For example; don't expose the "download as pdf" button if your pdf tools aren't "installed".
I've done this before by having a sort of plugin system that scans a predefined directory for .dlls and building a list of all exposed classes implementing a certain interface. Might be overkill for what you want though, and it's kindof the other way around than you suggest.
You definitely need some kind of 'in code' element, because a lack of DLL will break things in a worse way than simply disabling the modules you had intended.
This will definitely break if you are using Web Site instead of Web Application Project, because the DLL reference must be in your web.config... which will throw an error when it's missing.
You could get away with it in a Web Application Project, but that's a pretty ugly method. Much better to use some sort of plugin architecture, as others suggest.
One possible approach (assuming you don't want to or can't go the plugin route) would be to create a dummy DLL with all the same classes and methods in there but that actually doesn't do anything.
Depending on the size and complexity of your DLL this may or may not be a viable action.
The plugin route would be the way I'd approach it though, as whenever the "real" DLL changes you will need to update your dummy one.