-
Notifications
You must be signed in to change notification settings - Fork 676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support debugging full-framework (aka Desktop) .NET on Windows #813
Comments
Correct, we do not support debugging non-.NET Core projects in VS Code. As we have thus far at least, aimed the VS Code feature set as those that are portable across platforms. For desktop .NET scenarios, I would suggest using Visual Studio. |
Dam, my Visual Studio install isn't working properly (corporate anti virus problems) but VS code is working like a dream (minus the debugging problem). Anyway thanks for the response. |
Can I clarify this scenario... I'm running Asp.Net Core targeting full-framework, confirming that the debugger won't work (am getting a 'no symbols loaded error, I've configured Perhaps worth another ticket, but perhaps a better error message is applicable. |
@ctolkien I am assuming the only message you get is just a very generic one about the process exiting without CoreCLR loading? Or are you getting something else? |
2 similar comments
@ctolkien I am assuming the only message you get is just a very generic one about the process exiting without CoreCLR loading? Or are you getting something else? |
@ctolkien I am assuming the only message you get is just a very generic one about the process exiting without CoreCLR loading? Or are you getting something else? |
@gregg-miskelly no the error message is just "no symbols loaded". Debugging "starts", but no breakpoints are hit. |
@ctolkien I think you are talking about a message on a breakpoint. Correct? |
@gregg-miskelly The process starts and runs just fine from what I can tell? |
Do you see any module loads in the output window? |
Nope. |
That is what I thought. There isn't much we can do in this situation. The only thing that we could maybe do is have the breakpoint status say something like "CoreCLR hasn't started yet" instead of the more generic symbols load message. But we can't tell if CoreCLR hasn't loaded because it will in the future, you are debugging the wrong process, or, like in this case, you are trying to debug a full-framework app. |
Just to count I'd like to see vscode debugging full-framework and older versions of .NET too. =) |
#1390 enables Desktop CLR support. Documentation for this will be available later. In order to use Desktop CLR, the application to debug must be 64 bit and uses portable-PDBs. To enable the Desktop CLR debugger, change the configuration type in launch.json to be "clr" instead of "coreclr" and program should be pointing at the exe. "program:": "/path/to/program.exe",
"type": "clr" |
@WardenGnaw thanks! When will this feature be released? |
Sorry, I didn't realize it was already released... I just had to update the C# extension. |
I'm unable to debug TypeScript files in a ASPNET project. C# files breakpoint work fine, but I'm getting the message that symbols haven't been loaded on breakpoints in .tsx files. |
@dfdumaresq this extension only supports debugging .NET Code. For debugging client side script you would want to use either another extension (ex: there is a VS Code extension from Chrome debugging) or the built-in browser tools. Note that VS Code doesn't support debugging both the server side and client side code at the same time in the same instance of VS Code. So if you are using VS Code as your client side script debugger you will either need to switch back and forth, or use two different instances of VS Code. |
Thanks for the quick reply. I've added the Chrome extension and am checking the docs on setting up launch.json. |
Ok, I've read the docs and need to debug both server and client side code and therefore need to launch two instances of VS Code. When I try to open VS Code from the same workspace root, I cannot open a separate launch.json. So I've started the first instance to run the server code, it is running (if I'm using the correct terms) the extension type "coreclr". So, from VS Code, I now open a New Window and in the second instance open the folder from the webroot, and it runs the extension type "chrome". However, the webroot only contains the minified js files, so I cannot see my .tsx files and I get the console message: "Download the React DevTools for a better development experience: https://fb.me/react-devtools If I open the Chrome inspector, I can see all the files and de-minified JS. Am I on the right track or completely in the wrong train-yard? |
Hi there, I am now getting breakpoints working in my .tsx files as mentioned above. The trick I was missing was to put the launch.json under my ClientApp folder which contains all the client side files and keeps the two VS Code instances of launch.json separated. |
This worked for me , thx!!! |
VSCode Version: 1.6
OS Version: Windows 7
Steps to Reproduce:
Create a Asp.Net MVC or WebForms App.
Try to attach Visual Studio Code to IIS for debugging purposes.
Don't see any real option to debug...
Environment data
dotnet --info
output:.NET Command Line Tools (1.0.0-preview2-003133)
Product Information:
Version: 1.0.0-preview2-003133
Commit SHA-1 hash: 74df06500c
Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64
VS Code version: Version: 1.6
C# Extension version: 1.4.1
Steps to reproduce
Create a Asp.Net MVC or WebForms App.
Try to attach Visual Studio Code to IIS for debugging purposes.
Expected behavior
Should be able to attach to IIS to allow debugging.
Actual behavior
Don't see any real option to debug...
The text was updated successfully, but these errors were encountered: