Office Preview 2013 breaks your SharePoint 2010 Enterprise, notably InfoPath

Office logoI’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=' (...)

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:
UlsViewer complained:

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Office.InfoPath, Version=, 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=, 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\\Policy.14.0.Microsoft.Office.InfoPath.config.
LOG: Publisher policy file redirect is found: redirected to
LOG: ProcessorArchitecture is locked to MSIL.
LOG: Post-policy reference: Microsoft.Office.InfoPath, Version=, 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=, 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 “”. 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 version).
The binding mismatch in the fusion log must refer to this DLL. The config file reads:

<?xml version="1.0" encoding="UTF-16"?>
		<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
				<assemblyIdentity publicKeyToken="71e9bce111e9429c" name="Microsoft.Office.InfoPath" culture="neutral"></assemblyIdentity>
				<bindingRedirect oldVersion="" newVersion=""></bindingRedirect>

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…


10 thoughts on “Office Preview 2013 breaks your SharePoint 2010 Enterprise, notably InfoPath

  1. Hello Sebastiaan,

    In your blog you described to delete all Policy.14.0.Microsoft.Office items. That are to much files to delete. It is only nessesary to delete 3 folders.

    The others you better can not delete because those version 15 are available in the assembly. (if you has installed Office 2013 Professional Plus) if you want to normal function all the other office programs you don’t delete the other folders.

    Regards Paul Font Freide

  2. Dear Paul,

    You are indeed correct, you don’t need to delete all files if you wish to keep Office 2013 Pro in place. I already uninstalled Office 2013 so I deleted all redirects to 15 as I had no Office 15 components on my machine left.

    Thank you for your reply.

  3. When I tried to delete the three InfoPath folders mentioned above, Windows reports “You require permission from SYSTEM to make changes to this folder”. I’m logged in as a domain user with local admin rights. And I started Windows explorer using run as Administrator. I tried to change the owner of these folder from SYSTEM to my account, but I end up getting Access Denied on that as well.

    How did you manage to delete these folders?

  4. Aaaah I also installed Office 2013 and it broke my SharePoint 2010 InfoPath forms.
    Works like a charm now after deleting the 3 folders.

    Ty Sabbe

  5. Pingback: Resolvendo o erro “Could not load file or assembly Microsoft.Office.InfoPath” | SharePoint

  6. Hello
    I Can’t Delete these three folders; i see the following error message:
    “Assembly could not be uninstalled because it is required by other applications”
    What can i do now?
    Is it because of sharepoint 2010 or one of its prerequisites?

    special thanks

    • Hi mmnsh,

      Thank you for your interest.
      The most likely cause for that error is that the DLL is still in use. Try stopping IIS and killing owstimer.exe.
      Then retry deleting the assembly.
      If that still doesn’t work, you need to find out which application is using the DLL. It may be Powershell, Visual Studio … Use SysInternals’ Process Explorer to find handles for that DLL.
      Then kill every application that uses it and retry deleting the DLL.

      Good luck!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s