What's the best practice to share the bin folder and dlls and other resource files (like css) between multiple web applications on the same server?
I've already separated out the common code into their own assemblies, but I'm wondering about deployment, etc. I basically want to have all the common files located in ONE location on the webserver, and then have each web app reference that common location.
Currently I'm not sure how to tell an Asp.net website to use the bin folder from a different location.
If it makes any difference, these are ASP.NET MVC applications.
Thanks for you help.
mklink - http://technet.microsoft.com/en-us/library/cc753194%28WS.10%29.aspx
Also, see this question over at ServerFault - https://serverfault.com/questions/7109/how-do-i-create-a-symbolic-link-in-windows
Best practice would suggest you don't.
Each application is different, treat them as such. By sharing resources you create an implicit dependency between the projects - if you change a shared resource you are changing it for all - whether it was intended or not.
If you really must share resources, do it at the level of source control or builds - it is far easier to break the dependency at that level than it is to break the dependency once you have it deployed on a production server.
Xanadont, sharing common libraries etc is fine ( this is essentially what open source projects like nHibernate do ), but doing this at the level of bin sharing folders on a production server creates more problems than it solves. The kind of re-use you are talking about is best approached by creating shared libraries that are independent projects within source control with binary versions maintained somewhere. Projects wishing to use the shared libraries then take a binary dependency on the shared library by copying the binary into the lib folder of the solutions source tree and referencing that binary. This allows the shared libraries to be maintained and updated without causing side-effects due to direct dependencies on them, and solutions that use the libraries can evaluate the fixes / updates to determine how they will impact the code that depends on them and if the upgrade is worthwhile.
Scott, what you are referring to is 1 application with variations in the view layer (templates), not 50 applications with variations in the business logic. The best approach for this kind of application is multi-tenanting ( as I assume you have 1 database per city as well ) and use the url to define a context from within which you can access your database and resolve your view paths ( hard to describe a better approach without understanding your application architecture better ).
Changing views based on the url could be done by implementing a context aware view engine ( see http://www.coderjournal.com/2009/05/creating-your-first-mvc-viewengine/ for an example of how to do this.
With this kind of approach, you have only 1 location that you need to update with fixes, yet you can easily create a new "site" for another city just by adding a new set of templates and ( depending on how you set the routing up ) pointing the new domain at your site. If you have a set of default templates, your view engine could even fall back to these if customisations do not exist, therefore allowing you to set up a new site just by pointing a new domain at your application.
I use the following technique: I have multiple ASP.net application projects with ascx controls, resources and so on...I've implemented virtual path provider to resolve virtual paths between these applications. It works very well. I've also implemented special http handler to make files downloadable. If you need samples, look at liveui source code.
来源：https://stackoverflow.com/questions/1151453/shared-code-between-multiple-asp-net-projects