>
Blog
Book
Portfolio
Search

2/25/2008

4060 Views // 0 Comments // Not Rated

Cassini Slow To Load ASP.NET 2.0 Web Application Assemblies

For the last few weeks, I've been plugging along at my client, working on a massive ASP.NET 2.0 web application that makes a massive usage of ASP.NET AJAX. I use (and reuse) the term massive purposefully: this app, as everyone agrees, should be a Win Forms deal. We have had to manage modal dialogs, Office-like functionality, lots of pages and user controls, script controls, web services, and about a dozen references.

What we do is set our solution to have multiple startup projects: first a web service that is our middle tier, then a web app (NOT a web site) that talks to the service. In my opinion, this is a lot for Cassini to handle, especially on the crap boxes that consultants always have to dev on.

The problem was that as requirements changed and scope creeped and milestones became merged together, our project grew and grew, which meant that it was taking longer and longer to build. Coffee breaks, as it stood, began by hitting F5. After a while, watching the output window during a build was almost humorous; SO MANY assemblies (.NET, third party, and cached ASP.NET pages from the magical Temporary ASP.NET Files folder alike) were being loaded, that it seemed as through we were recompiling Windows itself.

So we played with hosting things in IIS (5.1 on Windows XP). I ran into a lot of security problems and the like, but after some tinkering, was able to keep my builds reasonable as the project become more and more bloated. I hosted my web service in IIS, and launched my web app through Cassini, and got my builds down to only a few seconds.

Then, one fateful Thursday evening, the MIS department at my client pushed some updates to everyone's machines. Harmless, you say?

Well, the next day, I noticed that, although the builds were still smooth, it starting taking almost a minute before the home page would actually render in the browser. Visual Studio would save the build succeeded and popup a browser, which would sit there picking its nose while "Web site found. Waiting for a reply..."

But this time, a reboot and another coffee break did not fix things.

And when other people in my group began to have the same issue, we decided to take and hour and try to figure this out. It turns out that all the configuration stuff I mentioned at the beginning of this post was not the culprit. Although we are using VSS 6.0, which loves to mangle settings and config files, Visual Studio was fine.

So I turned my eyes toward Cassini. Watching the output window during a build, like I said, WebDev would load probably a hundred assemblies. IIS had started doing the same thing! It was as though I was always hitting a web app in IIS for the first time; nothing was being cached. Now I believe that Cassini goes away between builds, but something was still slowing this process down for IIS as well.

And what we discovered was two offending Windows Updates. Uninstalling them and rebooting seemed to solve the problem. These updates go after DirectX and Windows Media Player allowing remote code execution. What does this have to do with ASP.NET applications? Well, the only explicit correlation I've found is that we are using gradients in our markup, like this:

Code Listing 1

  1. /><td style="filter: progid:DXImageTransform.Microsoft.Gradient(endColorstr='#FFFFFF', startColorstr='#003366', gradientType='1';"> I am a gradient </td>

Since DXImageTransform is a call to DirectX, Update 941568 could have been somehow causing CAS or something else to be slowing down our assembly loading. I know it's half-baked, but that's what it looks like. So if you're having problems with Cassini slowly loading your ASP.NET 2.0 web application assemblies, consider these two links:

No Tags

No Files

No Thoughts

Your Thoughts?

You need to login with Twitter to share a Thought on this post.


Loading...