I'm developing a Powershell module in C#, in Visual Studio 2017.
I am a bit surprised that the developing-experience is so bad in terms of running and debugging so I'm trying my luck here.
The way it works for me now is as follows:
Implement the module
Compile
Start a new Powershell window
Navigate to the bin/debug folder
import the compiled DLL (import-module)
Run the commands
Close the Powershell window (as otherwise I cannot rebuild the project as the DLL file is locked)
Fix bugs, and go back to step #2
In case I need to debug the code, I use VS2017 attach to process and debug the code (after step #5).
That is not ideal in terms of DX and I would like to have something better, as close as to this:
Implement the module
Compile
Press F5 (start)
Powershell window opens up with the module loaded
Run the commands
Breakpoints hit pause the program like we used to
How do I achieve that?
I managed to get this work with help of above comment from #Glenn:
Start your debugging with external program
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
and the parameter line
-NoExit -command "Import-Module '<path to your module>'; "
With this you can now start with F5 -> get a powershell window with your already loaded module and the Debugger is attached to this process.
But you have to be careful if your binary module is written to target .NET Standard. In this case it seems that the debugger (VS2017 15.8.9) is not able to detect which run-time modules to load. So no breakpoints hit at all in this scenario! My quick workaround here was to add another project with Console App targeting .NET framework 4.xy and use this other project as start project with above settings. Now my workflow exactly mirrors your second sequence (1-6). Unloading the dll is no issue because stop debugging does end the process.
Related
I have two VS solutions. Solution A_sol is C++/C# projects. Solution B_sol has project B_proj that is C# wrapper around C++ *.dll generated by B_proj project in A_sol.
How do I debug A_proj from B_proj ?
UPDATE: one of the projects in B_sol is an executable.
How do I debug A_proj from B_proj ?
If I understood you correctly, A_proj is a C++ project. Below I will give my advice based on this assumption.
Note that it doesn't really matter from which project/solution you start debugging as long as you have the debug info (in other words, for C++ projects - if Visual Studio is able to pick up PDB's).
So you may either run your executable from the solution, or, as suggested by #hoodaticus in his answer, attach to the process which is already running. Whether your project is executable or not, you will be able to attach to it as long as:
DLL is loaded into that process
You have the PDB file that matches the DLL (generated during the build)
So I'll just repeat the same advice
In the other project, do Debug > Attach to Process > pick your process
from the list.
but I'll add that you have to pay attention to select "Debug these code types -> Native" for the process that contains your C++ dll. This part is often missed and confuses people, taking some time to discover (personally, I often get into it)
Hope that helps.
Run the process you want to debug outside the debugger.
In the other project, do Debug > Attach to Process > pick your process from the list.
To be able to debug by pressing F5 (rather than having to pick your process each time),
Right-click the startup project (the EXE) and choose Properties
In the Debug tab, select Enable native code debugging
The above steps are from this tutorial: https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-managed-and-native-code?view=vs-2019
I am running the HelloMvc sample application from the command line using k web. I have tried to run it using the different environments available to me using kvm use -runtime. When I change the controller and hit F5 (or Ctrl+F5) in the browser, the code is not recompiled automatically and the page does not change. What am I doing wrong?
Active Version Runtime Architecture
------ ------- ------- ------------
1.0.0-alpha3 svr50 x86
1.0.0-alpha3 svrc50 x86
1.0.0-alpha4 CLR x86
* 1.0.0-alpha4 CoreCLR x86
Running dnx web from your command line only starts your host. To get the automatic recompilation goodness something needs to watch the files for changes and restart your host if any changes are detected. To accomplish this use the --watch flag and run your web command like this:
dnx --watch web
Currently this just shuts down your host when a change is detected, so you need something that restarts it once that happens. IISExpress does this for you if you run your project from Visual Studio 14.
Your best bet for this workflow outside of Visual Studio is through a JavaScript build tool or npm scripts. I would recommend you to look into this gulp-aspnet-k plugin (note this plugin only works on windows currently) if you want continuous recompilation on file changes while working outside of VS14. Seems to be the best way to accomplish that without IISExpress that I have found. This plugin is/was windows specific, but looking at the code should get you started. :)
Glenn F. Henriksen has written a wrapper for nodemon that is very nice, called kmon. Try that out as well. The kmon GitHub repository has all the instructions you need
Based on the gulp plugin linked to by AndersNS, there's a bit of powershell you can use to automatically restart the application:
#powershell -NoProfile -ExecutionPolicy unrestricted -Command "for(;;) { Write-Output \"Starting...\"; k --watch web }"
If you stick this into a batch file (e.g. run.cmd) you can easily start the application, keep it running and automatically restart and rebuild on file changes.
Make sure you adjust the k command line if you want to use another target than web.
I'm writing a .dll using Monodevelop on Linux that is run by an application, and I have no control over how or when my code is called, but I would like to debug that DLL.
How can I make Monodevelop's debugger attach to that DLL when a chosen method is run in the DLL ?
Alternatively, I thought about starting the debugger from the code itself (i.e. "from now on, please debug me").
The DLL I'm writing contains a xbuild task that throws and obscure exception when run using xbuild (but the code runs fine if I call it from main), so if there's any way to debug custom xbuild tasks, I'm interested in that too.
Open your library project options
On left side go to Build->Output
Output path: set to path where external application will load your dll
On left side go to Run->Custom Commands
In dropdown box with text (Select a project operation) change to "Execute"
In Command textbox set to external executable that loads your dll
Now you can right click on your library project in SoltuionPad and set "Set As Startup Project"
I have a project in c# which uses bindings to use some c++ code. The c++ code consists of multiple DLL's which are compiled using a makefile. Currently I'm trying to run the makefile using a pre build event which calls nmake. However to get it to find nmake I need to have a line in it like the following:
"$(DevEnvDir)..\..\VC\vcvarsall.bat"
Also, even with that line present, nmake doesn't produce any output at all in the output window. Neither does it throw any errors. I tried redirecting the output to a file and it doesn't write anything. I have reproduced all steps in my pre build event in a normal shell and it works fine. I figure I must be missing something. Why doesn't Visual Studio give me a Visual Studio shell for my pre build event? Is there a better way to run this makefile? If not, has anyone got any ideas as to why nmake isn't producing any output?
EDIT: D'oh! nmake wasn't running as I forgot to add 'call' to the start of the line, i.e:
call "$(DevEnvDir)..\..\VC\vcvarsall.bat"
I often build non VS-project (sometimes with nmake, sometimes with other build tools) as a part of a larger solution build.
I tend to make a simple batch file, which sets up the environment and then runs the make.
I call the batch file from a build event (often post-build on my stuff) - usually with a CD on the front:
cd ..\.. && armbuild
Never (that I can remember, anyway) had any problem with the output appearing in the console window.
I have a C# Service that is calling a C DLL that was originally written in VC6.
There is a bug in the DLL which I am trying to inspect.
After having a nightmare trying to get debug to work I eventually added the dll to the VS2005 solution containing the C# Service and added the necessary _CRT_SECURE_NO_WARNINGS.
The debug version of the service is registered using 'installutil.exe' tool.
I can get the debugger to break just before the line where the dll is entered via a call to System.Diagnostics.Debugger.Break();.
I found some instruction on the net regarding stepping into debugging unmanaged code, and enabled the 'Enable unmanaged code debugging' check box, I've also tried turning on the Options->Debugging->Native 'Load DLL exports' and 'Enable RPC Debugging' (even though it's not COM). I've also copied the debug dll and .pdb to the same bin directory as the service.
However the unmanaged code is not being stepped into which is what I really need.
UPDATE: I found the Debugging Type in the DLL properties and set it to 'Mixed' as per suggestion on several sites but to no avail.
UPDATE2: My project now emits the debug dll and the pdb to the same directory as the debug service. Still unable to debug the dll.
Try setting the unmanaged code as the startup project. I know it doesn't make sense but I remember this working for a very similar project.
Since the DLL doesn't have an associated executable, when you try to run it will pop up asking what app to run. Browse to your C# app and then you should be good to go.
Happy debugging!
EDIT: it's been a while, but I think the debugging type Mixed is correct
In the end I created a console app and recreated all the prior calls just to make sure the call would act as it did in the actual service with the actual parameters once it got there.
I chronicled my fix and the resultant code at my site.
There is a workaround in Visual Studio 2013. Run the application from cmd line. When System.Diagnostics.Debugger.Break(); is hit, a Visual Studio Just-In-Time Debugger window should pop out. Check "Manually choose the debugging engines.", click "Yes" and ensure that "Native" engine is checked. Click "OK". Now you should be able to step into the native code as if you would by running the code from within VS.