I develop Excel tab-pane addin(office.js api) and use F12Chooser tool for debugging.
After upgrade Windows 10 to build 14342.1001 I can't run F12Chooser.exe from:
C:\Windows\SysWOW64\F12\F12Chooser.exe and C:\Windows\System32\F12\F12Chooser.exe
After double-click the mouse cursor quickly flashes and nothing happened. When try run from context menu in Excel web view still nothing happened.
(This is an old post so replying in case anyone else finds it usefull.)
You can file a bug/feedback on F12Chooser in the Feedback Hub (search for it in start). If you place it in the Microsoft Edge -> Developer Tools category it should get routed to the right people.
As a workaround if you have Visual Studio 2017 installed you can use that to attach the script debugger to any process from the attach to process menu (changing the debug engine to script). VS2017 has the same tools as F12 (e.g. the DOM Explorer and Console etc.).
Related
I created an Office Add-In using the Yeoman generator, I chose the React add-in and I was able to make it run properly within VS Code by following this tutorial:
https://learn.microsoft.com/en-us/office/dev/add-ins/tutorials/excel-tutorial
The react boilerplate includes a piece of code which logs an action to the console, but I see no console anywhere. According to the documentation, since my version of Office is 2016 volume licensed, I'm running Internet Explorer, and since my Windows system is 8.1, I can't use the F12 tools nor the Microsoft Office Add-In Debugger, so how do I view these logs like I do when I develop web applications for other browsers like Chrome and Firefox?
I followed the instructions in this guide by microsoft:
https://learn.microsoft.com/en-us/office/dev/add-ins/testing/debug-add-ins-using-f12-tools-ie
Now, for what I understood, the only option I'm left with is to "Switch to the Internet Explorer 11 webview". So I ran the command npx office-addin-dev-settings webview manifest.xml ie in the terminal and it returned "The web view type is set to Microsoft Internet Explorer". Then when I go ahead and type npm start, the add-in loads correctly but I still can't see any dev tools.
I did try something else by going to the Run and Debug tab in VS Code, choosing the option "Excel Desktop (Edge-Legacy)", running the command npx office-addin-dev-settings webview manifest.xml edge-legacy, modifying the launch.json file so it didn't complain but I saw no difference.
I was able to have bridge chrome and edge devtools using the IEDiagnosticsAdapter, but nothing appears in the console, so I think it's unsupported.
I'm using Visual Studio 2019 to develop a .NET Core 3 application which runs on embedded Linux. I am able to build the code in Visual Studio 2019. If I copy the binaries manually to the Linux machine and then start the application running there then I am able to attach the Visual Studio debugger to the remote process over SSH in Linux and debug the application. This does work, but it's tedious to deploy it, start it and attach the debugger manually for each debug session. I do have a script in Visual Studio Code which works, but I want to use Visual Studio Professional.
I'm trying to write a Visual Studio Extension so that I can press a key in Visual Studio to have the application built, deployed, started and then connected to the debugger. I would then share the extension with my team. It's very nearly working, except for attaching the debugger.
In the extension I am able to list the processes running in the Linux machine and select my application using this code:
EnvDTE100.Debugger5 debugger = (EnvDTE100.Debugger5)dte.Debugger;
EnvDTE80.Transport transport = debugger.Transports.Item("SSH");
EnvDTE80.Engine engine = transport.Engines.Item("Managed (.NET Core for Unix)");
EnvDTE80.Process2 process = (EnvDTE80.Process2)debugger.GetProcesses(transport, "192.168.11.1").Item("app");
process.Attach2(debugger);
There are two problems:
The call to GetProcesses() opens a dialog where I need to enter the Linux username and press enter, how can I specify the username in code to avoid the dialog appearing?
Even though the selected process looks like the right one (process.ProcessID matches what I see in Linux if I run the ps command), I get an exception when I call Attach2(). The exception message is "Exception from HRESULT: 0x8971001E"
I feel like I'm really close to getting this to work, any suggestions for how to finish it?
I also solved the second problem by changing the parameter passed to Attach2() from debugger to engine, as shown below:
EnvDTE100.Debugger5 debugger = (EnvDTE100.Debugger5)dte.Debugger;
EnvDTE80.Transport transport = debugger.Transports.Item("SSH");
EnvDTE80.Engine engine = transport.Engines.Item("Managed (.NET Core for Unix)");
EnvDTE80.Process2 process = (EnvDTE80.Process2)debugger.GetProcesses(transport, "root#192.168.11.1").Item("app");
process.Attach2(engine);
I found out how to add the user Name, but not the Password:
In GetProcess(), set transportQualifier to $"{userName}#{hostName}".
The 1st time the Window will still Pop up and ask for the Password.
But after that VisualStudio has stored the connection including the password.
I'm trying to debug a class library (PDM Add-in) using Explorer.exe for SOLIDWORKS PDM Professional. I'm on Windows 10. Explorer starts for a second and then something happens that shutdown the debugger.
This what I see in my debug tab.
onecoreuap\shell\windows.storage\sharedstoragesources\util.cpp(6571)\windows.storage.dll!76538288: (caller: 765382E5) ReturnHr(1) tid(c0c) 80004002 No such interface supported
pcshell\shell\appresolver\lib\pintostartcontextmenu.cpp(97)\appresolver.dll!7720C6F5: (caller: 7720DA4B) ReturnHr(1) tid(c0c) 8007007E The specified module could not be found.
onecoreuap\shell\windows.storage\sharedstoragesources\util.cpp(6571)\windows.storage.dll!76538288: (caller: 765382E5) ReturnHr(2) tid(c0c) 80004002 No such interface supported
CallContext:[\InvokeAssociatedProgram]
There is some sort of unhandled exception that gets thrown in Explorer by some stupid Microsoft extension. I think it's OneDrive. Since the debugger is attached to Explorer, it crashes because of this fatal error. The debugger doesn't catch the exception because the symbol file of the culprit code is not loaded. Actually, you can see something illuding to that in the output window In Visual Studio.
This didn't happen to me in Windows 7.
Solution 1
Use Notepad.exe to debug Solidworks PDM addins (This is already recommended by Solidworks API doc examples) but I don't really feel comfortable having to go To File > Open > Going to the vault (login) and setting the file filter to solidworks document types every time I start debugging. Moreover, Notepad OpenFileDialog dialog does not support multi-selection.
Solution 2
Use this console application I developed that invokes the OpenFileDialog dialog. The console app will:
Log you into the vault.
Uses the vault's path as the start up directory for the OpenFileDialog.
Sets the extension filter for SOLIDWORKS files
You can enable multiple-selection if you need it.
I am using Visual Studio Code for a javascript project. You can set breakpoints and step through and debug very easily the code that runs in nodejs. Is there any way to allow breakpoints and debugging for the client side, browser running code?
Debugging via console.log gets old real quick.
For debugging in Chrome there is the Visual Studio Code: Debugger for Chrome extension. You can find this extension in the marketplace, search for debugger as told in the debugging manual. Unfortunately there is (currently) no support for other browsers,
Debugging node.js works out of the box, see the debugging manual above or John Papa's blog post.
Debugging both client and server (as Phil commented) is not possible at least in my opinion since you need to have two different launch configurations, sorry.
You should use developer tools which all modern browses have (F12).
I prefer chrome because with workspaces and you can inline edit your code in browser.
By opening you project in chorme Browser and using chrome DevTools.
You can debug it whatever you want.
steps:
Open your project (with url).
Open DevTools (F12)
Choose the "Elements" and choose the Element
You can see "Event Listeners" on the right panel , Select what you needed
And then, You can right click the event you, Select "Show function defination"
Enjoy yourself !
If you means Debug Nodejs ,As I known there's A npm package named "debuger"?
Another technique is to use the Visual Studio Code: Debugger for Chrome extension. Save the contents of your launch.json config for node.js and delete it. Then create the Chrome launch.json. Combine the two and you can debug either the server or the client in Code (but not both at the same time).
To debug the client, the server must be running, so from a command prompt use the "node" command that starts the server. In Code launch the Chrome debugger and debug the client side.
After I installed Windows 8 perfectly legit statement like this doesn't work anymore:
#if DEBUG
Debugger.Launch();
#endif
Service starts ignoring that thing.
Yes, I am building the project in a debug mode.
if I change that to a Debugger.Break() - the service just fails, and still there's no dialog for attaching a debugger.
The secret lies in changing the registry key for the Visual Studio JIT debugger via the following:
reg add "HKCR\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}" /v AppIDFlags /t REG_DWORD /d 8 /f
Before making this change the value on my machine was 0x28. The above changes it to 0x8. In essence it removes the 0x20 flag.
If you search the Microsoft include files (WTypesbase.h) then you find the following:
#define APPIDREGFLAGS_IUSERVER_ACTIVATE_IN_CLIENT_SESSION_ONLY 0x20
Once you make this change then the JIT debugging window is displayed again. I believe that all of this relates to various session 0 security changes made by Microsoft.
Sourced from this post:
http://forums.arcgis.com/threads/69842-Debugging-your-SOE-on-Windows-8
Debugger.Launch would launch an application with a visual GUI. By default services do not interact with a desktop and thus anything they do cannot be "seen".
Support for interacting with the desktop has slowly been removed from Windows services ("Interact with the desktop" option has been removed from some Server versions for example). I would imagine they've continued this trend.
Windows Services by nature are not GUI applications, they can run before and after a user logs into a desktop and thus cannot show a GUI all the time. It's not generally a good idea to depend on an ability to have a GUI in a Service.
If what you want to do is debug a service, I suggest running it as a regular application so that you can do things like Launch and Debug. Shameless plug: you can see Developing Windows Services in Visual Studio for a way to write a service that supports that.
Is this a Windows Store app or a desktop app?
Try right-clicking on your project (the C# executable project if that's what you have) and selecting "Properties". Then in the left sidebar of options, click "Debug". In the "Start Action" section, check the box for "Do not launch, but debug my code when it starts".
Now you can hit F5 and run Visual Studio with breakpoints in your code, and it will sit and wait for you to fire up the process. Then run your application (outside of Visual Studio), and Visual Studio will attach the debugger.