Moving towards the efficient development of smart software solutions
That’s what happens to the Resharper 4.0, if you open 14MB flat XML file in Visual Studio 2008.
Note, that after closing this file and running GC, memory consumption drops to a mere 880 MB. This feels like a tiny memory leak, does not it?
And that’s one more reason to switch to 64 bit OS - you can add enough RAM to keep R# happy.
If something has gone wrong, and it is really tough to figure out the reason, try looking at the situation from the different angle. Could it be, that there are two separate and simple problems that play well together in distorting the symptoms?
This has been the case with the Web Deployment Projects failing spontaneously on the CC.NET. Deployment projects do really fail under VS 2008 under some weird circumstances (that’s the first problem), but the real cause was simple build timeout on the integration server (second problem).
And I’ve got way too carried away by the complexity of the first problem (and ease of reproducing it locally) and didn’t even check server log (CC.NET separates build logs from the server log, which holds higher-level messages) for some other hints (i.e.: “Process timed out:…”)
That was a good lesson.
Now I’m getting to love VS 2008 and deployment projects.
Web Deployment Project always fails the build, when being executed from VS 2008 (and sporadically on the CC.NET), but, at the same time:
How am I supposed to fix the thing if it does not tell me what’s going wrong?
Updates (as I’ve been looking for the problem):
Resume: according to the rule of thumb below, it is not efficient to continue looking for the solution to this specific problem.
If you spend more than a couple of hours trying to fix some mysterious framework/IDE problem without any luck, then probably this problem is not worth fixing. It would either be fixed by some hotfix/SP or the home-made fix would be quite complicated/fragile (adding more maintenance problems than it resolves). Let it go, step back and look for the workaround.
Here’s one more way to edit project files in Visual Studio (kudos to Jeremy Gray):
Microsoft Visual Studio 2008 Power Commands have “Edit Project File”:
This command opens the MSBuild project file for a selected project inside Visual Studio. It combines the existing Unload Project and Edit Project commands.
As you know, normally Visual Studio 2008 does not let you open *.csproj files from the current solution in the editor (for example, when you want to tweak the build process to compile these custom DSL scripts of yours). I used to resort to starting second instance of VS just for the XML editing with the IntelliSense.
However, as it turns out, there is another approach:
R# 4.0 EAP is the best thing that we can have right now, but you’ve got to be really careful about it. Especially, if you have habit of keeping your Visual Studio instances running for days, like I do.
Just today my R# finally ate all free space on his hard drive with logs (7 GBs) then threw an exception in all 3 VS 2008 instances. As if it was not enough, all VS instances crashed after that.
Latest Comments