Description:
If you use Visual Studio 2013 for web development, you could face some issues:
1) A Web application is being loaded for a very long time/client scripts are being loaded long when you debug it on the development server;
2) CPU usage by the local IIS worker process increases enormously while debugging the application;
3) Pages that use the jQuery library return JavaScript errors;
4) HTML markup contains garbage tags;
5) The "ArgumentNullException: Value cannot be null. Parameter name: key" error occurs (the stack trace contains the FindEntry / TryGetValue / BrowserLinkExecutionListener.FindSourceFile methods).
Answer:
In Microsoft Visual Studio 2013, the Browser Link feature was introduced. It provides dynamic exchange between IDE and any open browser on your machine. With the help of this feature, you can test changes in page markup in browsers on the fly, inspect HTML objects, etc. However, the use of this feature might cause above mentioned problems in the debugging process.
A common solution is to disable Browser Link in Visual Studio:
via menu (uncheck the "Enable Browser Link" check box):
or via the web.config file:
XML<appSettings>
<add key="vs:EnableBrowserLink" value="false"/>
</appSettings>
Visual Studio 2015:
Startup.cs:
C#public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) {
...
//app.UseBrowserLink();
}
Case 1 and 2: The cause of the problem is that the Browser Link feature requires dynamic compression to be disabled. The dynamicCompressionBeforeCache attribute allows IIS to dynamically compress the response when a request is made for the first time and queues the content for compression. When this attribute is enabled, a page loads faster, whereas if it is disabled, it causes additional CPU consumption and increases the page load time - see the remarks section of the MSDN : urlCompression article.
In these cases, the only solution is to disable the Browser Link feature as described above.
Case 3:
Browser Link's Scripts Manager adds a jQuery reference to the <body> tag. JavaScript is an interpreter language and processes code line-by-line, so the place where the scripts are referenced or declared is really important. If a custom script that uses the jQuery library is declared before the body (commonly, scripts are added in the head), it will not work correctly.
If you want the Browser Link option to be enabled, you can move jQuery-dependable scripts to the <body> tag.
Case 4:
This issue is usually caused by a page compression conflict. If URL compression has the enabled dynamicCompressionBeforeCache that is set by default for IIS 7.5, it interferes with HttpModules that are used by Browser Link, and produces problems in output.
If you want the Browser Link option to be enabled, disable the dynamicCompressionBeforeCache (web.config -> system.webServer):
XML<urlCompression doDynamicCompression="true"
doStaticCompression="true"
dynamicCompressionBeforeCache="false" />
See also:
VS 2013 Browser Link generated script causes jQuery reference to be broken
Browser Link feature in Visual Studio Preview 2013
Page uses an invalid or unsupported form of compression when debugging ASP.NET MVC app with Visual Studio 2013 Preview
now it's working fine. Thanks Helen
Thanks Helen,
Your thorough analysis helps a lot!!
Regards,
Luiz
Welcome!
Clear helpful comprehensive yet simple! Excelent!
Thank you!