Debugging Custom Assemblies

The best debugging tool for debugging custom assemblies, no surprise, is Visual Studio. There are two debugging options:

• Debug with a single instance of Visual Studio. This is done by creating a single solution that contains both a Reporting Services project and a custom assembly project. You would set breakpoints in a custom assembly and run the report in DebugLocal mode. The easiest way to start DebugLocal is to right-click on the report that needs to be tested and select Run from the shortcut menu.

• Debug with two instances of Visual Studio: one has a report project and another custom assembly. Set breakpoints in the custom assembly, click debug, and from the list of processes select devenv.exe that corresponds to the report project. After you run a report that calls the assembly in preview mode, the debugging session will break at defined breakpoints.

Debugging with a single instance of Visual Studio ( DebugLocal method) requires several setup steps:

1.	Include both the report project and a custom assembly project in a single solution.
2.	Set breakpoints in a custom assembly.
3.	Set up the report project as a startup project by right-clicking the project in Solution Explorer and selecting Set as StartUp Project from the shortcut menu.
4.	Set up a report as a start item. Right-click the project in Solution Explorer and select Properties from the shortcut menu, then from the Start Item drop-down, select a report that you want to debug, as shown in Figure 23.7. Figure 23.7. Project Configuration dialog box.
5.	Start debugging from the Debug, Start Debugging menu or by pressing F5. Use F11 to step through the report.

Running the GetLibraryInfo() example that was developed earlier in the chapter did not create any issues when you ran it in preview mode (Report Preview tab). This is because preview mode does not enforce security permissions. Let's try to run GetLibraryInfo() in DebugLocal mode. Visual Studio breaks on the GetExecutingAssembly() call and shows an exception:

System.Security.SecurityException was unhandled by user code Message="Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."

So, what happened with your code and why didn't it work?

First, you have to check if the configuration was properly set. Reading of the configuration file was discussed earlier, but GetLibraryInfo() does not really read a configuration file. All it does is call the GetExecutingAssembly() function.

 public static string GetLibraryInfo()     {         return Assembly.GetExecutingAssembly().GetName().ToString()              + (                  (mPeriod != -1) ?                     " Initialized with value=" + mPeriod.ToString()                     : " Not  initialized "                 );      } 

The clue here is the fact that the assembly is trying to retrieve information about itself. So, it must mean that you need some kind of permission to that assembly file.

Earlier in this chapter, you learned that the GetExecutingAssembly() requires the PathDiscovery permission. To configure Report Designer for debugging of this library, copy the library to C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ or, better yet, set an output path for the library in Visual Studio. In Solution Explorer, right-click the library project, select Properties, click the Build tab, and enter C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ for the Output Path, as shown in Figure 23.8.

Figure 23.8. Library Properties interface.

The benefit of setting an output path is that Visual Studio realizes that it was using this library (through Report Designer) and, thus, is able to replace it. If Visual Studio compiles the library to an alternative location and a developer is trying to copy to the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ directory, afterward he might not be able to do that. This is because Visual Studio will be "holding" this library during and after debugging. Visual Studio will require restart so it can release the "hold" and so the library can be replaced .

The next step is to create a <PermissionSet> with PathDiscovery permission in C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\RSPreviewPolicy.config :

 <PermissionSet class="NamedPermissionSet"    version="1"    Name="  GetLibraryInfoPermissions  "      Description="A custom permission set to grant read access to a configuration file.">   <IPermission    class="FileIOPermission"   version="1"  PathDiscovery  ="C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies"   />   <IPermission class="SecurityPermission"   version="1"  Flags="Execution, Assertion"  />   </PermissionSet> 

And in the same file, add the following:

[View full width]

 
 [View full width] 
 <CodeGroup class="UnionCodeGroup"   version="1"   PermissionSetName="  GetLibraryInfoPermissions  "   Name="MyNewCodeGroup">   <IMembershipCondition class="UrlMembershipCondition"   version="1"   Url="C:\Program Files\Microsoft Visual Studio 8 Visual Studio 8\Common 7\IDE  \PrivateAssemblies\RSCustomLibrary.dll </CodeGroup> 

to this location:

...

ADD HERE (before the second CodeGroup above the PolicyLevel)

 </CodeGroup>   </CodeGroup> </PolicyLevel> 

The final step is to Assert the permission in the code, as follows :

[View full width]

 
 [View full width] 
 public static string GetLibraryInfo()  {  try   {   FileIOPermission permission = new Perrmission   (FileIOPermissionAccess.  PathDiscovery,  @"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies  \RSCustomLibrary.dll");   permission.Assert();   }   catch (SecurityException ex)   {   return ex.Message;  }  return Assembly.GetExecutingAssembly().GetName().ToString()    + ((mPeriod != -1)?           " Initialized with value=" + mPeriod.ToString()              : " Not initialized");    }