We Keep Coding

Why does my ASPX page goes into dynamic preview when debugging Web application [duplicate]

Since I installed Visual Studio 2010 from scratch about 2 months ago, it behaves slightly different when debugging JavaScript code being run in IE.
When I set a breakpoint, it opens a duplicate of the view with the term "[dynamic]" in the header and marks the breakpoint in there.
When a JavaScript error happens during execution, it does the same before it marks the line of code that threw the error.
This "dynamic" view is editable but edits have no effect - they are not saved to the file.
I find this behavior pretty uncomfortable. Everytime I notice an error in the code during debugging, I happen to fix it in the dynamic view. I hit save. VS does not complain. Next I refresh the page in IE, and - bang - the changes are lost, it loads the untouched old version again.
I haven't been able to find out how I can turn these views off. Before I re-installed Visual Studio it did not do that. It would only create "dynamic" views for script found in inline script tags in HTML files.

Try this
IE > Internet Options > Settings (under browsing history) > Check for new version of stored pages : Every time I visit the webpage.
This works for me in IE10.
Other option is to open Developer tools and select cache option Always Refresh from Server as show in the image below

Try hitting CTRL+F5 on the web page. That did the trick for me.
The problem was that I had opened other IE windows from a previous debugging session, so the dynamic javascript files were still cached.

Having developer tools open - F12 - should also cause the cache files for the page to be cleared on each refresh.

Changing the encoding of the JS file in question, from a Windows codepage to UTF-8, fixes this for me.
Narrowing it down, it appears that OEM Extended ASCII characters in the file (e.g. ALT-254 which I use for a bullet) trigger the problem with the Windows codepage files.
(Visual Studio 2013 Update 5, IE11)

For Google Chrome:
Open developer tools(F12)
Open Network Conditions Tool
Select Disable Cache

I had the same problem of not being able to hit a break point in new code. And breakpoints on old code in the same page will bring up the [dynamic] version. The edited page is not reloaded. This just started for me a week ago in both VS2012 and VS2013. Using refresh page and/or Ctl-F5 did not work for me. BUT, reading this thread pointed me to using F12 to open Developer tools. Leaving that window open, while hitting refresh does the trick. Thanks guys.

1) Run the page Without Debugging (Debug-->Start Without Debugging)
2) While the web page is open in Internet Explorer, press Ctrl-F5 so
that the IE cache is cleared. Ensure IE has the focus.
3) Close IE and re-run the page with Debugging (Debug-->Start
Debugging).
This fixed the issue for me.

.NET 4 WebBrowser hangs

