Symptoms

After upgrading to K2 BlackPearl 4.6.11, custom web application is erring with: System.BadImageFormatException: Could not load file or assembly 'SourceCode.HostClientAPI' or one of its dependencies. An attempt was made to load program with an incorrect format.
 

Diagnoses

This web application was previously configured to run with the application pool's 'Enable a 32-bit Applications' setting being 'True' as such it was likely attempting to load the x86 architecture of the 'SourceCode.HostClientAPI' assembly from the 'bin' directory of this web application. Starting K2 Blackpearl version 4.6.11, this x86 version of the assembly will no longer be available where it used to be (used to be available at location 'C:Program Files(x86)K2 blackpearlBin', in 4.6.11, it is replaced with the AMD64 version).
 

Resolution

To check the processor architecture of an assembly, the following Windows PowerShell command can be executed (will usually return x86 or 32-bit, AMD64, MSIL):

 

 reflection.assemblyname]::GetAssemblyName("C:Program Files (x86)K2 blackpearlBinSourceCode.HostClientAPI.dll") | fl

 

* change the path to the actual file as necessary

 

The current application pool's 'Enable a 32-bit Applications' setting will affect if your web application will try to load the x86 or x64 version of the 'SourceCode.HostClientAPI' assembly.

 

https://help.webcontrolcenter.com/kb/a1114/how-to-enable-a-32-bit-application-pool-in-iis-7-dedicated-vps.aspx

 

Although x86 of the 'SourceCode.HostClientAPI' assembly is no longer available at 'C:Program Files(x86)K2 blackpearlBin', both versions of the assemblies can still be retrieved from the locations below if needed:

 

C:WindowsassemblyGAC_32SourceCode.HostClientAPI4.0.0.0__16a2c5aaaa1b130d

C:WindowsassemblyGAC_64SourceCode.HostClientAPI4.0.0.0__16a2c5aaaa1b130d

 

Some OS will requires the implementation of the registry key below to access the GAC location above:

 

aHKEY_LOCAL_MACHINESOFTWAREMicrosoftFusion] "DisableCacheViewer"=dword:00000001

 

http://www.symantec.com/connect/blogs/using-windows-explorer-view-global-assembly-catalog

 

To resolve the issue in this case, the Application Pool's 'Enable a 32-bit Applications' setting was kept 'True' and the x86 version of the assembly was used. Additionally, the version of the K2 assembly used by the custom K2 application will need to match the version from the K2 server.