Debugging a .NET user interface extension

The basic steps involved in debugging a user interface extension include:

Register the extension in a vault as described in “Registering an interface extension.” This specifies the path to the compiled extension DLL file. By default, the compiled extension is placed in the output subfolder of the project folder (for example, bin\Debug).
Set breakpoints in the code that requires testing.
Run the project in debug mode.
Visual Studio will stop code execution at the breakpoints so that you can resolve bugs as you test the functionality from within the PowerUser client application.

To configure a Visual Studio project for debugging:

In Visual Studio, open the project’s properties.
Click the Compile tab. The Compile options page appears.
If you are debugging an extension in a 64-bit application:
1. Click the Build Events button . The Build Events dialog appears.
2. Click Edit Post-build button. The Post-build Event Command Line dialog appears.
3. Add the following command line:
  "%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe" "$ (TargetPath)" /codebase /tlb
4. Click OK to save your changes.

Select Active (Debug) from the Configuration list.
Select the Register for COM interop check box.

Note
You may need to run Visual Studio as an administrator to be allowed to register the .NET assembly for COM interoperability.

Click the Debug tab. The Debug options page appears.
In the Start Action group, select Start external program and enter the path to the PowerUser executable.
Save the project.
Build the project.

When you run the project next in debug mode, Visual Studio will automatically start the PowerUser.

Note
If you specified the PowerUser executable (or another unmanaged application) as an external program to start for debugging a user interface extension, then debugging in Visual Studio 2010 using F5 may not stop execution at breakpoints that you have set. The debugger will launch and code will run, but breakpoint indicators will appear hollow and a message will appear that says “No symbols have been loaded for this document”. The problem is that the debugger has loaded the wrong Common Language Run-time version; 4.0 is loaded instead of 2.0. To resolve the issue, create a file named PowerUser.exe.config that contains the following: CopyPowerUser.exe.config fragment <?xml version ="1.0"?> <configuration> <startup> <supportedRuntime version="v2.0.50727" /> </startup> </configuration> Place the file in the same location as the PowerUser executable (by default, C:\Program Files\BC-Meridian\Program). This workaround is only required for debugging and should not be applied on development computers. For additional information, see the following resources.

Note

If you specified the PowerUser executable (or another unmanaged application) as an external program to start for debugging a user interface extension, then debugging in Visual Studio 2010 using F5 may not stop execution at breakpoints that you have set. The debugger will launch and code will run, but breakpoint indicators will appear hollow and a message will appear that says “No symbols have been loaded for this document”. The problem is that the debugger has loaded the wrong Common Language Run-time version; 4.0 is loaded instead of 2.0.

To resolve the issue, create a file named PowerUser.exe.config that contains the following:

CopyPowerUser.exe.config fragment

<?xml version ="1.0"?>
<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727" />
    </startup>
</configuration>

Place the file in the same location as the PowerUser executable (by default, C:\Program Files\BC-Meridian\Program). This workaround is only required for debugging and should not be applied on development computers.

For additional information, see the following resources.

See Also

Other Resources