Solution package containing the InfoPath 2010 repro


In my last post I have been complaining about an InfoPath 2010 error while opening the form within internet explorer whereas it works fine while the very same form is running within InfoPath client application. I have asked questions about this indeed very strange behavior without really getting resolution. Of course I realized it is somewhat uncomfortable for anyone trying to help to buy the book and go through the steps in order to have the scenario I was talking about. Instead it would be better to create a solution package (wsp) and a deployment batch for anyone interested in this issue and deploy the scenario on her SharePoint 2010 server farm.

So I honestly confess you, that starting this my project I was unaware of those difficulties awaiting me and it took me some time to complete such solution package which I’m going to present here. The articles which helped me greatly to accomplish this task are at the end of this article along with the solution download link.

Please note this article deals only with the end result, meaning it describes only the wsp solution package and the repro scenario steps. I’m going to provide the complete Visual Studio 2010 solution along with the code in my next article, hopefully in the upcoming week.

Also note, that this article does not deal with the question, whether the recent InfoPath Form was designed properly and whether the very same Form could be designed using data Connection Libraries, relative paths and further approaches. This article only takes the Form from the declared book as is. 

Solution package described

So let me explain what this solution is about and which tasks have been resolved during development. The solution package will firstly create within a dedicated site collection two libraries (according to the books receipt they are named EventBudgets and NewEventForms). The solution will thereafter upload two Excel spreadsheets into the first library. These spreadsheets are later on used as data templates within the InfoPath form. The solution will thereafter rewire the second library’s default form template to our custom template form which is represented by the infamous InfoPath Form (Form2.xsn file).

Furthermore in order to accomplish the last task (rewiring with new content type), the InfoPath form has to be uploaded and published to the FormServerTemplates document library. The key was hence fore to figure the form’s customization methodology in order to reflect the current user’s environment and the current site collection. This form namely contains at least six Data Connections (Picture 1) all of those based on my SharePoint 2010 development server’s fully qualified domain name. I mean, imagine this form containing exactly thirteen times string artifacts like “http://mydomain/sites/chapter/<further characters>” whereas in your environment every Data Connection will not work correctly unless those string artifacts will exactly reflect your environment e.g. “http://yourintranet/blah/jonnykid/<further characters>”.


Picture 1

This above described (InfoPath Form) task was the core of the problem. I was forced to build upon this scenario:

  1. Put my XSN form into the WSP which is “contaminated” with my specific strings
  2. During solution deployment extract the XSN package (which is just a CAB file)
  3. Take from the extracted files those two files containing my private strings (which are the manifest.xsf and OpenWorkbook1.xml files)
  4. Load these XML files, parse and replace the strings and save the files
  5. Repackage the files and create a brand new XSN adopted to the target environment
  6. Take this XSN and upload and register it within SharePoint 2010 server

Further problem was to find some library dealing with cabinets, as no such exists within the official .NET Framework 3.5 SP1. So I took CabLib which is a very nice and very well documented, easy-to use signed library. The perfect choice to use within a SharePoint solution.

It was needed to figure, how to accomplish the timing around the form’s extraction and compression during feature deployment. Sahil Malik suggested in this article a particular declarative XsnFeatureReceiver-strategy, which indeed works fine, however it is impossible to use in my scenario as it would publish rather the original XSN Form. Why? This is due to the fact, that the form will be published immediately during wsp installation and there is no way to hook-in or repeat the step after succeeded XSN repackaging.

So I have decided to create my own Feature receiver class inherited from the XsnFeatureReceiver. This way I could during solution deployment uninstall the automatically published old XSN, alter that XSN, and republish it within FeatureInstalled. The tricky problem to be solved here was the fact, that within the Feature’s FeatureInstalled event handler there is absolutely no information yet available about the targeting site collection. This is only available within FeatureActivated event handlers’ context.  So I have resolved this catch using a somewhat unusual features-architecture like this (the name Chapter5 refers to the book’s chapter five):

  1. Chapter5_Feature2 is to be used to handle XSN uninstall and install
  2. Chapter5_Feature3 is to be used to handle feature activated events and repackage the XSN form (cabinet)
  3. Chapter5_Feature1 is to be used to create the two libraries and assign the appropriate custom content type to the second library

The deployment batch (Picture 2) reveals the timing (whereas %~1 is the targeting site collection):

stsadm -o addsolution -filename chapter5.wsp 
stsadm -o execadmsvcjobs
stsadm -o deploysolution -name chapter5.wsp -immediate -allowgacdeployment
stsadm -o execadmsvcjobs
stsadm -o uninstallfeature -filename Chapter5_Feature2\feature.xml -force
stsadm -o activatefeature -name Chapter5_Feature3 -url %~1
stsadm -o installfeature -filename Chapter5_Feature2\feature.xml -force
stsadm -o execadmsvcjobs
stsadm -o activatefeature -filename Chapter5_Feature2\feature.xml -url %~1
stsadm -o activatefeature -name Chapter5_Feature1 -url %~1
stsadm -o execadmsvcjobs

Picture 2

