在同一服务器上的多个 Web 应用程序之间共享 bin 文件夹和 dll 以及其他资源文件（如 css）的最佳实践是什么？
我已经将通用代码分离到它们自己的程序集中，但我想知道部署等。我基本上希望将所有通用文件位于网络服务器上的一个位置，然后让每个网络应用程序引用该通用文件地点。
目前我不确定如何告诉 Asp.net 网站使用不同位置的 bin 文件夹。
如果有什么区别的话，那就是这些都是 ASP.NET MVC 应用程序。
谢谢你的帮助。
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.
发布评论
评论（3）
mklink - http://technet.microsoft.com/ en-us/library/cc753194%28WS.10%29.aspx
另外，请参阅 ServerFault 上的此问题 - https://serverfault.com/questions/7109/how-do-i-create-a-symbolic-link-in-windows
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
最佳实践建议您不要这样做。
每个应用程序都是不同的，请分别对待。 通过共享资源，您可以在项目之间创建隐式依赖关系 - 如果您更改共享资源，您就会更改所有项目 - 无论是有意还是无意。
如果您确实必须共享资源，请在源代码控制或构建级别执行此操作 - 在该级别打破依赖关系比将其部署到生产服务器上后打破依赖关系要容易得多。
Xanadont，共享公共库等很好（这本质上就是像 nHibernate 这样的开源项目所做的），但是在生产服务器上的 bin 共享文件夹级别上这样做会产生比它解决的问题更多的问题。 您所讨论的重用类型最好通过创建共享库来实现，这些共享库是源代码管理中的独立项目，并在某处维护二进制版本。 然后，希望使用共享库的项目通过将二进制文件复制到解决方案源树的 lib 文件夹并引用该二进制文件来对共享库建立二进制依赖。 这允许维护和更新共享库，而不会由于直接依赖于它们而导致副作用，并且使用这些库的解决方案可以评估修复/更新，以确定它们将如何影响依赖于它们的代码以及是否升级是值得的。
Scott，您指的是1 个在视图层有变化的应用程序（模板），不是 50 个在业务逻辑中有变化的应用程序< /em>。 这种应用程序的最佳方法是多租户（因为我假设每个城市也有 1 个数据库）并使用 url 定义一个上下文，您可以在其中访问数据库并解析视图路径（很难描述）一种更好的方法，但无需更好地了解您的应用程序架构）。
根据 url 更改视图可以通过实现上下文感知视图引擎来完成（请参阅 http://www.coderjournal.com/2009/05/creating-your-first-mvc-viewengine/ 有关如何执行此操作的示例
，您可以使用这种方法 。您只需更新 1 个位置并进行修复，但您只需添加一组新模板并（取决于您设置路由的方式）将新域指向您的站点，即可轻松为另一个城市创建新的“站点”如果您有一组默认模板，如果自定义不存在，您的视图引擎甚至可以回退到这些模板，因此允许您只需将新域指向您的应用程序即可设置新站点。
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.
我使用以下技术：
我有多个带有 ascx 控件、资源等的 ASP.net 应用程序项目...我已经实现了虚拟路径提供程序来解析这些应用程序之间的虚拟路径。 它运作得很好。 我还实现了特殊的 http 处理程序来使文件可下载。 如果您需要示例，请查看 liveui 源代码。
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.