Freigeben über

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.BizTalk.Interop.SSOClient'

  • Artikel

This is one common error you might encounter especially if you are into an in-place upgrade activity from BizTalk 2009 or older to BizTalk 2013. There are indeed customers who have run into this even with fresh installations and they do have my consideration here.

Note: For Enterprise Service Bus Took Kit 2.2, this is a recognized bug and has been fixed in CU2 for BizTalk Server 2013. And so no further worries on the ESB front.

Getting back to BizTalk, whilst an in-place upgrade to BizTalk 2013 what most users overlook is the Targeted Framework BizTalk is built against which is .NET 4.0 and a new assembly comes into play. (Keep in mind, older versions use 2.0 based
assembly). In a correctly upgraded BizTalk 2013 environment, the SSO (Microsoft.BizTalk.Interop.SSOClient.dll) file version will be 9.0.1865.0 and the .NET version will be 7.0.2300.0 (You could check the version in Registry atHKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ENTSSO or C:\Program Files\Common Files\Enterprise Single Sign-On). But during the upgrade somehow the SSO assembly fails to update and that causes the system to behave abnormally.

In such a scenario there are 4 things you could try. I have seen articles on the first two, but the third and fourth revealed itself during a recent customer incident I attended to.

Upgrade SSO through Installer

  1. Verify that the current master secret key is backed up to a secure location.
  2. Verify that a current version of the SSO database is backed up to a secure location.
  3. Run the Enterprise SSO Setup.exe file from the BizTalk Server 2013 installation media
  4. In the Autorun dialog box, select Microsoft Enterprise Single Sign-On.
    - For 32-bit computers, use the Setup.exe file at \Platform\SSO.
    - For 64-bit computers, use the Setup.exe file at \Platform\SSO64.
  5. In the Summary dialog box, select Upgrade.
  6. Restart the ENTSSO and BizTalk services.

Tweak app pool settings

It could so happen that your IIS upgrade scripts failed to upgrade the application pool which when originally created were set to Classic and targeted against v2.0 framework. BizTalk 2013 being built against the v4.0 framework will fail to load the correct assembly simply because it doesn’t know where to locate the DLL. Alongside, you also need to run aspnet_regiis.exe –I to re-register the asp pages against the updated IIS metabase (v4.0).

Overwrite the WCF Runtime binary DLL.

Check the file version of BizTalk.Adapter.Wcf.Runtime.dll in C:\Windows\Assembly. (That’s the WCF-adapter related to binary that references SSOClient.dll). In a failing environment, the file version could be 3.9.469.0 or older and to get it working. We should have 3.10.229.0 version in GAC. So go ahead, copy the newer (3.10.229.0) DLL from a working environment, if you have one and overwrite the older DLL in GAC.

Reexamine your BizTalk Config file

Now this part is fairly intriguing. And this typically comes into play when you attempt to export all your configuration data from BizTalk 2009 to BizTalk 2013 within the BTSNTS*.exe.config files. Most users fail to notice that in due course of updating the configuration file(s), RuntimeActivationPolicy segment gets whacked off.

<startup useLegacyV2RuntimeActivationPolicy="true">                                
       <supportedRuntime version="v4.0"/>               
</startup>

This segment is pretty important for your BizTalk services to identify the location where it should look for the assemblies. Effective BizTalk 2010, there are two GACs, one each for .NET 2.0 and 4.0. So if you don’t have these in the config, BizTalk service will look for 4.0 based assemblies in 2.0 GAC, but to no avail. This might cause unpredictable behaviors on your BizTalk servers.

Written BY
Rajkumar Damodaran

Reviewed By
Jainath V R

Microsoft GTSC India