Why Microsoft.Office.Server.Search.dll prevented me from using SPCop to analyse code.

I recently evaluated SharePoint Code Check (SPCop) and I quickly came across a problem whereby I was unable to run SharePoint Code Checks on certain projects.

The problem was that SPCop would initiate the build but then, before the code analysis started, the following error would be shown in the Visual Studio Output window:

SGEN : error : An attempt was made to load an assembly with an incorrect format: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.Office.Server.Search.dll.

 
The good news is after a bit of investigation I found that the issue has absolutely nothing to do with SPCop and it is actually quite an old SGEN and SharePoint 2010 custom development problem, so if you come across the same problem, don’t associate it to the new release of SPCop … I know it is easy for a developer to download software, install it and then consider immediate problems as something which was caused by misconfiguration or that there might be a known issue with the new release..

This problem is not because of SPCop!!

This post will explain the detail of the issue and how to work around it.

Scenario:
    I have a Visual Studio 2010 SharePoint project which contains:
    • a reference to Microsoft.Office.Server.Search.dll and
    • a web service reference
      (in this example a reference to SharePoint Authentication service at                       http://SiteCollectionURL/_vti_bin/Authentication.asmx)

I am busy with development and I can successfully build my project in debug mode.
 

I then try to run SPCop.. Right click on project, select SharePoint Code Check and then click on “Run SharePoint Code Check”
  
SPCop starts to create a new build but then fails and I am unable to analyse my code :-(

Why?
Before SPCop analyses your code it builds and packages the SharePoint project to create the .wsp file which it then inspects. During the build process SGEN actually fails. It is not SPCop which fails.
I was able to build and package my project in debug mode so why is SPCop unable to build the same code?
After a bit of investigation I realized that SPCop will build the project in RELASE mode even though my project configuration is set to DEBUG mode. This is actually great because before I finalize my code I need to build and test it in release mode anyway.

Why did SGEN fail?
If your project contains a reference to Microsoft.Office.Server.Search.dll and a reference to a web service SGEN will fail to generate the serialization classes.
This is due to Microsoft.Office.Server.Search.dll not being a MSIL dll but instead being specifically compiled to run on AMD64. I guess this means that SGEN is unable to reflect on it and build Serialization classes.
If you set your project to release mode and go to your project properties page, you will most likely notice in the Output section the setting for “Generate Serialization Assembly” is set to “Auto”.

The interesting thing is that when the setting is on Auto the following applies:
    • When build in debug mode: Generate Serialization Assembly = OFF
    • When build in release mode: Generate Serialization Assembly = ON

So, this explains why we can build in debug mode but not in release mode. And, because SPCOP builds in release mode it explains why you will receive the same SGEN error.

Proper Solution
I haven’t found a solution for building projects which contains both a reference to Microsoft.Office.Server.Search.dll and a web service reference in release mode. I assume that because of this issue one would build in debug mode and then use SGEN.exe to create the serialization assembly and then include the assembly in your package.

There is a Work Around

The work around is to set "Generate Serialization Assembly" to "Off" on the project properties for the release build configuration.

 

Once you changed this setting and saved the project you will be able to successfully analyse your code with SPCop

 

My concern is that if we set "Generate Serialization Assembly" to off, XmlSerializer will generate serialization code and a serialization assembly for each type when the SharePoint web app runs for the first time (example, after server reboot or IIS reset). Because this happens only once it is not a huge performance issue, but nonetheless, I would still like to find a proper solution.

Enjoy!!