Debugging dotnet core apps with the SAM CLI #568
Comments
|
Yaay! This is awesome! Sounds like a plan. I have a few questions:
Looking forward to working with you on this! |
|
Good to see someone else taking this up, here's some notes I've got from looking into this already.
The bootstrapper in the docker container loads the user's compiled function into memory and calls the handler method directly. The problem in a nutshell is that the actual process being executed is not the user's function, it's the bootstrapper. This might be work-aroundable by having users add a |
|
@austinlparker Awesome! thanks for clarifying. In nodejs debugging, when you start the debugger, it actually breaks at the bootstrap script. And when you hit Continue, it runs and hits the next breakpoint in your actual function. Would this be acceptable in dotnetcore too? I want to make the debugging experience as transparent as possible. |
It will work for Visual Studio 2017 & Visual Studio Code. Visual Studio 2015 only supports dotnet core 1.1 (project.json) and below, so I don't think we need to worry about it.
In the dotnet world (beyond just dotnet core), there are different build configurations. The defaults are Debug and Release. In the dotnet cli, this is set with the [-c|--configuration] parameter:
Yes!
Based on @austinlparker's answer, I don't think we should need to change the container. We should be able to handle this similar to the go implementation.
Also based on @austinlparker's answer, I don't think we'll have an answer until we begin work on this. Since there is a bootstrapper that runs our code within the container, we would be attaching the debugger to the bootstrapper's process and the bootstrapper would be treating our code almost like a class library (unless it's doing some reflection magic). In the past, I have been able to debug my own class libraries that are executed by a different project using Visual Studio 2017, but I'm not sure if this is the situation. |
|
@sanathkr I'm not sure if the same thing will happen with compiled languages. In order for VSDBG to debug, it needs the .pdbs (similar to Source Maps in front-end JS development) associated with the process it's trying to debug. When compiled in Debug mode, the .pdbs are embedded in the binary. In Release mode they are separate files. If we attach the debugger to the bootstrapper which is most likely compiled in Release mode, it may not break within the bootstrapper script. This is all speculation though until we actually try it. |
|
Yeah, ultimately I think someone will need to sit down and just hack on it for a bit to see how it works. I don’t know how much time I’ll have to really help other than answering questions and being a resource, but feel free to reach out on here or the Slack.
…Sent from my iPhone
On Jul 21, 2018, at 1:29 PM, Alex Burck ***@***.***> wrote:
Will this method of using vsdbg work across all Visual studio products?
It will work for Visual Studio 2017 & Visual Studio Code. Visual Studio 2015 only supports dotnet core 1.1 (project.json) and below, so I don't think we need to worry about it.
Does debugging require a change in the way function code is authored or compiled?
In the dotnet world (beyond just dotnet core), there are different build configurations. The defaults are Debug and Release. In the dotnet cli, this is set with the [-c|--configuration] parameter: dotnet build -c Debug.
For our purposes, the user should always be in Debug mode. I'm not sure what vscode does, but I know Visual Studio will popup an error message if you attempt to run the debugger in Release mode. That being said, it is possible to run the debugger in release mode by disabling justMyCode in the launch.json.
does this work for both dotnetcore 2.0 and 2.1?
Yes!
Would it require a change to the Docker container?
Based on @austinlparker's answer, I don't think we should need to change the container. We should be able to handle this similar to the go implementation.
Do you know if this requires a way in which the dotnetcore runtime is started?
Also based on @austinlparker's answer, I don't think we'll have an answer until we begin work on this. Since there is a bootstrapper that runs our code within the container, we would be attaching the debugger to the bootstrapper's process and the bootstrapper would be treating our code almost like a class library (unless it's doing some reflection magic). In the past, I have been able to debug my own class libraries that are executed by a different project using Visual Studio 2017, but I'm not sure if this is the situation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I'll give it a go sometime in the next couple days and let you all know what I find out. |
|
Sounds good! @burck1 Hit us up on #samdev Slack if you need more help :) |
Even if that is a workaround, I don't think we should put this on customers. The way I am thinking about this is, I am going to be writing my code in my IDE. At some point in time, I will run into some issue and need to jump into my debugger. Yes, I will need to run some command (Ideally, I shouldn't even have though) to start the container with a debug port, etc, but that should be it. I shouldn't have to remember to add another statement in my handler code or have extra code that isn't needed/executed while the function is deployed to the cloud. Honestly, I am not familiar with the dotnet world. This might not be a big deal but I think creating a streamlined experienced here will set this off on a good foot. |
|
Hi All, quick update. I got dotnet debugging working using the lambci/lambda:dotnetcore2.1 container image. For now I had to extend it to add in VSDBG. Check out my repo here for more info and to test it out yourself: |
|
This is awesome!! I glanced thru the run.ps1 file to understand how you did it. Looks straightforward. Looking forward to the PR! Let us know if we can help you in anyway |
|
Looks like the container and function is invoked outside of |
|
I am currently having issues with a dotnet core Lambda function that I am trying to debug, any ideas if this is going to make it to a release soon? I was looking at the work @burck1 did and it looks awesome. |
|
the work looks awesome in which release of sam cli will this be included? |
|
We have some initial designs but there are some blockers and we don’t have anyone driving this forward at the moment. We are looking for someone to help us drive this, to get this done sooner. |
|
@sanathkr What kind of help do you need? |
|
@sanathkr , I've started looking into the issue as well. I would provide the feedback if I have some more formed approach. |
|
I’ll update this issue with details by Monday. Excited to see interest in
this from the community!
…On Sat, Nov 3, 2018 at 6:14 PM, Dobrianskyi Nikita ***@***.***> wrote:
@sanathkr <https://github.com/sanathkr> , I've started looking into the
issue as well. I would provide the feedback if I have some more formed
approach.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#568 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADmJlnmtGu4c074BORj6YQjdCoP_ExOfks5urj-QgaJpZM4VZeBi>
.
|
|
@rschiefer @ndobryanskyy Thank you so much for offering to help. @thesriram already did some deep diving to come up with a checklist of work remaining. Between us, hopefully we should be able to standardize on an approach and start implementing. |
|
@sanathkr @thesriram , I'm glad to see, the work going on at this. I've done some deep research too. I suggest we sync at Monday and share the findings. |
|
Some thoughts on this. We need a way for The debugger that is used for debugging is called vsdbg. The debugger can be obtained by downloading it from the following link. The transport mechanism for the debugging session needs to be figured out, the options could be docker and ssh. Tasks I had envisioned for debugging to work are below.
Do let us know your thoughts and any steps that you had thought of. |
|
@thesriram Hi! I'd very glad if you take a look on it. I'll include the Readme.md with steps and thought process |
|
@ndobryanskyy woot! 🎆 💯 definitely! |
|
@thesriram , @sanathkr I've uploaded my POC to this repo. I'd appreciate if you check it out and say what do you think. I will document all my decisions and plans for integrating it into the CLI tomorrow, because it is midnight at my place now. At high level:
For me this approach seems pretty decent. The only thing we can still improve is auto continue of the program after attaching, I have some hack, but I need some more time to implement it properly (this is I don't have so much of the insights of the SAM CLI internals, but I hope it does pretty much the same as my POC code. I'm open for propositions and discussion- waiting for your feedback guys. EDIT: fixed commands for sh |
|
@ndobryanskyy This is awesome! Actually yours is much different than what we originally imagined. It aligns closely with what how SAM CLI already supports debugging for other languages.. |
|
@sanathkr as we discussed, I'm also happy to help on this as the design comes together. |
|
@sanathkr , I'm glad you liked the solution. I can now try and integrate it in the CLI itself. I'll fork the repo and implement initial design, similar to how the GO was added I think. But first, could you please answer those questions:
As for help, I would appreciate if someone experienced with the CLI will explain me the overall design to accelerate the onboarding, maybe you have some detailed docs, (especially for Windows 🐱👤). Apart from lack of knowledge of the product implementing the feature seems straightforward to me. @mikemorain maybe you can help with that? Also I'll work on explanations of the solution today. |
|
I've updated the detailed explanation section. I would appreciate if you look through it, ask questions (if any) and give feedback - I'm open for discussion and suggestions / improvements, as I now plan to start working with SAM CLI integration of this approach. |
|
@ndobryanskyy Sorry progress on this has been slow, the team has been focused on tasks at hand. This is awesome work!, going through explanation sections. I personally like the third option where we the supply the debugger path, because its the most flexible approach and we dont need to tamper with the image at all. Are you on the slack channel? #samdev . You should totally get on it! :) I think what we can do is to encapsulate all the work that is to be done as an issue, that clearly shows the tasks. (maybe as checkboxes or other issues). Then we can go through this implementation process by just finishing those tasks. Does that make sense? @sanathkr has a WIP PR: https://github.com/awslabs/aws-sam-cli/pull/738/files which talks about how we are to have a design doc for the features we do. I think this feature could be a pilot for that! |
|
@thesriram , no problem you had the release it is understandable and thanks for reading that "TL;DR" of mine 😅. I've submitted the request to be added to the slack channel, but no invitation yet 😔. Maybe you can streamline the process. I will go with third approach then, and am going to submit the PR with modified runner with debugging flag support to Docker lambda repo (check out the issue above). As for the docs you've mentioned, I like the idea, I can open up an issue and write down all of the required steps with checkboxes. I've already grasped how the CLI works, and now trying to make some draft with .net core debugging on SAM develop branch. Does this sound like a plan? |
|
I've filed PR with just the debugging support at docker-lamda (no |
|
@ndobryanskyy Nice work on the design section for this! I'm wondering if, for the long term, we can do a combination of 1 or 2 and 3. I think that would give the best UX overall, since it would be easy to get going quickly, but also provide the flexibility for the user to provide a separate debugger. I like the idea of making it incredibly easy out of the box, as it goes along with the theme of the CLI generally. With regard to the debugger attachment generally, I think we could also elect to use the System.Diagnostics.Debugger.IsAttached property to wait for the debugger and proceed once it's attached. It provides a slightly more stream-lined process than a Console.Read(). Thoughts? |
|
@mikemorain, thanks for the feedback I really do appreciate that, I am totally agreed with you, that the UX must be consistent and streamlined, so the second option with some plugin support maybe, could be the best, but again in the long run. Got to get some grooming on that, and take into the consideration all of the runtimes also, to he as consistent as possible. As for the waiting, have you checked my WIP: PR it now uses both the As some other thought we can actually communicate with VS Code C# extension team, and make some event like Maybe you have some other suggestions or so e debugger port listening socket kind of magic? |
|
@ndobryanskyy Ah, I had missed that in the PR; I was looking at the design document; nice work already putting that check in there. I'm wondering if, since to trigger this behavior, a specific flag or environment variable will need to be set, that putting in a waiting loop would be slightly smoother. Obviously not the biggest of deals, but might be a slightly better UX. And while I like the creativity of the your C# extension idea, I agree that it's probably not the most robust way to go forward :-D. Looking at the way that the Go integration is handled, delve seems to handle the waiting of execution until the remote debugger is attached to the server and says continue. Given that experience, I think it might be best to emulate the friction-free UX and have a loop that waits for attachment given the flag. I'm definitely open to counterpoints though! |
|
@mikemorain, well, I agree with you, that if it will all happen automatically, without user ever pressing any key, that would be considerably easier. In that case I suggest that we go like this:
It could be like What do you think? |
|
I prefer the infinite loop approach, without key press. When this is integrated with IDEs or other tools, then pressing key might not be an option. Also if you are hitting a local API, then you are seeing the browser window and wondering why it didn’t run. So I would just do a tight while loop, may be with a timeout of like 5minutes. |
|
@sanathkr yep, nice point about timeout! The user would be able to stop waiting either by pressing any key to "continue without debugging" or just a simple timeout. |
|
@sanathkr, small off-top (because I don't know the other place to ask this) how can I join the Slack channel, because I've sent the request like 5 days ago, and still no invite do I have to do anything else, to get it? |
|
@ndobryanskyy Can you send your preferred Slack email address to my email listed in my profile? https://github.com/sanathkr I will add you |
|
@ndobryanskyy I was suggesting removing the Press Any Key option altogether. It doesn't make sense because customers won't have direct access to the stdin of the Docker container inside which this code runs. Instead a plain infinite loop to wait for debugger to attach (with timeout) is the best idea IMO |
|
@sanathkr, I will send you my email, thanks! I will update the PR according to our discussion. Thank for the feedback @sanathkr, @mikemorain |
|
I think we could close this |
|
@ndobryanskyy sounds good. Do you want to open an issue for debugging support with Rider in a separate issue. (Think you covered this in your RFC) and then we can close this guy? |
|
@thesriram, no problem I will open issue for Rider support and issue on csharp VSCode today 👍 |
|
Closing this issue, another issue has been opened for explicit Rider support in .NET debugging. #855 |
Currently the sam cli does not yet support debugging the dotnet core 2.0/2.1 runtimes with vscode. After #565 / #281 has been merged (thanks @jfuss and @austinlparker), I think it should be pretty straightforward to add in debugging support. I've been using vscode for dotnet core + lambda development a lot recently and this feature would be be very useful.
The basic requirements to attach a remote debugger to dotnet core from the C# extension for vscode is outlined pretty well here: https://github.com/OmniSharp/omnisharp-vscode/wiki/Attaching-to-remote-processes. The main requirement is that VSDBG is setup within the container. It handles sending and receiving the debug adapter protocol messages to the remote debugger.
After that is setup, it's just a matter of configuring vscode's launch.json to use pipeTransport.
My plan would be to wait until #565 is merged before starting work on this. Thoughts?
(also related to #500)
The text was updated successfully, but these errors were encountered: