This project is read-only.


Slowing Builds In VS2010


I've been using the task under in my VS2008 .csproj file for my website for a while now with no problems. After upgrading the solution to VS2010 I've hit problems. Basically after the compressor task is first run then ALL subsequent builds of that project and others in the solution are slowed down. So I can build a normal C# project that doesn't call the task five minutes later and it will be slowed down because I've run the compressor rask. Maybe a leak of something is causing it?
More details can be found on my Stack Overflow post at

file attachments

Closed Jan 10, 2011 at 4:56 AM by purekrome


purekrome wrote Jun 7, 2010 at 12:58 AM

Hi MrKWatkins.

I've not replied to this for a while because

1) I was waiting for VS2010 to hit RTM (which it has a few weeks back, by now)
2) Test this under RTM version
3) See if anyone was having problems, to try and help resolve it.

So .. can u confirm if you have had any luck/no-luck with this issue, still?

MrKWatkins wrote Jun 7, 2010 at 8:49 AM

Yeah, still the same problem. We only upgraded to VS2010 once it had hit RTM so it wasn't an issue due to using a beta or anything like that.

wrote Oct 29, 2010 at 1:39 AM

mpjohnson wrote Oct 29, 2010 at 1:45 AM

I am experiencing the same issue. The second and subsequent builds of my ASP.NET application see the ResolveAssemblyReference task duration jump from about a second to about 20 seconds. When I remove the CompressorTask from my .csproj file. the issues goes away and all builds take seconds again.

Any progress on resolving this?

purekrome wrote Oct 29, 2010 at 4:15 AM

Any chance one of you guys could post a video screen-grab of this so I can see various things, like the content of your xml file, how u're doing the build, etc. etc. I can't promise that I can figure it out, but it could start to give me some suggestions to how I can try and setup a replication environment.

Alternatively, if it's possible to zip up a complete solution that replicates this issue - that could help too.

My first thought is that there's some attempt to find some file(s) and it's failing on finding them .. like it's trying to search some network drive? hmm....

mpjohnson wrote Oct 29, 2010 at 4:38 AM

I have also noticed that once the CompressorTask has executed it seems to effect that instance of VS2010 for any project or solution. If after running the CompressorTask as part of building a project, and I then close the solution and open another solution with no projects that use the CompressorTask they also build very slowly in a similar way. If I open a new instance of VS2010 the same project builds fine, consistantly.

wrote Oct 29, 2010 at 7:01 AM

mpjohnson wrote Oct 29, 2010 at 7:02 AM


As requested I have created a test solution with the issue and a video showing the problem. You will notice in the video that the solution also has a utilities project that I have removed (this is because I cannot distribute the code) so just add any of your own projects that are of a reasonable size to make the problem more obvious.

wrote Nov 8, 2010 at 2:21 AM

mpjohnson wrote Nov 8, 2010 at 2:21 AM

The issues seems to relate to the amount of time it takes to resolve references. If I build with the output set to diagnostic I can see that the task for resolving references is the one that causes the overall build time to increase.

I have recorded a new video where you can see that the 'TestProject' takes less than a 10th of a second to build each time until I build the project containing the Yahoo.Yui.Compressor, then the build times jumps to around 1.5 seconds.

I believe the reason why the problem is so exaggerated in the utilities project is because it has many references to other internal components that we have.

I have attached the new video and the exact solution from the video so you can clearly see the build time go from less than 10 milliseconds to over a second and a half. I have also included the full solution.

Please let me know if I can assist you further. I don't know if this is relevent but I am using Windows Server 2003 R2.

purekrome wrote Nov 8, 2010 at 3:18 AM

Thanks heaps MPJohnson. I can't look into it this week .. and maybe not next week either, cause i'm hellishly busy. But after that I should be ok to check it out. These vids do help, heaps.

mpjohnson wrote Jan 5, 2011 at 2:34 AM

purekrome. Please check this issue that I opened with Microsoft, they mention the root cause of the issue and how to fix it.

purekrome wrote Jan 5, 2011 at 5:32 AM

WHOA! Excellent work MJ! I can fix this and release a newer version with the fix. What I don't understand is how my (buggy) code that forces the Culture has any effect outside of the dll AND after the dll has been used? That part of the MS Connect explanation I didn't understand. But i do know how to fix it.

wrote Jan 5, 2011 at 5:35 AM

purekrome wrote Jan 6, 2011 at 12:50 AM

@mpjohnson : Can you please confirm what version of YUICompressor.NET you are using, where this issue exists? Why? I just checked the code (specifically, Line 115 and line 116 in file JavaScriptCompressor.cs and it looks like i'm resetting the current Thread's CurrentCulture back to the initial settings. Also, is the version the .NET 3.5 or .NET 2.0 download?

mpjohnson wrote Jan 6, 2011 at 1:31 AM

purekrome. The version we are using is (.NET 3.5). I've just tried downloading it to check it is the latest version and it seems to be the same, modified on 6/12/2009?

purekrome wrote Jan 6, 2011 at 3:04 AM

@mpjohnson - cheers mate :) sounds like that is the latest. kewl. When I get a new release out, I'll Private Message u a link so you can test it for me, please? (i can't replicate the issue here :( )

mpjohnson wrote Jan 6, 2011 at 4:52 AM

No problem, just let me know when it's ready to try out.

wrote Jan 10, 2011 at 4:56 AM

Resolved with changeset 61954.

purekrome wrote Sep 5, 2011 at 5:14 AM

MrKWatkins - I can't remember if i ever sent you a private message asking you to check if this issue has been fixed?

wrote Feb 22, 2013 at 12:55 AM

wrote May 16, 2013 at 12:20 PM

wrote Dec 8, 2017 at 5:08 PM