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>”.
This above described (InfoPath Form) task was the core of the problem. I was forced to build upon this scenario:
- Put my XSN form into the WSP which is “contaminated” with my specific strings
- During solution deployment extract the XSN package (which is just a CAB file)
- Take from the extracted files those two files containing my private strings (which are the manifest.xsf and OpenWorkbook1.xml files)
- Load these XML files, parse and replace the strings and save the files
- Repackage the files and create a brand new XSN adopted to the target environment
- 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):
- Chapter5_Feature2 is to be used to handle XSN uninstall and install
- Chapter5_Feature3 is to be used to handle feature activated events and repackage the XSN form (cabinet)
- 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
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).
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).
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.
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.
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).
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.
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).
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).
So the demo’s first part succeed 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)
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.
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
- How to deploy an admin approved form template using the feature framework
- Sahil Malik on Deploying InfoPath 2007 Forms to Forms Server properly
- Developing a InfoPath Solution using a Solution Package
- Deploy InfoPath as a Feature
- Automatic publish InfoPath forms via Feature-based ALM deployment
- Extracting Files from an InfoPath Form XSN File.
- Cabinet File (*.CAB) Compression and Extraction