ASP.NET项目中有多少个"页面"，是否存在任何已知问题？

由项目创建的DLL的大小根本不重要吗？

我现有的项目大约有150页，并且DLL大约只有3MB，但是最近从50页和0.5 MB增加到了

解决方案

对于大小不超过数百页的网站，我没有遇到任何问题。我们在谈论一个多大的网站？页面之间是否存在内置冗余，可以通过使单个页面带有参数来解决？

通常，将较大的站点或者项目的子部分分成多个ASP.NET Web项目通常是有意义的。这使站点方式更加模块化。此外，如果我们有在整个站点中使用的通用控件，而这通常是导致仅包含那些控件的项目的原因。

但是，为了直接解决这个问题，我管理的项目有很多页面，而且没有问题……除了它成为浏览器的"乐趣"并针对它进行开发之外。

从技术上讲，我们可以在一个Web应用程序项目中弄乱(我想说成千上万个)"页面"。

不过，拉塞尔所说的将其分解为模块，可能会使其更易于维护。

有限制吗？否。我们应该组织项目以便于管理吗？是的。

除非我们尝试对其进行调试(或者关闭批处理编译)，否则无需担心。或者，如果我们有一堆文件夹。启用了批处理功能的情况下，每个文件夹将为所有文件提供一个DLL。因此，如果将事情分解成一堆文件夹，可能会导致进程内存碎片化问题。否则，很多页面都不会出现问题。

斯科特·汉塞尔曼(Scott Hanselman)在两年前开始讨论这个话题。

绝对限制是系统内存。项目越大，将使用的内存越多。

当然，我们可以在解决方案中留在[50-200]项目中。

如果我们发现Visual Studio占用的内存比预期的多，那就开始考虑将项目分解。

我认为最好的办法是使项目规模成为设计要求。

编辑：我不是真的回答你的问题。弄清楚。 VS2003，VS2005或者VS2008解决方案中包含的元素(页面，项目，图像，引用等)越多，Visual Studio占用的内存就越多。