We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now

x

Visual Studio Design

Medium Priority
394 Views
Last Modified: 2013-11-26
Hey guys,
  It seems like my Visual Studio if running slooooowww... when I work from the "SDesign Page."

Source view is normal.

Did I change something?
Comment
Watch Question

That could be Anything.

Found this forum post with a lot of people having the same issues though, there are a few tips on there:

http://forums.asp.net/t/1248738.aspx
CERTIFIED EXPERT
Commented:
I believe restricting the compilation to ONLY affected projects will definitely 'speed-up' the overall compilation, a lot.
Are you using VS 2005 IDE? In VS 2005, if you go to 'property page' for the solution., you can do this by following 2 options(or combination of both)-
1.) in 'common properties' tree node of solution property page, click on 'Project dependencies' node, In the right pane, you can 'select' the projects that you think require to be rebuilt for the changes you made in your project x. If you feel project Y and Z don't require to be rebuilt even if they are dependency projects, you can 'uncheck' them. Unchecked projects would be ignored during compilation.

2.)In 'configuration properties' tree node of property page, click on the 'configuration' node. In the right pane, you can deselect the projects that are not required to be compiled. All the unchecked projects willl be ignored during compilation.

Make sure though, that next time you make changes in projects Y or Z, you check these projects or else changes won't be compiled and possibly would make you split
-----
Slow compilation of large ASP.NET sites on IIS
Let me start by saying this is not about slow compilation in VS 2005. If you are experienceing slow performance in Visual Studio, then look here.

Background

Our CMS utilises ASP.NET to render the live site that the end users see. The CMS basically publishes an ASP.NET site as if you hand wrote it yourself. The management classes and ASPX pages behind this are pre-compiled and the pre-compiled configuration file is set to allow updates i.e.:

<precompiledApp version="2" updatable="true"/>This allows us to have a nice strong pre-compiled set of management classes etc whilst allowing the publication system to send new ASPX files to the live site at any time.

This means that there are heaps of ASPX files on the site possibly needing to be compiled at any given time (on some of our larger client sites there could be 20,000 ASPX files).

Problem

Normally you would expect that a new page would be compiled on the first visit and then run fast and efficient for subsequent hits& however a few months ago (June maybe) Microsoft released a patch which caused a few headaches to a large non-pre-compiled site.

Our clients started ringing up complaining about slow downs after publication (i.e. a page had to be re-compiled by ASP.NET). Some of the slow downs were 15 or more minutes! The CPU and memory would max out even quite high spec machines - and the site would become totally unresponsive.

After some head scratching and remote access to the client networks (we couldnt replicate the problem in our environment) and lots of file monitoring, run-time monitoring etc. I finally realised that ASP.NET was re-compiling every page in the site (including a special cache we keep for system purposes). Naturally on a large site this was taking forever. Further research on our part tracked the problem back to the KB article http://go.microsoft.com/fwlink/?LinkId=91233. Being a security update, some of our clients installed it straight away - against our general advice (i.e install to staging environment first :)).

The solution is however quite simple:

<configuration>
    <system.web>
        <compilation debug="false" batch="false" numRecompilesBeforeAppRestart="50"></compilation>
    </system.web>
 </configuration>Update your web.config file and add in the attribute batch=false to the compilation line. The problem was that the framework patch had turned on batch compilation mode by default - causing obvious compilation delays (well this is what we assume has happened - information was a little scarce about the problem, most sites are not as dynamic as an Objectify live site). With this setting, affected machines now compile only one page at once. Click here for more information.

You will also notice another setting here - numRecompilesBeforeAppRestart. Normally ASP.NET will cycle the worker process after 15 dynamic compiles. You can extend this out depending on your needs.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.