First of all, everything was working fine for several months:
When I tried to debug a web app with Visual Studio 2005 and Internet Explorer 7, I just click "Start Debugging", a IE window opened and the process was attached to the debugger.
But after I installed IE 8, the process was not attached automatically. I had to attach manually to be able to debug anything.
Then I discovered that to make it work correctly I had to close all other instances of IE 8 before start to debug. But I did not need to do this with IE 7.
I have Windows Vista Enterprise and everything is up to date.
Is this the correct behavior? If it is not, what I have to do to debug a web app without having to close any other IE 8 instances?
The problem is caused by IE8 creating new processes for each new tab.
This is the solution
1) Open RegEdit
2) Browse to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet Explorer -> Main
3) Add a dword under this key called TabProcGrowth
4) Set TabProcGrowth to 0
Check out this link for the full details from Brad Sullivan
http://social.microsoft.com/Forums/en-US/vsdebug/thread/e2c795cd-b7a0-4fad-b7c9-b1ca40d7302e
In summary: IE8 creates a new process for each tab. The VS2005 debugger doesn't know which process to attach to, and so doesn't attach to anything. The solution is to stop IE8 creating new process for each tab. Brad mentions that this problem is found on older versions of the VS debugger, but does not say if it works properly in VS2008 or VS2010.
Edit: If you are using Vista you need to turn off IE "Protected Mode" which is a checkbox on the Security Tab under Tools -> Internet Options.
Related
I have built an add-in which works fine in Excel online, whereas it does not work in Excel 2016 for Windows.
I know that in Windows 10, we could use this tool to debug the add-in, however I am using Windows 7.
I just installed Visual Studio 2017, right clicking on the add-in shows a menu where Attach Debugger is. But clicking on Attach Debugger fires nothing.
Does anyone know how to debug in this case?
Two potential options:
You can use Volorn.js to remotely debug your add-in. You can use the Debug Office Add-ins on iPad and Mac article as a starting point. Although this article is targeting Mac and iPad, the concepts are the same for Windows.
You can also use Visual Studio by creating a new Excel Web Add-in. Simply replace the default manifest with your own. Note that you still need to retain the default web site, Visual Studio still this for some library references. It will use your manifest's URL for the source location however.
Office applications use Internet Explorer for the web browser, so all settings from IE should carry over. I have found that if you disable (uncheck) both the Disable script debugging (Internet Explorer) and Disable script debugging (Other) options, your debugger breakpoints will be hit (I tested this in Outlook 2016).
You will need add debugger; statements to the source code to add breakpoints. When these statements are hit, a dialog like this should appear:
Simply select 'Yes' and a new instance of visual studio should open, with the debugger attached to your script.
I have installed and registered Visual Studio 2010 Premium (+SP1) onto the Windows XP Mode VM within Win 7 Pro; I have applied all of the product updates also. I have not yet created any projects as my first task was to try and connect to our TFS 2013 Server.
My problem is that from within Visual Studio 2010 whenever I try to "Connect To Team Foundation Server" from either the Start Page; The 'Team' Menu drop down or the icon in the Team Explorer tab, the window to "Connect To Team Project" flashes up and immediately closes and so I cannot enter the details of my TFS server.
I cannot find any errors 'Event Viewer' and there is no further information from Visual Studio. It cannot be the TFS setup as I haven't got that far yet.
It looks like XP mode is interfering. Not all applications are supported and I have never seen or used visual studio in this manor.
You would be better either running VS2010 on your local Windows 7 or running it in a VM (Not in XP mode).
I found a solution to this and it is somewhat unbelievable, but it definitely worked for me:
Ensure HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Control Panel\Colors = 0
Go to Internet Properties -> General -> Colors
Change the check state of 'Use Windows Colors' and change the check state back again then click OK and click OK on the internet Properties page.
My "Connect To Team Project" window now stays open allowing me to select a server!
A colleague enlightened me to this trick which is regularly used for Win 7 installations but this is the first XP version (although it is the Win7 XP Mode VM).
This works to fix flashing pop up screens for Win7 & XP and has been reported to MS.
I can no longer debug my Silverlight application in Visual Studio after updating to Internet Explorer 10. I made no other changes to my system and it was working fine with Internet Explorer 9 just before the update to IE10. When I hit F5 in Visual Studio, IE10 is fired up and the Silverlight application runs in the browser, but breakpoints are not hit in Silverlight code. If I hit shift+F5 (stop debugging), the browser remains open (this used to shut it down). Alternatively, if I close the browser while debugging, it doesn't stop debugging in Visual Studio (which it always did before). I'm running Win7 64.
This problem has also been reproduced in Visual Studio 2010 and Silverlight 4.
I had the same problem with Visual Studio 2012 and Silverlight 5. The symptoms that I was getting included the following.
Multiple browser instances would be opened when I started the application in debug mode within Visual Studio.
I sometimes got an error in the browser saying that the application could not be loaded.
Visual Studio would automatically detach from the browser and drop out of debug mode.
Turning off the Silverlight debugger (see the Web tab in the properties dialog for the web project) seemed to result in less of the other problems. This did however mean that I could not debug Silverlight code.
To resolve these issues, I right clicked on an aspx file in the solution explorer and selected 'Browse With...' to open the following dialog.
Note that there are two entries for 'Internet Explorer'.
I removed both (I set Firefox as the default temporarily to do so), cancelled out of the dialog and then reopened it. At this point, a new entry for 'Internet Explorer' had been added back in automatically. I made this the default and then had no further issues.
I had the same with VS2012..
Looks like Visual studio got confused which IE to use - somehow in system I hade two instances of IE as target browser (In VS2012 window called "Browse With..")
I removed all IE's from VS targets and restarted VS. Then only one instance of IE appeared after and debugger attaches normally.
I had a similar problem after opening a Silverlight-based application in two instances of IE10 at the same time. I could not debug. After which, I had switched between Chrome and IE10 in order to try and solve the problem. I could debug in Chrome but not IE10. But Chrome was cumbersome to run for debugging purposes.
Ultimately, I had to remove all the temporary files associated with VS builds in a three places:
C:\Users\brchase\AppData\Local
C:\Windows\Microsoft.NET\Framework\v4.0.30319
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
As well, I had to do a complete clean on the project and shut down IISExpress.
Also, I did a Tools /Delete Browsing History in IE10.
The above worked and I could debug again in IE10 -- even with multiple instances running.
Using Winserver 2008R2, VS2012 or VS2010. Latest version of FireFox does not hit SilverLight breakpoints. Tim Heurs solution at http://timheuer.com/blog/archive/2010/08/16/enable-silverlight-debugging-in-firefox-visual-studio.aspx does not apply as the required line is not in the FireFox config. My fix was to go back to IE9 (My IE10 was broken so I can't say for sure IE10 doesn't work)
Tried all of these suggestions.
Finally had to remove and re-install VS 2012 (which isn't straight forward anymore because after Oct 2013 some of the certificates had expired). Yay Microsoft!
So after re-installing I still had to go into the "Browse To" and switch it from IE to another choice then back to IE and it magically works now..
I think it was because Internet Explorer updated itself and left VS confused..
When trying to debug a Silverlight 4 application in Visual Studio 2010 with Firefox as my browser, I am unable to hit any breakpoints. I get the message "breakpoint will not currently be hit".
Here is the solution that worked for me when debugging was not working in Firefox:
Type "about:config" into the address bar of Firefox
Find the property named "dom.ipc.plugins.enabled"
Change the value from true to false by double clicking
Restart all Firefox browsers
Go back to Visual Studio and start debugging!
Hope this saves someone else some time!
Firefox hosts silverlight (and other plugins) in a sandboxed process called plugin-helper.exe.
Manually attach your debugger to the correct instance of this (it'll have "Silverlight" in the process type field), and you get your debugging back, and you get to keep your plugin sandboxing too.
EDIT:
Looks like someone else sick of doing this by hand and wrote an VS2010 addon to automatically attach to plugin-helper.exe.
I've created some automated tests using WatiN and MBunit and they run fine on my machine (running Windows 7 and VS 2010).
However, when I try running them on a virtual machine which is running Windows Server R2 2008 and IE8 my tests consistently timeout unless I am clicking into the window periodically.
IE is not in protected mode. Also each time a browser is launched the WatiN "BringToFront" method is called, but it doesn't seem to actually bring the browser to the front, it always opens behind Visual Studio 2010.
Looks like this is caused by two things, one is an IE8 bug, the workaround is to open Tools-> Internet Options -> Advanced and un-check "Show Pictures"
The other fix is to open Regedit, in the folder tree navigate to HKEY_CURRENT_USER\Control Panel\Desktop. Change the ForegroundFlashCount to 0, then log off and on again. (this fix is a per-user setting, so each testing user will need to do the fix)