I’m a SharePoint dev at the moment, and on my SharePoint dev box I recently installed the Office 2013 Preview, wanting to be on the edge of new releases. I knew it was a risk, but thought it wasn’t going to harm my dev machine. Oh boy, was I wrong thinking that…
First (and only) symptom:
Could not load file or assembly 'Microsoft.Office.InfoPath, Version=220.127.116.11' (...)
when deploying administrator-approved forms to my SharePoint farm using a solution (with its specific feature receiver). A long process normally (up to 10 minutes for 8 forms). However, I noticed that this took less time than average. Checking my forms, none of them rendered anymore, with the above exception. The forms were also no longer present in Central Admin (as they failed to deploy due to the “missing” assembly).
The referenced assembly was always there though, in the GAC under MSIL, no change there.
For some reason it wasn’t loading.
I got pretty sick of it, so I fired up the Fusion logger (Assembly bind failure logging) to find out what was going on.
By this time, I had already uninstalled Office 2013 Preview, but the error happened before already.
Upon uploading a form to Central Admin and clicking “Verify” the following error showed up:
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Office.InfoPath, Version=18.104.22.168, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.
The fusion log reports:
*** Assembly Binder Log Entry (4/12/2012 @ 12:51:23) ***
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll
Running under executable c:\windows\system32\inetsrv\w3wp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = WINDEVSP2010\SPInstaller
LOG: DisplayName = Microsoft.Office.InfoPath, Version=22.214.171.124, Culture=neutral, PublicKeyToken=71e9bce111e9429c
LOG: Appbase = file:///C:/inetpub/wwwroot/wss/VirtualDirectories/80741441fc-0d39-48f0-954e-96614c358095/
LOG: Initial PrivatePath = C:\inetpub\wwwroot\wss\VirtualDirectories\80741441fc-0d39-48f0-954e-96614c358095\bin
LOG: Dynamic Base = C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\ef3f51d0
LOG: Cache Base = C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\ef3f51d0
LOG: AppName = a6d35fbc
Calling assembly : (Unknown).
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\inetpub\wwwroot\wss\VirtualDirectories\80741441fc-0d39-48f0-954e-96614c358095\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Publisher policy file is found at C:\Windows\assembly\GAC_MSIL\Policy.14.0.Microsoft.Office.InfoPath\126.96.36.199__71e9bce111e9429c\Policy.14.0.Microsoft.Office.InfoPath.config.
LOG: Publisher policy file redirect is found: 188.8.131.52 redirected to 184.108.40.206.
LOG: ProcessorArchitecture is locked to MSIL.
LOG: Post-policy reference: Microsoft.Office.InfoPath, Version=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/Temporary ASP.NET Files/root/ef3f51d0/a6d35fbc/Microsoft.Office.InfoPath.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/Temporary ASP.NET Files/root/ef3f51d0/a6d35fbc/Microsoft.Office.InfoPath/Microsoft.Office.InfoPath.DLL.
LOG: Attempting download of new URL file:///C:/inetpub/wwwroot/wss/VirtualDirectories/80741441fc-0d39-48f0-954e-96614c358095/bin/Microsoft.Office.InfoPath.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\inetpub\wwwroot\wss\VirtualDirectories\80741441fc-0d39-48f0-954e-96614c358095\bin\Microsoft.Office.InfoPath.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: Microsoft.Office.InfoPath, Version=18.104.22.168, Culture=neutral, PublicKeyToken=71e9bce111e9429c
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Setup failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Now that’s a better error we can work with!
It seems that the GAC has some policies which allow custom redirection to other versions of the DLL’s (and much more dark magic I’m sure).
I then went to the policy directory:
I found under subfolder Policy.14.0.Microsoft.Office.InfoPath a folder named “22.214.171.124__71e9bce111e9429c”. I was worried and relieved at the same time.
In that folder I found both Policy.14.0.Microsoft.Office.InfoPath.config and Policy.14.0.Microsoft.Office.InfoPath.dll (the 126.96.36.199 version).
The binding mismatch in the fusion log must refer to this DLL. The config file reads:
<?xml version="1.0" encoding="UTF-16"?> <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity publicKeyToken="71e9bce111e9429c" name="Microsoft.Office.InfoPath" culture="neutral"></assemblyIdentity> <bindingRedirect oldVersion="188.8.131.52" newVersion="184.108.40.206"></bindingRedirect> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
Exactly what I feared, that somehow it was still referencing v15.
By removing all (Office-) folders that started with Policy.14.0 (…), and thus removing any reference to v15, and after an IIS reset, it worked, I again could manage form templates.
I’ve learned something truly valuable today: never let a “file not found” or “assembly not found” fool you without checking out the fusion logs.
In that regard – to end this post – I’d like to point to a great tool, the “Fusion Log Viewer Settings Changer” (found here), quite a mouthful.
It’s an easy command line tool that allows you to enable fusion logging and disable it without having to manually peek in the registry, like many other posts suggest.
There, I fixed it! 🙂
Back to deploying my forms now…