Home Dashboard Directory Help

Debugging external application by mikecvelide


 as Fixed Help for as Fixed

Sign in
to vote
Type: Bug
ID: 487949
Opened: 9/3/2009 11:23:35 AM
Access Restriction: Public
User(s) can reproduce this bug


I am building an extension for an external application (Autodesk Revit Structure 2010). This is a .NET DLL loaded into the 3rd party app via a config file. The application loads succesfully, and executes on command, but debugging doesn't work when Visual Studio is attached.
Sign in to post a comment.
Posted by Microsoft on 12/22/2010 at 10:34 AM

This issue has been fixed in Visual Studio 2010 SP1. The SP1 beta is now available for download from MSDN http://www.microsoft.com/downloads/en/details.aspx?FamilyID=11ea69cb-cf12-4842-a3d7-b32a1e5642e2&displaylang=en

Best Regards,
Visual Studio Debugger
Posted by Microsoft on 5/11/2010 at 10:33 AM
Please see the following blog entry for more details on the workaround: http://blogs.msdn.com/debugger/archive/2010/04/30/can-t-hit-breakpoints-in-a-plug-in-or-can-t-debug-net-2-0-3-0-3-5-from-a-mixed-mode-exe-project-with-visual-studio-2010.aspx

@Bank of NY: you will need to create/modify the powershell.exe.config file
@JamesSummerton: you will need to create/modify the excel.exe.config file

Best Regards,
Visual Studio Debugger
Posted by James Summerton on 5/8/2010 at 5:57 AM
I get this issue when I am debugging an Excel COM Addin
Posted by Bank Of New York on 5/4/2010 at 3:10 PM
I have a class library project where I created some Cmdlets. For the project properties, I had "Start external program" point to powershell.exe. The command-line arguments would invoke a script that would load my class library. In Visual Studio 2008, breakpoints would hit, along with the System.Diagnostics.Debugger.Break() when I hit F5. In Visual Studio 2010 RTM, this does not work. The debugger is attached, but it's not looking at .NET 2.0 code. The modules windows is empty. If I detach and re-attch the debugger w/Attach To specifying "Managed (v2.0, v1.1, v1.0) code", breakpoints will hit.
Posted by Microsoft on 2/9/2010 at 3:58 PM
Yes we realize that this issue is still present; a resolution of "Postponed" means that while it may be considered for a service pack, it will not be fixed for the RTM release. As described above, this decision rests with the Visual Studio Project System team.

Best Regards,
Visual Studio Debugger
Posted by mikecvelide on 2/9/2010 at 12:53 PM
This may be intentional, but I want to make sure you realize this issue is still present in the RC of VS 2010.
Posted by Microsoft on 10/2/2009 at 2:56 PM

Unfortunately due to where Visual Studio currently is in the product cycle, the project system team determined that fixing this issue does not meet the bar at this time given that there is a reasonable workaround (providing the information in the *.exe.config file).

I will be am closing this bug as "Postponed".

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by Microsoft on 9/29/2009 at 4:07 PM

Thank you for the additional information, using the steps that you provided I was able to reproduce your issue with Visual Studio 2010 Beta 1. You did not mention it in the steps above, but I presume that you are using "Start external program" under the debug properties to start Revit (that is what repro'ed this behavior for me)?

The issue that you are encountering is that Visual Studio 2010 is launching Revit under the default debugger (v4.0) but since you are building a project against the 2.0 framework (3.5 runs on the CLR 2.0) in order to correctly debug your Revit plugin, Visual Studio must launch Revit under the 2.0 debugger, not the 4.0. I am moving this bug to the language project system team since they own the project system settings that govern this.

To work around this issue with Visual Studio 2010 Beta 1, you can either launch Revit and manually attach to the Revit process with your Revit plugin open (the debugger will automatically attach with the correct engine once the process has already started) or you can add a <supportedRuntime> attribute to the <startup> section of the Revit.exe.config file that will allow Visual Studio to determine which debugger should be attached:

<supportedRuntime version="v2.0.[version on your machine]" />

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by mikecvelide on 9/23/2009 at 6:30 AM
If you want to try this you can download a free trial of Revit here:

After installation, create a new Class Library project (I used C#) in Visual Studio 2010.

Reference the file "RevitAPI.dll" in the Revit installation folder Program directory

Implement the IExternalCommand interface as shown here: http://codepaste.net/y7jzsf

Edit your Revit.ini file in the Revit install folder Program directory to include a section like this:

ECAssembly1=C:\Documents and Settings\kingm\My Documents\Visual Studio 2008\Projects\RevitTest\bin\Debug\revittest.dll

Invoke the test App (after running Revit) by selecting it from the 'External Tools' drop down on the 'Add-Ins' tab as shown here: http://twitpic.com/ithqq
Posted by mikecvelide on 9/23/2009 at 6:14 AM
That is also skipped, it sails right past and executes the rest of the code (in this case, popping up a message box for testing purposes). Debug build... attached to the app... not really sure what's going on.
Posted by Microsoft on 9/22/2009 at 6:42 PM

Thank you for taking the time to report this issue. What happens if instead of setting a breakpoint, you insert the line of code "System.Diagnostics.Debugger.Break()". Is that skipped, or does it stop correctly there?

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by Microsoft on 9/7/2009 at 1:17 AM
Thanks for your feedback. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by Bank Of New York on 5/4/2010 at 3:06 PM
detach from the process and reattach. Make sure the "Attach to" is correct - for my case, it needed to be set to Managed (v2.0)