I'm working with a Silverlight 3 app and using Chrome as my test browser. While debugging I keep getting the popup message:
Plug-in Unresponsive
The following plug-in is unresponsive:
Unknown Would you like to stop i?
Yes/No
How can I turn this off in Chrome? Can VS be set to shut it off only when debugging? It's a real pain when debugging.
Thanks,
Add --disable-hang-monitor to chrome shortcut
Nick - are you using Chrome early builds on the Mac? There are some known issues with Chrome/Silverlight that we are working through with the teams -- most scenarios work though. Is this something you can share so others may verify?
To be honest, I set IE9 as my default browser when debugging Silverlight and switch back to Chrome afterwards. Chrome doesn't seem to communicate to Visual Studio (or vice versa) so I can't get breakpoint and exception information when using Chrome.
Related
I'm currently developing a windows modern app using Foundation for Apps and cordova. The app crashes in many ways during navigation, sometimes even immediately after running it.
The crash is this one
And i can't manage to debug it in any way.
I've tried setting up a window.onerror and a WinJS.Application.onerror catch all function with no results. Apparently the crash happens at a lower level. I've also inspected the event viewer but no info are available.
What happens is apparently similar to this question: How to debug unhandled win32 exception in WinJS Win8 store app which is unfortunately unsolved.
What are my options here?
I had the same issue with Visual Studio 2015, Windows 10 and cordova 5.1.1 when I transfer the project to another dev environment. It only occurs at the Windows-x64 app build configuration for the local machine.
After successful building, the app window launches shortly and after that, the win32 exception like the screenshot from sPoz came up. It was reproducible every time.
I try to repair Visual Studio and also I checked the environment variable from my solution as it is described in this Microsoft Article. But I had no luck.
Nothing helped, but simply open the config.xml file and change the Windows Target Version from "Windows 10" to "Windows 8.1" solved the problem and I could run the app with no error:
After that I can turn back to "Windows 10" and everything is fine. This was reproducable on two dev machines.
I do not exactly know if the moved project was the source of the problem and maybe the rewritten config.xml triggers any rebuild mechanism.
Most likely you are hitting an issue related to DOM Ex WWAHost.exe error on Windows 8.1 (apparently fixed on Win10). There is a workaround that should work for most apps; before you click around and get the WWAHost.exe exception, close the DOM Explorer window. This should enable you to debug by hitting breakpoints, etc. If you need to use DOM Ex against a Windows target, you might need try debugging against a remote device (see Kenneth's suggestion here: Why is Cordova Windows 8 app causing an unhandled win32 exception occurred in wwahost.exe?)
What are you using to develop the app ? The Visual Studio Tools for Apache Cordova ? Or Cordova with CLI ?
If you are using the plugin, you must launch the generated WP project to debug. The debug of WP app is not supported currently with the plugin.
I was getting same error during development of cordova windows tablet application, using Visual Studio Enterprise 2015. So far, I was doing try to close DOM-Explorer and use breakpoints and javascript console. After that, while searching javascript intellisense issues with Visual Studio, I figured out that my problem was fixed. What I did to get rid of this problem is that:
Open Tools > Options
Select Text Editor > Javascript > Intellisense > References
Add following references ( angular.intellisense.js, domWeb.js, domWindows_8.1.js ).
I don't know what are the correct reference files, but with these 3 reference files added, my problem has been solved.
I'm creating a website using Angular.js and have primarily been building it using Chrome, but now I have gone to test some features in Safari (on OSX Mavericks, safari Version 7.0.1) and when I try to open the developer tools they keep crashing or are un responsive.
I have tried various methods of loading up the dev tools and none of them seem to work. For example, opening the dev tools by right clicking on an element and clicking inspect element doesn't work, and neither does opening the console via the Developer tab.
I have tried disabling extensions, but that had no effect.
If anyone has any ideas I would be extremely grateful!
So it looks like since safari has been upgraded to 7.0.2 this issue has been fixed. It seems that the devtools now work completely fine.
I'm a developer who does a lot of Silverlight work and I experience some frustrations from time to time with various browsers not playing nicely with Silverlight. Particularly, I've noticed that Firefox will frequently interact poorly with Silverlight and attack the plug-in for attempting to interact with the browser.
Specifically, I've seen various versions of Firefox crash when:
The user initiates an action that requires clipboard access and a standard Silverlight security dialog is supposed to display. Other browsers handle this just fine.
A Silverlight application asks the browser to display a messagebox to the user (I've since used custom Silverlight UI for this because Firefox just wasn't liking this)
Silverlight is being run in Firefox with GoToMeeting running
The plug-in takes a bit of time on an operation (much less of a tolerance than other browsers, but this is usually something I can do something about)
Quite a few other times for little reason in particular
What can I do as a developer to avoid these sorts of issues for users that run Firefox? What can I do to analyze the problem when the SL plugin crashes? I don't feel that telling people to use Chrome or IE is a viable solution, but there aren't a lot of resources available on catering SL apps to run well with Firefox.
The best thing you can you assuming you are fulfilling the requirements is to report these bugs. Although some of them sound more like Firefox bugs, like "Silverlight is being run in Firefox with GoToMeeting running".
Another workaround instead of asking your users to use another browser could be to encourage them to install the application as oob.
This is a known bug in Firefox, if you have dom.ipc.plugins.enabled set to false in Firefox. See bug 602502 in Bugzilla.
If you can, set it to true, and you should be just fine.
Does anyone know how to debug a Silverlight 2 app running in Google Chrome from Visual Studio? Even after making sure that Chrome is the debugging browser, breakpoints are still not being hit.
Have you tried attaching to Chrome manually? Tools > Attach to process?
Chrome isn't officially supported but there are hacks.
Here for example. Halo's comment may give you some help too.
You can have more than one browser running on your localhost.
1) Hit F5 to run debug. Probably opens IE or whatever your default is. F5 your way through the breakpoints until it's loaded. Leave this IE open.
2) Open your other browser, coping the localhost Url into the new browser and run it. New browser should hit the breakpoints.
This works with all browsers, and even emulators like BlackBerry emulators.
Attach to the process manually (Tools > Attach to process), but make sure to attach to the chrome process that lists its type as "Silverlight, ...". Its title should be blank.
If you see your application name in the title, it's because chrome has a separate process for the HTML form that your Silverlight app is in, and the html's title probably matches. Attaching to this process does not load the Silverlight assemblies.
I usually will start debugging the app in IE to make sure that the most recent changes are compiled and running, then launch chrome, clear its cache ('cause it likes to hang onto Silverlight data), paste in the url from IE, and then stop IE and attach to chrome. Extra steps, but worth not spending 3 hours to figure out you are looking at cached assemblies.
This is an issue with Visual Studio interacting with Chrome: http://code.google.com/p/chromium/issues/detail?id=45560. My guess is you need to wait for a Visual Studio patch, but I honestly wouldn't hold your breath. The majority of Silverlight developers just use IE or FF for debugging. (Apparently even FF has some issues now that they've sandboxed their plugins: http://timheuer.com/blog/archive/2010/08/16/enable-silverlight-debugging-in-firefox-visual-studio.aspx#20476). As much as I hate IE, it's really your best bet for debugging Silverlight apps.
Simply set SL app as startup prtoject instead of asp.net and press F5
Does anyone know if silverlight plugs into chrome, or when they plan to support it?
This guy have had partial success with silverlight in chrome, but it does not seem to be supported:
http://wildermuth.com/2008/09/02/Silverlight_2_and_Google_Chrome
From The Microsoft Silverlight Team in the silverlight forum:
Hello, currently we don't have plans
to support Chrome. We will support it
in the future if it gains enough
market share. Please understand, each
browser implements the plug-in model
differently, so it'll be a lot of
effort to officially support a browser
100%... By the way, IE 8 also runs
each tab in its own process. If a tab
crashes, other tabs will still work
fine.
UPDATE:
Jon Galloway has just posted instructions on how to get silverlight successfully running on Chrome here:
http://weblogs.asp.net/jgalloway/archive/2008/09/17/silverlight-on-chrome.aspx
The official word on what is supported looks like this:
alt text http://www.jesseliberty.com/sl/browsers.jpg
The reality is that we do run on a lot of browsers, but things change might quickly in these here parts.
For what it is worth, the Dev Branch of Google Chrome was recently updated to support Silverlight 2. I tried it and it works for me. Of course, you have to use the Dev release of Google Chrome. You can get more information about switching to Chrome Dev here.
Silverlight already works with web-kit, and since Google's Chrome is based on web-kit, it shouldn't be too much effort to get it working.
Indeed, this gentleman seems to have had some success.
Based on this, I would suspect that Silverlight will be fully supported by Chrome by the time it goes gold.