I am using .NET 4 and trying to use the desktop authentication for the StackApps site via the web-browser control (WPF and/or WinForms) to develop a NNTP Bridge for accessing StackOverflow (https://stackapps.com/questions/4215/stackapp-nntp-bridge-for-accessing-stackexchange-forums-like-stackoverflow).
It seems that the login cannot be done, because the web browser hangs up, after the page from "StackExchange Login" is displayed.
I use the following URL:
https://stackexchange.com/oauth/dialog?client_id=1736&scope=no_expiry&redirect_uri=https://stackexchange.com/oauth/login_success
It works in the normal IE browser, but not in a WinForms or WPF window... Does anyone know what the problem is?
It is simple to repoduce:
Create a WinForms-Project
Add the "WebBrowser" control to the dialog
Double-Click on the Form1
Add the following code
private void Form1_Load(object sender, EventArgs e)
{
webBrowser1.Navigate("https://stackexchange.com/oauth/dialog?client_id=1736&scope=no_expiry&redirect_uri=https://stackexchange.com/oauth/login_success");
}
Start the application
Login by pressing the "login with Stack Exchange" account symbol
A new page gets loaded; it is displayed correctly, but you cannot enter your login name; the window hangs...
The same happens, if I use WPF-App and the WPF-WebBrowser-Control... it seems that it is stuck in an endless-loop in JavaScript...
Any hint on how to solve ths problem?
Or is it possible to debug the JavaScript in the WebBrowser-Control???

Fixing WebBrowser Control
I also had the issue of the WebBrowser control handing when trying to login.
Although requesting a token in IE (11) works, I found that IE itself also hangs when I put it in IE 7 emulation mode. This suggested to me that my previous attempt to make the WebBrowser control use a newer version had failed.
I found this article, Web Browser Control Specifying the IE Version, which suggests that for 32 bit applications in 64 bit mode, you need to set a different registry value.
So now, I've added two values in the registry:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION
and
HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
In both of them, I added a DWORD value named 'MyExecutable.exe' (where MyExecutable is the actual name of my executable). The value for each of them is 9000 which will work for IE9 and above. Watch out when using RegEdit to test this, it will default to hexadecimal instead of decimal. Also, make sure it is a DWORD value, not any other type.
This seems to do the trick. I can now run the application, go through the login process, and eventually I am redirected to the url specified by me, which I can then capture using the OnNavigate event of the webbrowser control.
Remaining issue
It doesn't really work perfectly. The first time I was redirected to some OpenID page as well, but at least the form didn't hang. With subsequent attempts, apparently the login (which succeeded before) is remembered and I get the message "Navigation to the webpage was cancelled" with a link to refresh the page. When I click that link, I am immediately redirected to the redirect_url I specified when requesting the login form. At least that part works, and I get an actual access_token and an expiry time, so for now I'm happy.
Update: After some testing, it turned out that the previous login was remembered. That causes the request uri to direct to the redirect_uri immediately. I used the OnBeforeNavigate event to detect this, but it isn't fired in this case. I now linked the NavigateComplete2 event, and that one is triggered in this scenario.
Fix for .NET?
I think for .NET the solution should be the same: add the executable (and MyExecutabl.vshost.exe as well, for debugging purposes in Visual Studio) to the first key. If it's a 32 bit executable running on 62 bit Windows, you might also need to add it to the second key, although I'm sure if that rule applies to .NET as well. I don't do C# on a daily basis, and I'm trying to get it to work in Delphi first, but if I find time to test this in C# I will post the update here.
In the end, it would be nice if the actual issue would be solved, and the JavaScript would work in IE7 mode as well, but at least this seems to be a proper work-around.

Unfortunately, I'm not a JavaScript developer, so I only could try to explain you how to debug a JavaScript that executes in the WebBrowser control.
This approach is for the Microsoft Visual Studio, I don't know if Delphi can provide similar functionality.
Enable Script Debugging (both Internet Explorer and Other) in Internet Explorer settings.
Disable Friendly HTTP messages in Internet Explorer settings.
Enable Display a notification about every script error in Internet Explorer settings.
From Visual Studio, start your WebBrowser hosting application without debugging (i. e., Ctrl + F5).
In Visual Studio, go to Debug → Attach to Process… and select your application in the list.
Hit the Select… button to the right of Attach to: field and choose Script code.
Hit the Attach button. Visual Studio starts the script debugger.
In your application, navigate to the deadlocking page by pressing the Login with Stack Exchange account symbol.
Go to Visual Studio and press the Pause button on the debugging toolbar.
Now you can look into your script code and investigate the code itself, the call stack, the variable values and so on. You can set breakpoints too. Perhaps you can then find the place where the script hangs. As I said before, I'm not a web developer and cannot help you with this…
Update:
I guess I can propose you a working solution.
My investigation shows that the WebBrowser hangs when it renders the content in the IE7 mode (what is the default mode even if you have IE10 in your system). You should force it to switch into IE9 mode. In IE9 mode, the page renders well and does not cause the script to stuck in an endless loop.
You can switch your WebBrowser to the IE9 mode using one of the following methods:
Define the global browser emulation mode for your application in Windows registry.
For 32 bit OS, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION.
For 64 bit OS, use HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION.
In this node, create a new DWORD parameter called YourApplicationExeName.exe with a value 9000 (0x2710). You can create another entries for your *.vshost.exe executables, if you want this to work in Visual Studio debug mode.
Manipulate the source for the WebBrowser to switch it in the IE9 mode.
This will be more complicated. You need to alter the <head> tag of the html document adding a new <meta> tag preferably as a first element: <meta http-equiv="X-UA-Compatible" content="IE=9"/>.
This will cause the WebBrowser to switch its mode on document rendering. Since you can't change the compatibility mode after the document is rendered, you could use a proxy as a source for your WebBrowser, so this proxy will add the header.
I`ve successfully tested this with the 1st approach, and the second one should work too.
Hope that helps!

Project + Properties, Debug tab, tick the "Enable native code debugging" option. Ensure that you've got the Microsoft Symbol server enabled (Tools + Options, Debugging, Symbols), I know you do :)
You can now use Debug + Break All and see what's going on inside the browser. Do so repeatedly to get the lay of the land. You'll see that Javascript is executing (jscript8.dll) and constantly forcing the layout engine to recalculate layout, never getting the job done.
Browsers in general are vulnerable to Javascript that's stuck in an endless loop. A regular browser tends to put up a dialog after several dozen seconds to allow the user to abort the JS, but WebBrowser doesn't have that feature. Nor does it have the dev tools so debugging the JS isn't going to be a great joy either. This is going to be difficult to get fixed.
You might consider using the OAuth 2.0 api instead. Notes on usage are on this web page. Exactly how to integrate that with WebBrowser is a bit murky to me, I don't have a key to test this. Find help for this at the Stackapps site. You are probably not the first SE api user that ran into this problem.

Displaying console output?

I am currently creating a customer application for a local company. I have a datagridview linked to the customers table, and I am trying to link it up so that updates, inserts and deletions are handled correctly. I am very new to c# so I am starting with the basics (like about 2 days ago I knew nothing - I know vb.net, Java and several other languages though..).
Anywho from what I understand anything output through Debug.WriteLine should only appear when in debug mode (common sense really) but anything output through Concole.WriteLine should appear whether or not in debug mode. However I have checked the immediate and output windows and nothing is being output when in normal mode. Does anyone have any idea why this is??
Edit: I have event handlers for clicking a cell - it should output CellClicked and set the gridview to invisible when a cell is clicked. The latter works whichever mode I am in, but CellClicked is only output in debug mode. I am using Console.WriteLine("CellClicked").
Edit: Seems I may have solved it - I just set the output to Console Application in the project settings pages. It now opens a command line window as well as a windows form, but I can change the output back again when I compile for distribution. Thanks for the help.

Console.WriteLine() outputs to the console window in the case of a console app only.
You are probably looking for Trace.WriteLine().

Getting the output of Console.Write/Line() written to the Visual Studio Output window is a feature of the Visual Studio Hosting process. Project + Properties, Debug tab. This will not work if you run your app without a debugger, the hosting process isn't being used.
Using Console.WriteLine for debugging isn't the greatest solution. That code will still run in your Release build and take time formatting the output string. And prevent the JIT optimizer from doing a good job generating the most efficient machine code. Output will fall in the bit bucket, nothing to actually write it to.
And it is unnecessary, the debugger gives you much better tools to find out what is going on in your program. Take some time to familiarize yourself with its capabilities. If you want to find out if an event handler runs, just set a breakpoint. Such a breakpoint can even trace output without actually breaking. Right-click the red dot, click "When hit" and use the "Print message" option.

I think you'll like the tracing infrastructure a lot better than Console.WriteLine. Tracing gives you many different options for where the trace messages can go, as well as being able to turn them on or off. You can also set different levels of tracing output so that you can adjust how much logging actually gets done. The built in tracing in .NET is very flexible, and is well worth the investment to learn.
Here are a couple of references to help you get started:
http://msdn.microsoft.com/en-us/library/ms228993.aspx
http://msdn.microsoft.com/en-us/library/ms228984.aspx
http://www.code-magazine.com/Article.aspx?quickid=0409081
HTH!
Chris

You could go to Tools | Options | Look for Debugging, General, Choose the Redirect all Output Window text to the immediate window, or try to log the console-intended output to a file and view it there instead.

Visual Studio Web Application edit source while running like in Tomcat\Eclipse\Java

In an ASP.NET Web Site project, I've always been able to make changes to the underlying C# code and simply refresh the page in the browser and my changes would be there instantly.
I can do the same thing when working with Java and Eclipse - edit my Java source and refresh the page and my changes are there.
I cannot do this in ASP.NET MVC though and it is a real downer - I have to stop the running process and make my changes, and then restart debugging. This is a huge waste of time.
Am I doing it wrong? What is the best approach to ASP.NET MVC development?

I rarely use debug mode in ASP.NET MVC project (F5). I run the project once with CTRL+F5 and always have a browser window open. Then if I make a change to a view (.aspx, .ascx), I hit F5 in the browser and changes automatically take effect. If I have to do changes in the .NET code (controller logic, models, repositories, etc...) I no longer use the browser. To verify that my change is correct I navigate to the corresponding unit test and hit CTRL+R+T. The result is seen either in green or red.

Visual Studio locks the source code in debug mode. So your options are:
Publish the site on your local IIS and use the "attach to proccess".
Use Run without Debug (Ctrl-F5) instead and again "attach to proccess".
Break the execution in debug mode (with Breakpoint).
The first one is my favorite.

You don't have to stop the process, you can break.
Try breaking the project, then editing, then continue.
1) CTRL-ALT-BREAK
2) Edit your code
3) F5

My technique has been to launch it normally then copy the URL from the browser and open another window for the website then kill the original. Once you kill the original browser, VS lets your source code go but you still have it up in another window and can navigate it normally. Now you can edit your code and then refresh the browser and it works just like before.
The only reason to launch it normally first because VS seems to pick a random port number against localhost when firing up the built in IIS. But even that rarely changes
My URL usually looks something like this:
http://localhost:49434/something.apsx
The port numbe changes on occasion but it seems to stay the same as long as you dont close visual studio. Once you kill VS your URL will fail.

Run the MVC project with shortcut key (CTRL + F5) and now any changes you make to the C# code would be reflected in browser after refreshing (F5)

The fastest way to code is to Host locally on IIS and then all you have to do is build the solution before checking out your changes.
Another alternative is chucking everything into the App_Code folder which will compile on the fly as you make changes.

Is there a way to *completely* disable Edit and Continue?

I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
How to: Enable and Disable Edit and Continue
“Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
How do I enable file editing in Visual Studio’s debug mode?
How does “Edit and continue” work in Visual Studio?
Can we edit our code while running the application
Editing C# while debugging
Thanks in advance for any help or ideas...
Mike

Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
Open the executable assembly's properties
Go to the Debug tab
Check the Enable unmanaged code debugging checkbox
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".

Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam

Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.