We recently moved to Visual Studio 2013 at work, which seemed like a wise choice as it has been in the wild since October of last year, has had some time to mature and comes with some interesting code editing and debugging features. Since we were upgrading development environments, why not upgrade the ASP.net web stack our core application, Quadra, runs on and the Entity Framework too! This meant the following:
- Upgrading MVC 3 to MVC 5
- Upgrading WebPages 1 to WebPages 3
- Upgrading Razor 1 to Razor 3
- Upgrading Entity Framework 4 to Entity Framework 6
- Upgrading .NET 4.0 to .NET 4.5
- Upgrading from MiniProfiler to Glimpse
The astute reader will glean that we missed an update to the web stack, this was by design as when the MVC 4 upgrade was going to take place we didn't have the requisite runtime on the server and then a whole host of new development projects got in the way. So yeah, updating the development environment and moving ahead two versions in the ASP.net web stack, what could go wrong? Not much, except crippling performance issues and a quest to resolve them, let the slow crawl begin!
 |
| Waiting for page loads was like watching this turtle video, wait is that a video or a still, I don't know! |
Oddly the upgrade process was not painful at all, I opted to move ahead one version at a time, due in no small part to this great MVC3 to MVC4 NuGet package:
Once that was installed it was simply a matter of following the steps outlined in this article: How to Upgrade an ASP.NET MVC 4 and Web API Project to ASP.NET MVC 5 and Web API 2 . With a bunch of version number find and replacing, referencing latest NuGet Packages, and fixing up the Web.config after said NuGet pacakges mangled it we were good to go. And go we did, very slowly.
When I say slow, I mean painfully slow, pages would take 120 seconds to load the first time and then 20 seconds to load subsequent times. Oddly, this was fairly consistent regardless of Debug or Release compilation. Obviously it is impossible to work with that kind of lag so I headed to the internet and found a whole host of reported MVC 5 and or Visual Studio 2013 performances issues and their resolutions.
First I went down the Visual Studio 2013 road and tried these:
BrowserLink
Turn off the BrowserLink feature. This feature is cool for cross browser testing, enabling refreshing browser clients from the IDE, but it adds a ton of overhead and bloat. More on this feature here http://blogs.msdn.com/b/webdev/archive/2013/06/28/browser-link-feature-in-visual-studio-preview-2013.aspx
Visual Experience
The default setup of the visual experience is reported to have a pretty hefty performance overhead, though likely not an issue on my i7 laptop with 16 GB ram and a 2GB video card, regardless to disable this I performed the following:
- Open up Tools > Options
- Navigate to the Environment > General tab
- Uncheck all of the following:
- Automatically adjust visual experience based on client performance
- Enable rich client visual experience
- Use hardware graphics acceleration if available
Microsoft’s Git Provider
Since I’m used to GitExtensions and haven’t used an “in the IDE” source control for years now, the newly available Microsoft Git integration was not really necessary. Also, I read that it isn’t the fastest thing around and could cause a slowdown. To disable:
- Open Tools > Options
- Navigate to Source Control > Plug-in Selection
- Chose the None option from the drop down list
All that work, all those possible fixes, and still excessively slow loads. The next avenue to explore was MVC 5 itself.
RazorViewEngine Exclusively
This cam from Stack Overflow and improves performance by making sure two view engines aren't looking for views, we only use Razor, sorry WebForms. This can be accomplished by adding statements shown in the screenshot below.
You guessed it, still slow. At this point I may or may have not been deliriously scrambling to find a solution, when hacking apart a view I noticed that without any DevExpress controls, which we rely on heavily, the page came back lightning fast. Wait, what?
DevExpress Update for MVC 5!!11!!1
Yes, it wasn't Visual Studio 2013 or even MVC 5, it was our 3rd party controls and how they reacted to the new MVC 5 security policy that caused the ultra performance hit! DevExpress released an update for this sometime ago, which we were already using, however we were using the WRONG VERSION of their MVC dll. They released an MVC 5 specific version to address the security issue fully explained here that required replacing DevExpress.Web.Mvc.v13.2.dll with DevExpress.Web.Mvc5.v13.2.dll.
However, just updating the dll didn't fix everything. The other aspect was redeploying MVC theme files and choosing MVC Version 5 to assure the theme files referenced the correct dll:
That's it for this epic odyssey of MVC 5 and Visual Studio 2013 performance and my casting about attempting to find a resolution. Let this be a lesson to you all: blame 3rd party controls first! I hope this information helps someone, somewhere out there on the interwebs. I'm sure the blow would have been softened by upgrading one item at a time, but heck, where is the fun in that! :-)