Skip to content
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

Closed
Dave3of5 opened this issue Oct 12, 2016 · 22 comments
Closed

Support debugging full-framework (aka Desktop) .NET on Windows #813

Dave3of5 opened this issue Oct 12, 2016 · 22 comments

Comments

@Dave3of5
Copy link

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...

@gregg-miskelly
Copy link
Contributor

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.

@Dave3of5
Copy link
Author

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.

@ctolkien
Copy link

ctolkien commented Oct 18, 2016

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 project.json to use portable pdb's')
Edit: OK, according to this, no it's not:
#776

Perhaps worth another ticket, but perhaps a better error message is applicable.

@gregg-miskelly
Copy link
Contributor

@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
@gregg-miskelly
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link

@gregg-miskelly no the error message is just "no symbols loaded". Debugging "starts", but no breakpoints are hit.

@gregg-miskelly
Copy link
Contributor

gregg-miskelly commented Oct 18, 2016

@ctolkien I think you are talking about a message on a breakpoint. Correct?
In the output window, I am assuming the only message is that the process exits without starting CoreCLR? (or I guess if you are stop debugging, you wouldn't even see that)

@ctolkien
Copy link

@gregg-miskelly The process starts and runs just fine from what I can tell?

@gregg-miskelly
Copy link
Contributor

gregg-miskelly commented Oct 18, 2016

Do you see any module loads in the output window?

@ctolkien
Copy link

Nope.

@gregg-miskelly
Copy link
Contributor

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.

@gregg-miskelly gregg-miskelly changed the title Debugging Legacy .Net Support debugging full-framework (aka Desktop) .NET Dec 15, 2016
@gregg-miskelly gregg-miskelly changed the title Support debugging full-framework (aka Desktop) .NET Support debugging full-framework (aka Desktop) .NET on Windows Dec 15, 2016
@dunebuddy
Copy link

Just to count I'd like to see vscode debugging full-framework and older versions of .NET too. =)
But I ask myself if it can't, maybe should, be achieved by an extension, just like other languanges do?

@WardenGnaw
Copy link
Contributor

#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"

@thomaslevesque
Copy link
Member

@WardenGnaw thanks! When will this feature be released?

@thomaslevesque
Copy link
Member

@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.

@dfdumaresq
Copy link

dfdumaresq commented Aug 17, 2017

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.
Is debugging supported for both types of files?
My launch.json
{
"version": "0.2.0",
"configurations": [{
"name": ".NET Core Launch (web)",
"type": "node",
"request": "launch",
"preLaunchTask": "build",
"program": "${workspaceRoot}/bin/Debug/netcoreapp1.1/EPBC.PSAS.dll",
"args": [],
"cwd": "${workspaceRoot}",
"stopAtEntry": false,
"internalConsoleOptions": "openOnSessionStart",
"launchBrowser": {
"enabled": false,
"args": "http://local.educationplannerbc.ca:8081/",
"windows": {
"command": "cmd.exe",
"args": "/C start ${auto-detect-url}"
},
"osx": {
"command": "open"
},
"linux": {
"command": "xdg-open"
}
},
"env": {
"ASPNETCORE_ENVIRONMENT": "local"
},
"sourceFileMap": {
"/Views": "${workspaceRoot}/Views"
}
}]
}

@gregg-miskelly
Copy link
Contributor

@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.

@dfdumaresq
Copy link

Thanks for the quick reply. I've added the Chrome extension and am checking the docs on setting up launch.json.

@dfdumaresq
Copy link

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
Warning: It looks like you're using a minified copy of the development build of React..."

If I open the Chrome inspector, I can see all the files and de-minified JS.
I'm using webpack and might need to pass an env param, but I'm not sure.

Am I on the right track or completely in the wrong train-yard?

@dfdumaresq
Copy link

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.

@theangel1
Copy link

#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"

This worked for me , thx!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants