While performing several upgrades for my clients I have encountered all sorts of issues that hinder and even prohibit a content database upgrade. Most of these issues can be traced to a single source, a person with too much permission and too little knowledge (about SharePoint, about programming APIs, about databases, etc.). This is the world of “I know how to do X and since I am an administrator, I’ll do Y.” (See: if all you have is a hammer, everything looks like a nail or the Harbar corollary: “Just because you CAN doesn’t mean you SHOULD.”) The problem, you see, is this is very short sighted. It pushes the problem off to the next poor soul who should deal with the REAL issue that was preventing you from being successful in the first place. In my class Upgrading Your Farm to SharePoint 2016 I cover many of the issues that you may encounter in your upgrade, but today I found one I did not cover, so I figured I’d do a quick post on it. Other tools I have built for InfoPath came from ideas in Brian Cartmel’s post on brute forcing InfoPath with PowerShell automation: PowerShell Automation

The InfoPath Franken-form

Some years ago at my current client, an “InfoPath Expert” built an InfoPath form that, in hindsight, should have been an application. They embedded TONS of business logic in the form. They included rules, web service calls, data connections, and hidden sections. In fact, I think they just listed every possible feature and nook and cranny that can have a rule and data connection and action and then added those items to this form. There is no documentation what so ever. “What does it do?” I’d ask. “It creates a list item.” Was the answer. Well, as it turns out, it creates items in 10 different lists and then uses IDs to maintain “referential integrity”. I know these folks aren’t alone in their pain, but the truth is, the form works, it satisfies their business purpose. So, we need to upgrade it, along with a transition from Classic Authentication to Claims Authentication.

The Problem

The real issue is that using InfoPath to edit the form was not working. We were looking for 12 specific rules that needed to be changed and NONE of the rules were showing in the designer. We could see them in the Rule Inspector, but they could not be located through the UI. So here is how we solved the issue. You must “unpack” the InfoPath XSN file, edit the manifest and then pack it up again. Did you know that InfoPath XSN files are just CAB files by another name? Now you do.

1. Find yourself a copy of CabLib.dll (I got mine from CodePlex, remember WSPBuilder? Good Times!)

2. Open a PowerShell session and expand the XSN file so you can get at the chewy middle.

   EXPAND "MyInfopathFile.xsn" -F:* "d:\infopath\xsn\extracted"

3. Now browse into the extracted directory and behold all the glory that is InfoPath! Actually, just look for the manifest.xsf file. This has all the rules, data definitions and other stuff you are probably looking for. There are a bunch of other files in there too, so if you don’t find what you need in the XSF file keep looking. In my case I was looking for a couple rule formulae that were written incorrectly. So I used Notepad++ to perform the editing.

4. Save and close the file and return to PowerShell.

5. Brian mentions thanks to http://www.pseale.com for the following function.

   function Compress-Directory ($dir, $cabFileFullPathAndFilename)
   {
   # the cablib dll can be downloaded from http://wspbuilder.codeplex.com<br /> </span>
     [void][reflection.assembly]::LoadFile("C:\Users\ruby\Desktop\Forms\CabLib.dll")
   
   $c = new-object CabLib.Compress
   $c.CompressFolder($dir, $cabFileFullPathAndFilename, $null, $null, $null, 0)
   
   # thanks to http://www.pseale.com for this function
   }

6. Now you just need to recompress the XSN file.

     Compress-Directory "d:\infopath\xsn\extracted" " d:\infopath\newfile\template.xsn"

7. Copy the file to the list or library in SharePoint designer. In this case, it was the template.xsn file for a list. I made a copy of the previous form and then checked out the template.xsn file before overwriting it with my version. Then I checked it back in.

8. Reopen the form in InfoPath and it should load without error. If you messed up the structure of the file, that’s on you. In my case it opened just fine.

9. The problem was a Quick Publish did not do the trick. Click the File tab to go to backstage. Choose Publish from the left navigation and then choose the SharePoint option, in this case, SharePoint list, but your form may be a form library.

10. Now test, test, test.

Conclusion

There you have it, Notepad++ as an InfoPath editor. Not the prettiest thing in the world, but it saved us hours of rummaging around. There is a lot that you can do with PowerShell and InfoPath when it comes time to upgrade, migrate or otherwise change the environment around your InfoPath forms. Check out Brian’s article for more ideas.