Open webxl opened 7 years ago
I forked the project and added the ability launch and debug with XSP. The commit is here if it's useful for anyone:
https://github.com/adamhartford/vscode-mono-debug/commit/8d46a5fac1a3cb0901f161c2dd82b0c23b4feb8c
One thing I haven't figured out: When XSP is running and you change a cshtml razor view file, you won't see the change until you start/stop the server. However, if you run VS Code as root, you will in fact see the change immediately after saving without the need for a server restart. I've also seen this same behavior when manually running XSP as root and attaching in VS Code.
I'd like to know how to get XSP to recompile razor views when they're saved without having to run as root. My guess is that Mono has some file watcher processes that runs, similar to ASP.NET's File Change Notification, that doesn't have permission to watch the views folder or write new DLLs to the aspnet temp folder. I have no idea how that works though.
Adam any progress with this? I am having exactly the same issue using JetBrains Rider and ASP.NET MVC projects in not seeing the razor view changes. Strangely my colleague doesn't seem to have the issue despite what appears to be exactly the same setup (though we must be missing something).
Yes, actually. The main trick is to set MONO_MANAGED_WATCHER="y"
. For example:
MONO_MANAGED_WATCHER="y" MONO_OPTIONS="--debug --debugger-agent=transport=dt_socket,server=y,suspend=n,setpgid=y,address=127.0.0.1:55555" MONO_ASPNET_WEBCONFIG_CACHESIZE="2000" xsp4 --address 127.0.0.1 --port 5555 --nonstop &
The mono implementation of the file watcher doesn't hit the permission issues we see and doesn't require running anything as root. Razor views are recompiled as you'd expect.
After discovering this, I was able to come up with a VS Code workflow that's good enough that I use it exclusively now for ASP.NET development without needing to fork this project for anything. Give me an hour or so and I'll upload a sample project GitHub that shows my entire VS Code setup. I think it might be helpful for others to see.
Thanks so much - I had MONO_MANAGED_WATCHER=disabled in my bash_profile (whereas my colleague didn't. I have removed that and now view changes are reflected without a rebuild required.
You're welcome. For anyone using VS Code and vscode-mono-debug for Mono + XSP, here's an example project that shows how I do it. I'd love to know if there are better ways, but this has been working pretty well for me for a while now:
This has worked for me:
launch.json
{
"preLaunchTask": "build",
"name": "Launch",
"program": "/usr/lib/mono/4.5/xsp4.exe",
"cwd": "${workspaceRoot}/LimsWeb/src",
"args": [
"--port=62043",
"--nonstop",
"--verbose",
"--printlog",
"--loglevels=Standard"
]
},
tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "msbuild",
"args": [
"/t:Build",
"/p:Configuration=Debug;Platform=Any CPU;GenerateFullPaths=true"
],
"group": "build",
"presentation": {
"showReuseMessage": false,
"clear": true
},
"problemMatcher": "$msCompile"
}
]
}
Hi, I had trouble debugging an ASP.NET 4.5 web app earlier. Normally Xamarin or VS4Mac would suffice, but I need two debuggers going at once. The VSCode debugger was attaching, and I saw threads in the lower left, but it never paused at my breakpoints. I finally realized that I had disabled debug symbols and that was the reason why the breakpoints weren't being hit. Silly mistake, but I feel more docs are needed for this particular use case.
I figured out how to start my (Nancy) app like this:
Strange behaviors I encountered (these might be more to do with mono and/or Nancy framework):
Adding
,suspend=n
to the debugger options seems like the only way I could make it hit breakpoints.Sometimes it seems to work better if the root is set to the full project folder path.
In order for it to actually hit the breakpoints though, I need to hit a route on the app before I attach the debugger. This is the case on both mono 4.6.2 & 4.8.0.
Please let me know if you have any ideas about these issues, or if you need help with docs.
BTW, a month or two ago I forked this project and started a 'mono-xsp' debugger/launcher to try to eliminate the need for setting specific MONO_OPTIONS, but I couldn't figure out how to address/fix these problems. If anyone else sees the need for the launcher, I can forge ahead.