网站项目发布期间 Visual Studio 2010 内存使用情况

发布于 2024-09-26 15:23:05 字数 1560 浏览 0 评论 0原文

我有一个 Asp.Net 网站项目,该项目在发布过程中导致越来越令人沮丧的内存问题。 Visual Studio 在正常工作期间运行得相当好,甚至构建阶段也相当快(特别是在遵循下面列出的帖子中的一些建议之后)。然而,发布阶段很慢,更重要的是,导致 Visual Studio 消耗其定期消耗的内存的 400% 到 500%(在任务管理器中从大约 500 Mb 到大约 2.25 Gb)。此外,在 Visual Studio 中显示“发布成功”消息后,内存消耗的增加会持续几分钟(在某些情况下为 5 或 10 分钟)。事实上,这确实是问题所在 - 我不介意在发布活动期间不做太多事情,但一旦完成,我想立即回去工作,但内存过载意味着我的整个系统对看起来很漫长的事情没有响应VS 似乎完成了它的工作之后的时间。

该解决方案的结构如下:

Solution
   |
   -Web Site Project
   |
   - Data Access Layer Project
   |
   - Data Access Layer Tests

DAL 和一些背后的代码都依赖于外部库来访问 ERP 系统,但我非常小心地将它们保持在同一版本上(事实上,我必须- 如果版本不同,网站上的某些页面会损坏)。我还有其他几个小型帮助程序库,我也非常小心 - 在这两个项目中,它们都是从共享文件夹引用的。我不认为我正在遭受“决斗程序集引用"

该网站设置为“允许此预编译网站可更新”标志并打开“使用固定命名和单页程序集”标志。

整个解决方案从当前的实施例开始,作为 VS 2005/Asp .Net 2.0 站点。我们跳过了 2008 年,现在在 VS 2010/Asp .Net 3.5 下运行它。我所看到的问题或多或少地发生在 VS2005 下,并且肯定是跟着我从我的旧机器(有点动力不足)到这台看起来相当最新的机器。

我构建的机器是具有 8 Gb 内存的 Win7 64 位机器。我在 VS 中运行一些插件/扩展(特别是 Telerik 的 JustMock 和 DevExpress 的 CodeRush/RefactorPro)。

我仔细阅读了 SO 上其他几个与内存/性能相关的线程(包括 这个这个)并遵循我认为相关的建议。

还有其他人见过这种情况,或者有任何指示我可以采取什么措施来缓解这种情况吗?

编辑

FWIW,我将其发布到本地计算机上的文件夹中,所以我认为该问题与网络延迟没有任何关系......

I've got an Asp.Net web site project that is causing increasingly frustrating memory issues during publish. Visual Studio operates reasonably well during normal work, and even the build stage is fairly quick (especially after following some of the recommendations in the posts listed below). However the publish stage is slow, and more to the point causes Visual Studio to consume between 400% and 500% of the memory it consumes on a regular basis (from around 500 Mb to about 2.25 Gb in Task Manager). Furthermore, the increased memory consumption continues for several minutes (5 or 10, in some cases) after the Publish Succeeded message appears in Visual Studio. In fact, that's really the problem - I don't mind not doing much during a publish activity, but once that's done I want to get right back to work, but the memory overload means my whole system is unresponsive for what seems like a looong time after VS seems to be done its work.

The structure of the solution is as follows:

Solution
   |
   -Web Site Project
   |
   - Data Access Layer Project
   |
   - Data Access Layer Tests

Both the DAL and some of the code behind rely on an external library for ERP system access, but I'm pretty careful about keeping them both on the same version (in fact, I have to be - some pages on the site break if the versions aren't the same). I have a couple of other small helper libraries that I'm also pretty careful about - in both projects they're all referenced from a shared folder. I don't think I'm suffering from "Dueling Assembly References"

The web site is set up with the "Allow this precompiled site to be updateable" flag on and the "Use fixed naming and single page assemblies" flag on.

The over all solution started in it's current embodiment as a VS 2005/Asp .Net 2.0 site. We skipped 2008 and are now running it under VS 2010/Asp .Net 3.5. The problems I'm seeing occurred to a greater or lesser degree under VS2005, and definitely followed me from my old machine (which was somewhat underpowered) to this, seemingly pretty up-to-date, one.

The machine I am building from is a Win7 64-bit machine with 8 Gb memory. I am running a few AddIns/Extensions in VS (notably Telerik's JustMock and DevExpress's CodeRush/RefactorPro).

I have perused several other general memory/performance related threads on SO (including this one and this one) and followed the recommendations I believed to be relevant.

Anyone else ever seen this, or have any pointers to what I might be able to do to alleviate it?

EDIT

FWIW, I am publishing this to a folder on my local machine, so I don't think the issue has anything to do with network latency...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

遥远的绿洲 2024-10-03 15:23:05

现在回到这一点。我已经离开这个职位,并且在新职位中没有遇到同样的问题,但是在我的新职位中制定“构建解决方案需要 forEVAR”问题为我指明了确保我的断点保持在合理的水平 - 我经历了很长的构建时间,但是在删除所有断点(其中大部分未使用)后,构建时间缩短了十倍。

我很可能在这个问题中提到的项目中遇到了同样的问题,所以也许这会对遇到这个问题的人有所帮助。

Circling back around to this now. I've moved on from this position and don't have the same problem in my new position, but working out a "building solution takes forEVAR" issue in my new position pointed me down the road of making sure that my breakpoints are kept at a reasonable level - I was experiencing very long build times, but after deleting all breakpoints (most of which weren't being used) the build times improved by a factor of ten.

It's very possible I was suffering form the same issue on the project mentioned in this question, so perhaps that'll help someone who's having this problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文