If you are developing custom extensions for Reporting Services (such as a data processing extension, delivery extension, security extension, rendering extension, report definition customization extension) with Visual Studio 2010, you have to make sure you compile the extension for the .NET 2.0/3.5 CLR because current versions of Reporting Services run in the 2.0/3.5 CLR, and extensions compiled for .NET 4.0 cannot be loaded into the 2.0/3.5 CLR.

Some types of custom extensions can be deployed within BI Development Studio, and you can debug those directly.  However, if you chose to debug custom extensions applied on a report server, you have to attach to ReportingServicesService.exe.  This works fine when debugging with Visual Studio 2005 or Visual Studio 2008.

However, Visual Studio 2010 comes with .NET 4.0, which brings the 4.0 debug engine.  There are now two debug engines inside Visual Studio 2010, one for .NET 2.0/3.0/3.5, and the other for 4.0 only.  If Visual Studio 2010 cannot determine which debug engine to use when attaching to a process, it uses the 4.0 debug engine by default.  If you attach to a 2.0/3.5 CLR process with the 4.0 debug engine in Visual Studio 2010, it is not going to hit your code breakpoints.  You can read more details about this here.

The best workaround when debugging your report server custom extensions with Visual Studio 2010 is to add the following entry to ReportingServicesService.exe.config, which will enable Visual Studio 2010 to attach the right debug engine. 

   <startup useLegacyV2RuntimeActivationPolicy="true">
       <supportedRuntime version="v2.0.50727" />

Note: After you modified the .exe.config, make sure to restart the Reporting Services Windows service.