I am currently in the dilemma of trying to attach the debugger of Visual studio to a IronPython process.
I have a c# dll that i reference and use in a python scripts, via Ironpython (import clr).
In my c# program i call this python script, again via the IronPython setup.
C# Code to run Python Scripts and its class method
Steps I have done:
So far from the research done into this subject I have figured out that you need to add the options dictionary (as seen in the code) and also disable (Just my code) in the debug options. This should allow one to set a breakpoint in the python scripts which visual studio then can hit. Now this does not work for me in both vs 2019 / vs 2022. Only vs 2017 managed to hit these breakpoints. When I run it with debugger the breakpoints simply say
(The breakpoint will not currently be hit. No symbols have been loaded for this document)
Again from the research done it looks like the fault is that vs 2019 and 2022 do not support the python version that IronPython uses and as such I am slowly giving up on. The overall goal with my project is simply to try to make the debugger work.
Question:
Is there maybe still a way to attach visual studios debugger to a IronPython process and debug the .py file??
PS: I tried both ironPython 2.7 and 3.4.1 alpha
You could add the following code in your script:
import clr
import System
System.Diagnostics.Debugger.Break()
Then run your host .NET application under Visual Studio debugger, then run the script.
The script execution should stop in Visual Studio debugger, where you will be able to step, evaluate, etc.
Also note that IronPython supports standard python tracing mechanism (i.e. settrace). With this, you could implement a custom debugger/tracer for your scripts. For example, we made such an IronPython script debugger as a part of our product called AlterNET Studio.
Related
I have a runtime written in C++ (with Mono embedded) which calls functions in a dll written in C# using mono_jit_exec and mono_runtime_invoke. The glue code is generated with CppSharp - which I don't think is relevant here, but just to mention.
So far all good, I can communicate in both directions.
What I want now is to debug the C# code only, using Visual Studio (I'm using the version 2019 on macOS). So in my C# project, I went to Run Configuration and selected the Start external program option pointing to my C++ assembly. After that, I've set some breakpoints, but when I run the C# project in Debug mode, they're never triggered.
Why is not working - is there something else that needs to be done? Is it because Mono is involved?
Ok, so the answer is that is currently not supported.
A workaround would be to do remote debugging using a plugin for Visual Studio or Visual Studio Code, as Unity does.
One available extension is VS Code Mono Debug, which is based on the SDB: Mono Soft Debugger Client.
I am able to call C# methods successfully from Robot Framework using IronPython however I am facing few runtime errors on the C# side which I want to debug using Visual Studio. Is there a way to debug C# application using Visual Studio when its method invoked through external program/script?
I have configured my C# project in Visual Studio using Start External Program (provided the robot executable path and arguments as required by external program). When I started debugging then my external program executes as expected with C# methods also executed successfully. However breakpoints which I have set in the Visual Studio doesn't get hit.
Is there any specifics I am missing while using Start External Program? My python script (external program) is importing DLL from same location where it’s getting generated while building C# project. PDB files also available in the same folder as DLL.
For me breakpoints was not hitting because I haven't attached the correct process. Let me explain in detail for other users to understand the root cause.
As I mentioned in my question that I was calling C# methods from Robot Framework using IronPython. Therefore I had used robot.exe (Robot Framework executable) as my external program (in the Visual Studio) and I expect my breakpoints to be hit under C# project. However the issue was that C# method executed by ipy.exe (Iron Python) not by robot.exe. It looks like Robot Framework starts ipy.exe process internally and then ipy process invokes C# methods. That means I should have attached ipy.exe process to my C# project so that control will come to Visual Studio whenever breakpoints hit.
To achieve the same I have done the following. I have inserted Debug.Assert at start of my C# code to halt the execution. Now I have started my external program (Robot Framework Test Case) and then during execution, Message Box appears due to Debug.Assert statement in the C# project. At this moment I have attached the ipy.exe(Iron Python) process to my C# project using Visual Studio using Debug --> Attach to Process. Afterwards when I went ahead with code execution by ignoring the message box then control comes to the breakpoints in the Visual Studio.
Just spent hours pulling my hair trying to work out why my ssis Script Component was not breaking into debugger on hitting a breakpoint.
I searched the web and fund 64 bit setting (Project -> Properies -> Debugging) to be turned off but it didn't help me.
It turns out that if I use string interpolation ( $"{someVar}" ) in my code then debugger does not start.
Once I replaced it with the old string.Format("{0}...", param1, ...) method my breakpoints got hit and I could step through the code.
The code works either way and it is just the debugger that is affected by the newer syntax.
I hope this helps someone.
Indeed, limiting C# Script Tasks to language features of C# 4.0 brings the Debugger back to life. In my case, adding a single null-coalescing operator caused the debugger issue using Visual Studio 2015 (VSTA) on SQL Server/SSIS 2016.
To restrict the Script to C# 4.0 we can enforce a specific Language Level in the Build settings of the Task:
Open the Script Task in question, click the "Edit Script..." button to open Visual Studio (VSTA).
In the Solution Explorer right-click the Project node and select Properties
In the Project window, go the Build tab, scroll down and click the Advanced.. button.
In the Advanced Build Settings window change the Langauge Version from "default" to "C# 4.0".
Clean/Rebuild the Script Task, fix compilation errors.
Finally, exit VSTA, rebuild the project
and then you should be able to debug the C# Script Task again.
Also spent hours pulling my hair out and found out it is indeed due to new Roslyn compiler features not being recognised in older versions of Visual Studio. (I am using VS2015 with an SSIS Script Task)
To get the breakpoints to hit, I opened project in earlier version of VS (2012) and made changes to source code to get it to compile successfully. Once i got it to build i ran in 2012 and voilà! - it hits all the breakpoints. Re-opened project and ran in VS2015 and confirmed it works as intended.
Spent hours too and then finally found your post... thank you sir!
I'm using VS2015 with SSIS Script Task too. For me it was the function nameof() that was responsible for not firing up the debugger. Replacing the function with reflection worked for me: Get string name of property using reflection
I'd like to think the above has cured my issue, but there was another cause/work around that I needed to implement to get script task debugging working again.
In my instance, the issue was the debugger integration used by Resharper, as highlighted by user "Richard T. LaSalle" in the linked solution to the following issue: Could not set BreakPoint in SSIS ScriptTask
TL;DR, If using Resharper, turn off Debugger Integration
Microsoft released an update v3.2 of SQL Server Integration Services Projects where it resolves the issue with Roslyn and other C# language features introduced after .Net 4.5. C# features.
Bad news - this fix is for Visual Studio 2019 only, you have to upgrade your VS to use it.
I am running VS Code on Ubuntu 14.04. I am trying to run a C# web application which my team can run just fine in Visual Studio on Windows. The problem is that Code gives me an error message, "/app.js does not exist". No such file exists in our project, and I think I want to run it using "Startup.cs" instead, but despite trying to change the 'launch.json' file accordingly, another file that my team does not have, I still cannot get my project to run. Has anyone experienced a similar problem?
The .NET environment for Linux is currently in a pretty early state. Thus you can't do everything on Linux that you can enjoy on Windows.
If you want to develop an ASP.NET application then you should read this guide on how to setup the environment to work with Visual Studio Code.
If you have a C# application that can already be compiled and run on Linux then you can
create a script file which compiles the project and runs it afterwards
and let this script be executed as the build task in Visual Studio Code. Here is how to do it: How to prepare/configure development environment for C++ projects in Visual Code Editor?
Just for your interest: You can't currently debug C# projects in Visual Studio Code.
Perhaps you can try to open the project with Monodevelop? This is an open source IDE for C# that runs on linux. It is compatible with VS projects.
You will probably need to also install Mono (the open source .net runtime) to run Monodevelop.
You may even be able to run your web app with the Mono runtime, although it has been always a bit behind the official Microsoft .net runtime (you may get 'class not found' exceptions if your code uses libraries that are not yet implemented in the Mono runtime).
My setup:
Application.exe (Visual Studio 6.0 C++)
Component.dll (Visual Studio 2010 C#)
Application.exe uses Component.dll
I want to be able to debug my Visual Studio 6.0 C++ application and the Visual Studio 2010 C# component that it uses at the same time but I'm not sure if this is possible or not.
I tried to launch the application from Visual Studio 6.0 and attach to that process (Application.exe) in my Visual Studio 2010 component solution but when I go to attach to the process (Application.exe) it is greyed out. I tried switching the Attach To: to Native but this does not allow me to attach to this process. My Application.exe is still greyed out in the window.
Is it possible to do this and if so how?
There can be only one debugger attached to a process, that's why the selection is grayed out. You have little use for the VS6 debugger, it doesn't know anything about managed code. You'll have to debug this from VS2010. Right-click your C# project, Properties, Debug. Select "Start external program" and select your C++ .exe. Tick the "Enable unmanaged code debugging option".
Set a breakpoint in your C# code and press F5 to start the .exe. The breakpoint indicator will turn solid as soon as the C++ code loads you DLL. Debugging the C++ code might be possible too although you're working with a .pdb from the previous century. You cannot single-step from the managed code into the C++ code, you have to set a breakpoint.
You cannot attach two different debuggers to the same process.
Instead, you can attach it only to VS2010, but attach it as both managed and native.