You see, the solution is added firstly to the farm, then it is deployed. During deployment the XsnFeatureReciever will publish the original XSN form which couldn’t be prevented and therefore the batch will next remove (uninstall) that feature. Thereafter Chapter5_Feature3 is activated providing the site-collection’s URL (see %~1). At this step the XSN package will be extracted, altered and compressed. Thereafter Chapter5_Feature2 is install in order to re-publish the repackaged XSN, and lastly Chapter5_Feature1 will do the rest of the job (described at the beginning above).

Step-by-step guidance repro scenario

How to use this package? Download please and unzip it in a dedicated folder. I have tested the solution deployment on several machines. As good starting point for appropriate machine environments I should mention firstly Sahil Malik’s SharePoint 2010 development machine created according to his book ‘s instructions. Another machine I have tested on is the official Microsoft Information Worker Demo Image which could be downloaded for free.

Here goes my step-by-step guidance for the test scenario. First of all please create a fresh new site collection based e.g. on the Team Site collaboration template, however this does not matter too much. Next open a privileged administrator command prompt, change the directory to the downloaded and extracted package’s directory (Picture 3) and run the DeployChapter5Xsn.cmd batch fed with your site collection’s URL (Picture 4).


Picture 3


Picture 4

The batch will show you twice the number of running deployments and hit enter if you are sure there are zero deployments running (Picture 5).


Picture 5

Please make sure the XSN form publishing succeeded. The success’s prerequisite is to see the Phase1 and Phase2 messages (Picture 6) immediately after feature re-install is kicked on.


Picture 6

After the batch completed switch to your site collection and make sure the EventBudgets and NewEventForms libraries are created and you see the links within the Quick Launch pane. The EventBudgets library should have two spreadsheets uploaded (Picture 7). The other library is empty yet.


Picture 7

Furthermore check the XSN form has been published and registered successfully going to you site’s Form Templates Library. In order to do so, click on the left hand side All Site Content >> Form Templates (Picture 8). You have to see Form2.xsn (Picture 9).


Picture 8


Picture 9

Select View Properties, and confirm you see the Form ID (Picture 10). If this piece of information is empty, then something went wrong. The Form has been uploaded however registration failed. Seeing the ID is reassuring.


Picture 10

Further check could be done in Central Administration >> General Application Settings >> Manage Form Templates. You should see here the Form2.xsn as well.

Now time is to test the Form, for which reason let’s go back to you site collection and click on the NewEventForms link. This will open that Library which is empty yet (Picture 11). Here you have to click the “Add document” link which should start the infamous form within browser (Picture 12).


Picture 11


Picture 12

My previous article deals with the question how to make sure this will truly start within browser. I can confirm if you are going to work with the Microsoft IW Image, this will immediately open in browser. Make sure the Event Type and Event Location drop down lists work fine. These lists are filled via RESTFul Data Connection reading the another library’s Lookups.xlsx spreadsheet. Fill your Event Name and click on the Submit button. This will bring you the reported error message (Picture 13).


Picture 13

So the demo’s first part succeed Smile as we have produced the error. In order to make sure the form is fine, let’s open it in InfoPath client. This could be only done if you have installed Office InfoPath 2010 on your system. The Microsoft IW Image fulfills this prerequisite as well. In order to force the form opening within client application, go to Site Actions >> Site Settings >> Site Collection Features  and activate the Open Documents in Client Applications by Default feature. Repeat now the previous steps and confirm the form is opened within InfoPath client (Picture 14)


Picture 14

Fill in your data and Submit the form. The InfoPath client will disappear. Go right now to your site collection’s NewEventForms library. You have to see the submitted document (Picture 15). Click on it! This confirms, the Form works fine, the document has been submitted as expected.


Picture 15

Conclusion: In this recent article I’m providing a download to a package which installs a repro scenario according the book’s (Pro SharePoint 2010 Solution Development: Combining .NET, SharePoint, and Office) scenario, whereas the InfoPath form works fine within client application however produces an error at submit while opened within browser. My question is whether anyone could take this solution and confirm the scenario behaves like described and perhaps could explain what’s going on. Thanks for your contribution. Here is the download to my package:

Some useful articles concerning the topics above

This entry was posted in SharePoint 2010. Bookmark the permalink.

3 Responses to Solution package containing the InfoPath 2010 repro

  1. Brendan says:

    Hi, I have the same issue. I followed the steps in the book and it works fine from the InfoPath client but fails when the form is published to SharePoint.

    The Logs report:

    There was a form postback error. (User: xxx, Form Name: EventForms, IP: , Request: http://xxx, Form ID: urn:schemas-microsoft-com:office:infopath:EventForms:-myXSD-2011-12-19T09-58-13, Type: KeyNotFoundException, Exception Message: The given key was not present in the dictionary.)

    I tried this on a local dev machine and also a server with the same results. Changing to data connections doesn’t help.

    I’m guessing this is a credentials issues but can’t find any troubleshooting guidance.

    I wondered if you got any further with this? I will post back if I crack it!


  2. Stefan R. says:

    Hi Brendan, thnx for reporting. I was trying to resolve this issue and contacted some collegues experienced in SharePoint devlopment, however without any results. MS Premier-support could escalate the issue futher to the dev-team.

  3. Brandy says:

    Does your site have a contact page? I’m having trouble locating it but, I’d like to send you
    an e-mail. I’ve got some suggestions for your blog you might be interested in hearing. Either way, great website and I look forward to seeing it improve over time.

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