Why do script blocks grow endlessly in VS2010 Debugger when running ASP.Net page with partial postbacks?

On an ASP.Net page that uses an UpdatePanel containing various validated controls for partial postbacks, the Visual Studio 2010 script debugger window starts to show an ever growing list of “Script Block” entries which appear to be anonymous our auto-generated functions related to the controls on the panel as it is reloaded. It appears that old script blocks from previous times the panel was updated are not disposed so the list just keeps on growing, slowing down the page and the debugger, until IE is closed whereupon it can take a long time to delete the hundreds of blocks that have appeared.

Is this a problem with the way the page is operating or an artifact of the debugger? Comparing performance of the debugged and non-debugged page it appears to be the latter, but it would be good to know what is going on and why.

Well Well here is your answer.

First Way


Basically when you debug through VS2008/2010, IE8 and forward, script debugging will be enabled automatically. Which is criticized by many. However there are few workarounds.

First one is in above article which tells you to enable Silverlight debugging and tells you path for both Projects as well Websites, where to go and how to enable it.

Once you enable silverlight debugging JS debugging is turned off as both can’t run side by side.

Drawback (if you really think it is ): Silverlight tools for VS need to installed

Second Way

Start the application without debugging (CTRL + F5) once app running attach debugger manually by clicking on Debug->Attach to Process.

Read More:   How to use square cursor in a HTML input field?

Now for VS 2008

For VS 2008 there are several alternatives like editing registry keys and so forth.

If anyone need VS 2008 help regarding that check this out.

Since the Timer is within the UpdatePanel the Timer will re-instantiate itself when the UpdatePanel is refreshed and therefore continue to and more javascript.
What you should do is put your Timer outside the UpdatePanel and link it with Triggers.

The following will creates a Timer that will update a Panel after it calls GetStatus from the code-behind.

<asp:Timer runat="server" ID="Timer1" Interval="5000" OnTick="GetStatus" />
<asp:UpdatePanel ID="UpdatePanel1" runat="server" UpdateMode="Conditional">
        <asp:AsyncPostBackTrigger ControlID="Timer1" EventName="Tick" />
            <asp:Button ID="Button1" runat="server" Text="DoStuff"
                OnClick="Button1_Click" />
            <asp:Label ID="Label1" runat="server" Text="Blank"></asp:Label>

    protected void GetStatus(object sender, EventArgs e)
        Label1.Text = "Stuff!!!";

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .

Similar Posts