I participate in development of a site that has a significant number of users who view our site through the AOL Desktop v9.7 for Windows - which spawns browser windows inside itself. When debugging, I don't have the tooling I would normally be able to invoke (for example Chrome's Developer Console; Firebug; MSIE's F12 developer tools).
When inside AOL Desktop, I don't appear to have any of these, or anything similar. Is there a developer mode or console I can invoke, unearth?
What I meant in my comments, you could just use a very decent JavaScript debugger with manual DOM inspecting features, which comes with Visual Studio ([EDITED] including the free edition). With some tricks, it does work for AOL Desktop, too (what an amusing piece of software that is, BTW :) Of course, this is not the same as IE's F12 Tools, it lacks the interactive features like visual DOM tree, CSS tracing etc. But it still allows to step through the code, watch locals and objects, evaluate expressions and access DOM elements. It's an invaluable tool and I use it a lot for projects where we host the WebBrowser control. After all, that's what AOL does, too. Anyway, if you're already familiar with this, just give this post a smile and disregard it. Otherwise, read on :)
I tested the following under Win7 SP1 VM with IE9, Visual Studio 2012 Pro (Update3) and the latest AOL Desktop 9.7. [EDITED] It also works with the free edition, Visual Studio 2012 Express for Desktop, Update3.
The only major obstacle was that in about 20 seconds upon entering the debugger, AOL Browser used to restart itself, thus disconnecting from the debugger. A workaround for this was to close AOL and delete the following files:
"C:\Program Files (x86)\AOL Desktop 9.7\"
shellmon.exe
shellmon.ini
shellrestart.exe
Then, I used the following basic HTML file for debugging purpose (as "debug.html" in the root of localhost):
<!doctype html>
<html>
<head>
<title>Debugger Test Page</title>
<script>
function debugPrompt()
{
if (confirm("debug?"))
{
debugger; // breakpoint
alert("after debugger");
}
}
document.onkeydown = function()
{
if (event.altKey && event.ctrlKey && event.keyCode === 'D'.charCodeAt(0))
{
event.cancelBubble = true;
debugPrompt();
return;
}
}
</script>
</head>
<body>
<button onclick="debugPrompt()">Debug</button>
</body>
</html>
Here's what I did exactly:
Made sure Script Debugging is enabled in IE settings for both Internet Explorer and Other:
Made sure [x] Script is checked in VS2012 Debugging Settings, Just-In-Time section ([EDITED] this feature is missing from VS2012 Express, but it isn't really important):
Ran AOL and navigated to localhost/debug.html.
Ran Visual Studio and attached to the aolbrowser.exe process (with Script as the target kind of code), via Debug/Attach to Process menu:
Went back to AOL and hit Ctrl-Alt-D (invokes the "debugger" prompt in my JavaScript listed above). The next thing, I'm in the VS Debugger right at the debugger; line of code. At this point, all usual debugging features are available. Note the Immediate Window panel and the Watch1 panel. Also, instead of hard-coding breakpoints with debugger keyword as I did, it's possible to use Visual Studio Solution panel (once the debugger has been attached) to select one of the JavaScript files loaded by the page and toggle breakpoints interactively.
Right now, I don't have Visual Studio Express 2012 to verify if the same is possible with it, although I assume it should be. I'll give it a try a bit later.
[UPDATE] Almost all of the above applies to the freely available Visual Studio 2012 Express for Desktop w/ Update3, with one exception: Just-In-Time Debugging option appears to be absent. This is not a show-stopper though, as it is still possible to attach to the running AOL process and debug the currently loaded page the same way.
PS. And thank you for your voluntary bounty offer on an unrelated question of mine, that is a really nice gesture.
Just in case anyone comes here looking for information: the newest 9.8 version of AOL Desktop now includes Chrome's developer tools, which open in a new window when you press F12.
Related
I'm developing a JavaScript addin for Office applications, e.g. Word, Excel and PowerPoint. At some point it should open a file that resides somewhere in SharePoint.
I want the url to open the correct Office application right away and for this purpose I'm using Office URI Schemes (see https://learn.microsoft.com/en-us/office/client-developer/office-uri-schemes?redirectedfrom=MSDN).
Depending on the logic in the app, I'm using two different techniques, which work perfectly when the addin is running in Word, Excel or PowerPoint on Windows.
Technique 1 (normal link)
Open Me!
Technique 2 (programmatic)
// Js pseudo code
button.onclick = () => {
window.location = 'ms-word:ofe|u|https://foo.sharepoint.com/path/to/file.docx'
}
As I mentioned, both these techniques works flawlessly on Windows. But when running the addin on e.g. Word Desktop on Mac, absolutely nothing happens. I've debugged the addin, by using "Inspect Element" to open up the console, but there's no errors or anything. It seems to me that the internal browser on Mac silently refuses to open the link.
However, if you paste the link into e.g. a word document, it will open the document if clicked.
Some thoughts:
is this related to the manifest.xml for the addin? (still works on windows without modifying the manifest)
do I need to enable something on Mac for this to work? (the Office URI Scheme page states these links should work on Office for Mac 2011)
Any input is greatly appreciated.
I found a workaround that works on Mac as well by using window.open(url).
I've developed a web-addin for outlook365. However, for some reason, the add-in stops working on desktop client. It just load the HTML page for the taskpane but not executing the taskpane.js. The add-in still works on web based outlook. I tried to investigate the issue, found that the Office.onReady handler is not called on desktop client. Any idea what could be the cause?
Thanks,
Peng
The Office.initialize = function () {}; needs to be called first.
If an Outlook add-in running on Windows is not working correctly, try turning on script debugging in Internet Explorer.
Go to Tools > Internet Options > Advanced.
Under Browsing, uncheck Disable script debugging (Internet Explorer) .
We recommend that you uncheck these settings only to troubleshoot the issue. If you leave them unchecked, you will get prompts when you browse. After the issue is resolved, check Disable script debugging (Internet Explorer) again.
I had the same problem.
Finally, I use Office.onReady(); rather than Office.initialize = function () {};. Refer to the link below for more details :
Outlook addin
I cannot start my website from Visual Studio 2010 anymore.
For a few days I cannot start my project in a web browser using F5. When I open my web application directly by typing the same url 'http://localhost/Default.aspx' everthing works fine.
When I run the project (F5) a new webbrowser starts, but after a few seconds it is stuck and Visual Studio gives an error dialog:
Microsoft Visual Studio
Unable to start program 'http://localhost/Default.aspx'.
OK
When I run the project in release mode it gives an extra error:
Microsoft Visual Studio
The following module was built either with optimizations enabled or without debug information:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\6552bec6\694bce32\assembly\dl3\8c9bd8d8\fb1d75cb_af26cc01\[name].Presentation.DLL
To debug this module, change its project build configuration to Debug mode. To suppress this message, disable the 'Warn if no user code on launch' debugger option.
OK
I have already repaired, removed and reinstalled Visual Studio 2010, I've tried using different browsers (including Chrome and Firefox), used different aspnet_regiis.exe options, etc. etc.
Nothing helps, and yeah now I'm stuck pulling hair out of my head ...
Anyone any idea how to solve this?
Does it work if you start it with [CTRL]+[F5] which runs without the debugger?
If so, then you have an issue with the debugger auto-attaching to the web server. I would check that debugging is enabled for your web project - a warning that usually crops up automatically from VS when it detects that a project is not built in Debug mode.
This is not as simple as switching the project configuration over to Release, because the DLL that the debugger is moaning about is one of the dynamically generated ones originated by Asp.Net itself.
Typically you should have, in your web.config:
<configuration>
<system.web>
<compilation debug="true" >
</compilation
<system.web>
<configuration>
(Along with any other stuff in <configuration> and <system.web> nodes).
There's also the possibility that Asp.Net debugging is not, for some reason, enabled.
Check out this msdn article on debugging asp.net applications in VS2010 for more information.
Note that if this is VS010 express, then you won't be able to debug - as confirmed by the aforementioned link; but since you way it used to work then I guess that's not your problem.
Update
Since that hasn't worked - you can try emptying the Temporary ASP.Net files folder. Easiest first is to do an iisreset. Then navigate to C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files and delete everything in it. I've had issues in the past where the Asp.Net binaries don't get refreshed and so when I'm debugging it moans that the files are out of date.
Change the View Browser to another browser. Run the view in browser or debug, then change back to original browser should work after that.
Had same problem, answer for me was to remove Avast Free AV. Everything worked for a year with avast free up until a week or so ago, uninstalling it fixed the problem.
I had this exact problem with Visual Studio 2008. The solution was to set the default web browser that VS uses to a real browser (e.g. IE) and not the "Internal Web Browser".
Right click on an ASPX file in your project and select "Browser With...". This lets you select the default browser to use when you select the "View in Browser" option and for when you debug/run the app (this is key).
Select your favourite browser (i.e "Internet Explorer") and click on "Set as Default". Do not pick "Internal Web Browser".
Debug away! Your app should come up in your browser now and debug as normal.
the solutions for me is to test with 127.0.0.1 in place of localhost. and all goes well for.
so the problem come from the host resolution name, to solve it please proceed like :
open cmd and then tape : %systemroot%\System32\drivers\etc\
open hosts file with notepad and the look for localhost ligne(you'll find 0.0.0.0 befor it )
change the 0.0.0.0 with 127.0.0.1 at all lignes with localhost .
I solved in this way:
Right click on a aspx page
Browse with set internal browser as default
Remove the previous default browser
Add %programfiles(x86)%\internet Explorer\iexplore.exe
Set this choice as default
For me I just did a Build /ReBuild on the project level and it started working!!!
I had the same problem. When I debug my code it says:
Unable to start program 'C:\homework.exe'. this system cannot find the file specified."
I'm using Microsoft Visual C++ 2010 Express but when I made a new project by the following steps:
Open C++:
Press new project
Press win32
Press win32 Console Application
Rename it
Click next
make sure: that the application type is console application
additional options: empty project*
Press Ctrl+Shift+A
In Visual C++/Code section press C++ File (.cpp)
rename it and press add
It works fine with for me now.
Please set your page name e.g Default.aspx revert to parent in IIS configuration
I'll share my experience with this same problem. This is not a solution, but someone may be able to figure out the problem from my particular experience.
I've been having this same problem for a few weeks now. (I don't know what changed on my system.) I do not run as local admin, because we are not allowed to have admin privileges on our PCs where I work.
Until today, I could expect F5 (Start Debugging) to start up a new local VS web server, open an IE window, and then issue an "unable to start program http://localhost:nnnn/Login.aspx" and "access is denied" error pop-up. If I closed the IE window, waited a few seconds, and then clicked F5 again, it usually started up my web app in debug mode just fine from that point on.
But today, that all changed. I did not change any configuration on my web app, which has been running fine, but I did add a couple of more classes to one of my subprojects. At this point, I could never get past the "unable to start program" message. I could run my app without debugging, but that was rather pointless. I even tried attaching to a running (non-debug) IE process, but that did not work.
Finally, I modified some of the properties in the WebAppName >Web >Servers screen. Specifically, I enabled "Specific port" for a specific HTTP port (which VS had been using all along), and I disabled "NTLM Authentication". I also enabled "ASP.NET" in the Debuggers section. Some of these I first clicked, then unclicked, then clicked again, saving in between each click.
This time, running with debug (F5) worked.
After running several times, I still usually get a "unable to start" error the first time after a recompile, but I can still usually get a debuggable running app to start after the second or third try. At least I'm back to where I was yesterday.
I suspect it has do with VS reloading its execution profile, and also probably something to do with permissions (since I cannot run as admin).
I'm using VS2012 with an ASP.net app that was written using VS2003... I've tried everything to get the IE page to open automatically when I select F5, or even Ctrl+F5... Haven't been able to get anything to work... However, I have stumbled upon a very poor work-around. When I select debug and I get the 'Unable to start program...' msgbox... I noticed that on the icon-tray I get a msg saying local-host has started
You'll notice a picture that the msgbox is pointing to:
Well, if you right click it, you get three options:
When you select the first: 'Open in Web Browser', it will open IE with the page your working with...
Like I said, it's a very poor work-around... but it works. This isn't an issue when I select debug using 'Chrome' or the page-inspector... But they have their own issues.
Try to turn on Bypass proxy for local addresses.
First you can go to your browser settings-> Change proxy Settings-> Connection-> Lan Setting and just check bypass proxy for local addresses.
If this solution don't work then also copy the following code check your web.config file for settings to bypass firewall:
<system.net>
<defaultProxy>
<proxy usesystemdefault="true" proxyaddress="http://proxy:port" bypassonlocal="false" />
</defaultProxy>
</system.net>
I easily resolved this problem by enabling script debugging in the browser.
When I ran into this problem (using IE 11) I noticed that iexplore was open about a hundred times in the task manager. After killing them all I was able to open my project just fine.
Since then, I have made a .bat file with this code:
taskkill /F /IM iexplore.exe /T
so now I just run the .bat when I get that error.
(alternatively you could run that code from the cmd)
I just ran into this problem in Visual Studio 2013. I had to enable Anonymous Authentication.
Click on the project node in solution explorer.
Hit F4 to show the properties window.
Change the Anonymous Authentication option to Enabled.
UPDATE: navigating to the process via menu:DEBUG / Attach Process / iexplore.exe shows "Automatic: Silverlight code". i.e. VS 2010 already attached to the process. Why doesn't it go to debug view?
I have a frustrating debug behaviour going on on my laptop which I'd like to fix. I was following along with the demo called Silverlight TV 46: What's Wrong with my WCF Service?
On my computer, I noticed that putting throw new ArithmeticException() in the RIA service causes the just-in-time debugger to get involved (a bad thing -- I want VS). I can put a break point on the the throw new ArithmeticExpression() line, and VS stops as it normally does. Press F10, and I still get the just-in-time debugger kicking in.
On Yvor's computer (the presenter in the Ch 8 link above), the visual studio debugger kicks in instead of the just-in-time one. What am I doing wrong? Could having Redgate Reflector installed previously have caused this (it is gone now).
ERROR:
Visual Studio Just-In-Time Debugger
Code: 4004
Category: ManagedRuntimeError
Message: System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid.
Check ...
Possible Debuggers:
New instance of MS VS 2010,
New instance of VS 2008.
[checked] Set currently selected debugger as the default.
[unchecked] Manually choose the debugging engines
Action: Hit Yes.
2nd ERROR:
Unable to attach to the crashing process. A debugger is already attached.
I've spent several hours looking for a way to solve this.
Browser is IE9 / Silverlight 4.
Previously, I started starting the silverlight app directly via the VS2010 environment... but then decided to get more deployment compliant (again).
http://msdn.microsoft.com/en-us/library/cc838267(VS.95).aspx
Down the bottom they mention repairing from control panel / VS2010. Did that. Waited for ages, made coffee, did something else. Finally complete. Problem sill there. Included this step just-in-case the fix is cumulative (you get superstitious after a while with these things).
I then deleted zap files, switched startup page from html to the aspx one. Wired aspx to the xap (it wasn't pointing to the /debug/ folder). [note: looks like you can remove the debug via Silverlight Project / build / Output path: Replace Bin\Debug\ with Bin. With Silverlight I feel that the relative Uri path should match up to your html / aspx files no matter what -- wheather you are in Debug or Release.
project properties / Web / Specific Page
debugging works again!
Did .html stop debugging? Casual inspection reveals the same javascript stuff firing up Silverlight. On the surface it looks the same. hmmm. I guess it isn't.
... here are a few extra things to look at for those who still have issues (I may as well list them
while they are fresh in my mind).
project / properties / Web / Debuggers: I now only have Silverlight checked. ASP.Net is not checked any more. (Not sure if this influences my result at this stage)
make sure your web project points to the silverlight project in project / properties / Silverlight Applications. This ensures that the silverlight project's binary "xap" is copied to a folder within the Web Site / Web App. Note: hitting the add button reveals a destination folder (should be ClientBin).
Your build configuration will add an additional sub foler e.g. debug.
Make sure your .aspx or .html files have the right path. For me, I just included the .ClientBin/debug/ folder. I don't think this is deploy friendly, so I will search for a better way later.
IE9 settings.
[X] Disable script debugging.
[X] Disable script debugging (Other)
[ ] Display notification about a script error
[ ] Show friendly HTTP error message
Again, unsure if these later setting have an impact.
Lastly, there's something that I forget about sometimes. Be sure to check Debug VS2010 / Exceptions / Common language Runtime. This ups the ability to catch exceptions.
I had a similar problem, but the above did not resolve it. However, starting the application without debugging (Ctrl-F5) and triggering the exception would allow me to select the Visual Studio instance that I started the application from. Amazingly, I got a sensible stack trace and resolve the problem within a few minutes.
I'm running Visual Studio 2010 with SP1, as well as R# 5.1, and a few other extensions (like PowerCommands and Productivity Power Tools). Somewhere along the lines, my debugging got super slow. If I use the F10/F11 keys to step, VS hangs for a bit and then steps. If I use the toolbar buttons for stepping, it's snappy as expected.
Any idea what's up with my shortcut keys?
I had exactly the same problem - extremely slow debugging with keyboard (F10 for example). Some symptoms:
if I click Step Into on toolbar, then everything works normal,
the lag during debugging is present not only in Visual Studio but anywhere (notepad, browser,...),
if I set any other browser as default browser in Visual Studio (I tried Firefox), then it works OK,
if I disable third-party browser extensions in IE, then it works OK,
if I enable third-party browser extensions and disable LastPass, then the problem is gone and debugging with keyboard is fast again!
So, try to disable LastPass extension if you have it or all extensions and try it.
Edit1 - somebody allready posted this on LastPass forum: http://forums.lastpass.com/viewtopic.php?f=12&t=61029
Edit2 - and here on SO also :) https://stackoverflow.com/a/8186670/1110039
I've found a deeper explanation for this problem.
I had this problem, with the symptoms user1110039 described BUT I haven't installed LastPass toolbar. And my default browser is Firefox.
Well, my application uses SetWindowsHookEx() function for setting a system wide shortcut. Which happens to be the reason for blocking F10/F11 debug keys (only in Windows 7 64 bits) It doesn't happen under 32 bits.
I've just removed the hook from the debug build and it works ok. I reckon the problem with LastPass is some system wide hook in the code of the extension.
I had exactly the same problem.
The problem was solved by closing the Watch window.
Try debugging with Firefox or Chrome. There must be something about the interaction with IE that is causing this behavior.
Disable "show threads in source" worked for me!
Calling DirectInput's Acquire() function on a keyboard device is what caused the slowdown for me. This is potentially related to the SetWindowsHookEx() caused slowdown - ie. that might be using DirectInput.
It's really odd that the keyboard stepping is slow while the toolbar buttons are not. Typically whenever I hear about a slow stepping experience my recommendation is to disable automatic property and ToString evaluation as this is the most likely cause
Tools -> Options
Debugger -> Uncheck "Enable property and .ToString evaluation"
I'm not very hopeful that will fix this instance. It sounds like a problem with a misbehaving extension that processes keyboard input. Your best bet is to disable the extensions one by one and see which one fixes the problem. I would do it in the following order
Productivity Power Tools
Power Commands
R#
Make sure you've installed Service Pack 1. I believe they fixed at least one significant performance problem in the debugger.
I experienced that very slow step by step debugging too, and fixed it by closing the threads window.
(Making a note here on an old thread, so it can be found in a web search.)
I normally leave the ==Disassembly== window open during debugging (I have a big screen.) I just discovered that single-stepping in the debugger can be speeded up by 50% if I hide that window too. The -tab- for it can exist and be handy - makes no difference - but the window itself shouldn't be showing. Ahah.
Have followed all the other suggestions and more from elsewhere, single-stepping is now about 8 times faster overall. (About 2.5 steps per second now.) Woo-hoo! Thank you all.
(I don't understand how they can write such slow UI code... I have a CPU here that's running at two billion cycles per second... that works out to about 400 million instructions per single step. Seems like Microsoft code could be a -little- faster... but then, I've never had the pleasure of using .NET etc.)
I tried all the suggestion and finally found that When I uninstalled VS2005, this issue got resolved. Note that in that machine VS2005
I was having this problem in my new job, where we use Visual Studio 2008 SP1. (Yes, I know, I know). Long delay on step with flickering hourglass. I always use F10, I don't even think about it, there's no way I could tolerate changing to the mouse or waiting multiple seconds for a simple step command.
I read through all the solutions provided here and elsewhere on the net with no joy.
Finally found the issue - I had set up my default language for the IDE as C#. It turns out the project I'm working on actually uses VB.NET, and when I set the default language to VB.NET (via Tools - Import and Export Settings) the debugger got so fast that I couldn't keep up with it and accidentally pressed F5 on the breakpoint I want to examine.
I hope this helps someone else.
In the end, the disabling of Last Pass in my browser (IE) was what solved this problem for me, but along the way I learned a lot of other things that could have just as easily been the cause. A variety of other valid answers to this question (Some in the various answers on this page) are validated and explained here:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-debugging-faster-with-visual-studio.aspx
This article explained that this F10 slowdown can be from having various diagnostic windows and toolbars open, Symbol loading issues, etc. and also explained what to do about debug slowdowns in general. It was an eye opening education that I think will continue to help me in the future should the F10 slowdown rear it's head again.
In my case it was the Call Stack window (Visual Studio 15.9.13) that caused the lag!
Even when I stepped over a very simple line like ++i; it took around 1-2 seconds until the debugger stepped over to the next line. Closing the Call Stack window or hiding it fixed the lag for me immediately.