Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It's not possible, because of the design of the dot net virtual machine.</p> <p>Dot net code is managed, running in a virtual environment, not natively on the machine.</p> <p>Even if the Dot net code is compiled (whereas it could be interpreted), it's not directly compiled into a native Windows executable: it's compiled into CIL, then interpreted or converted into x86 op codes by the CLR, which op codes are run inside a virtual environment.</p> <p>This make it very reliable about security and allow some high-level tricks like RTTI or garbage-collection, but it's NOT a process like any other.</p> <p>So you can't just pass from your Delphi executable (which is a true Windows executable) into the DotNet code. You can do that with C or C++ code (if you have all the debugging information, and did compile it with Borland C++ builder), but you can't do that with DotNet code.</p> <p>You can try step by step debugging in the Delphi asm view (shortcut is Alt-F2), but you'll spend a lot of time in the mscoree.dll library, and you will never know which line of you DotNet program you're executing. I suspect you'll be like me: sinking in the asm code... we are humans, no x86!</p> <p>So to debug your application:</p> <ul> <li>add logging to both side (Delphi+DotNet)</li> <li>create a pure DotNet skeleton application, just big enough to call the DotNet code you want to test: this will allow you to debug your DotNet code</li> <li>even better, write automated tests: your DotNet code should be tested from DotNet side, with some regression tests - then it will integrate and work as expected when called from Delphi</li> </ul> <p>Last trick: if you want to make your DotNet code run under 64 bit OS without any problem, don't target your assemblies <a href="http://www.dottodotnet.com/2010/04/compiling-net-for-specific-target.html" rel="nofollow">to the right target</a>, because, when run from a Delphi application, it will be executed inside Wow64, since Delphi executables are still 32 bit.</p> <p><strong>EDIT: PERHAPS A SOLUTION</strong></p> <p>After some sleep, an idea came to me: in the Delphi IDE, you can attach a process to the debugging. Perhaps it could be possible to do the same with the Visual Studio IDE.</p> <p>And it sounds feasible: you can attach the Visual Studio debugger to any running process, via some menu of the IDE.</p> <blockquote> <p>The Visual Studio debugger has the ability to attach to a process that is running outside of Visual Studio. You can use this attach capability to do the following:</p> <ul> <li>Debug an application that was not created in Visual Studio.</li> <li>Debug multiple processes simultaneously. You can also debug multiple processes by starting multiple projects within a single solution.</li> <li>Debug a process running on a remote computer.</li> <li>Debug a DLL that runs in a separate process that cannot easily be started from Visual Studio, for example, a service or an ISAPI DLL running with Internet Information Services.</li> <li>Start the debugger automatically when a process crashes while running outside of Visual Studio. This is Just-In-Time debugging.</li> </ul> <p>Source: <a href="http://msdn.microsoft.com/en-us/library/3s68z0b3.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/3s68z0b3.aspx</a></p> </blockquote>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload