ASP.net应用程序组织问题
组织 ASP.NET Web 应用程序的首选方式是什么？我有两种选择：
拥有一个包含所有 dll 的 bin/ 目录和一个主 dll。在这种情况下，每次更改任何服务器代码时都需要重新构建。显然，可能有几个目录，但只有一个BIN
可以有多个 bin 目录（比如每个目录一个）。这里的优点是每个目录都是它自己的应用程序 - 但除此之外，它对我来说似乎相当混乱。
最好的选择是什么？如果我选择选项 1)，我可以让 Web.config 文件包含多个应用程序的设置吗？
What is the preferred way to organize your asp.net web application? Here are the two choice I have:
have one bin/ directory with all the dlls in it and one main dll. This case would require a rebuild each time any server code has been changed. Obviously, there may be several directories, but there is only one BIN
can have several bin directories (say one per each directory). The advantage here is that each directory is its own app - but other than that it seems pretty messy to me.
What is the best option? If I go with option 1) can I have Web.config file contain settings for several apps?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我从来没有使用过多个 bin 文件夹 - 不知道为什么你会想要这样做。 IIS 将加载它在其中找到的所有 dll，并且我从未遇到过任何性能问题 - 即使使用像共享点这样具有堆的东西。
拥有多个配置文件非常有用且有效。
HTH
干杯
Ive never had to use multiple bin folders - not sure why you would want to. IIS will load all the dll's it finds in there and Ive never had any perforamnce issues - even with things like sharepoint that has heaps.
Having multiple config files is quite useful and valid.
HTH
Cheers
您的网站最终应该有一个 bin 目录，但在具有多个项目的解决方案中通常有多个 bin 目录。
通过在您的网站中添加对其他项目的项目引用，或者通过构建后 dll 副本，所需的 dll 可以最终出现在您的网站 bin 中。
Your website should ultimately have one bin directory, but it is common to have multiple bin directories in a Solution with multiple projects.
By way of your website adding a project reference to the other projects, or by post build dll copies, the required dlls can end up in your website bin.
我要在 Jonesie 的答案中添加的唯一一件事是，如果您想维护某种模块化，那么创建不同的项目，以便您拥有单独的名称空间 - 从而拥有单独的目录。但请注意，这意味着您需要单独部署它们，除非您有某种构建自动化。
The only thing I would add to Jonesie's answer, is if you want to maintain some sort of modularity, then create different projects so that you have separate namespaces - thus separate directories. Beware though, this means you need to deploy them separately unless you have some sort of build automation in place.