Okay so, the catchphrase/keyword here is “properly”. This begs the question, what is improper?

See in InfoPath 2007, if you read all the docs, books, and even MSDN, they ask you to craft an InfoPath form, and then go through the publishing steps. Specifically, the docs call you to publish “To a SharePoint Server with or without InfoPath Forms Services”.

Hmm .. that’s good except, developers don’t deploy – infrastructure guys do.

My new motto is “If I can’t deploy properly, the feature doesn’t exist”.

So I am glad to say, that deploying infopath 2007 forms to forms server as web based forms is a feature that does exist – i.e. – you CAN package them up as features and solutions, and deploy them like god intended mankind to.

Here is how you can create and publish such a form.

1. Craft up your InfoPath Form – try and avoid certain features (too many to list here).
2. Publish it to “a network location”. This is a file on your disk.
   1. Ensure that while publishing to a network location, when faced with this question “if all form users can access the location that you entered .. “, blank out the textbox – you do not want the information of “where the form lives”, to be embedded in the form – you want that information to be embedded in the feature.
3. Great – now with the form published, craft up a visual studio solution, that will act as your InfoPath form/content type deployer.

Here is how you can craft up such a feature.

1. Craft up a project structure like this (this is a class library) -
   
2. In feature.xml, put in the following code -
   

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <Feature xmlns="http://schemas.microsoft.com/sharepoint/"

   3:           Id="41CEE181-9440-4536-A1DA-73F41D2155B7"

   4:           Title="My Form"

   5:           Description="This feature deploys the browser enabled InfoPath Form."

   6:           Version="12.0.0.0"

   7:           Scope="Site"

   8:           DefaultResourceFile="ipfscore"

   9:           ReceiverClass="Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver"

  10:           ReceiverAssembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" >

  11:      <ActivationDependencies>

  12:          <ActivationDependency FeatureId="C88C4FF1-DBF5-4649-AD9F-C6C426EBCBF5"/>

  13:      </ActivationDependencies>

  14:      <ElementManifests>

  15:          <ElementManifest Location="element.xml"/>

  16:          <ElementFile Location="MyForm.xsn"/>

  17:      </ElementManifests>

  18:      <Properties>

  19:          <Property Key="FeatureName" Value="My InfoPath Form Template Feature"/>

  20:      </Properties>

  21:  </Feature>

1. If you note, in the above, there is a receiver class that takes the responsibility of extracting the content type, and ensuring that the content type is browser renderable. How it does that? Heck I don’t know – the reflector code is obfuscated. I’m guessing it’s the equivalent of setting something in the database directly, which I shouldn’t be touching anyway. Except I know it works, and this is a supported mechanism because MSFT uses this all over the place.
2. Secondly, if you note, There is an activation dependency. The dependency is ensuring that you have enterprise features turned on. That’s it.
3. In the elements.xml put in the following code –
   

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

   3:      <Module Name="XSN" Url="FormServerTemplates" RootWebOnly="TRUE">

   4:          <File Url="MyForm.xsn" Name="MyForm.xsn" Type="GhostableInLibrary"/>

   5:      </Module>

   6:  </Elements>

1. As you can tell, I am simply copying over the MyForm.xsn over to a place called ~site/FormServerTemplates. If you view the SharePoint file system on the site (i.e. inside the content db), you will see that FormServerTemplates is a special place where templates for content types exist.
4. Your Install.bat looks like this –
   

   1:  @SET STSADM="c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm"

   2:  @SET GACUTIL="c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe"

   3:  @SET WSPPBUILDER="C:\Code\WspBuilder\WspBuilder.exe"

   4:   

   5:  @echo off

   6:  Echo Creating Solution Package

   7:  %WSPPBUILDER% -outputpath solution -Excludepaths bin

   8:   

   9:  Echo Retracting Solution

  10:  stsadm -o retractsolution -name MyForm.wsp -immediate

  11:  stsadm -o execadmsvcjobs

  12:   

  13:  Echo Deleting Solution

  14:  stsadm -o deletesolution -name MyForm.wsp

  15:   

  16:  Echo Adding Solution

  17:  stsadm -o addsolution -filename Solution\ MyForm.wsp

  18:   

  19:  Echo Deploying solution

  20:  stsadm -o deploysolution -name MyForm.wsp -immediate -allowGacDeployment -force

  21:  stsadm -o execadmsvcjobs

  22:   

  23:  Echo Resetting IIS

  24:  IISRESET

1. As you can tell, I’m a fan of WSPBuilder. You should be too.
5. Modify your project to call Install.bat at successful builds.
6. That’s basically it. Build & Deploy.

How to use it?

1. Create a Forms Library
2. Go to its Settings à Advanced Settings. Choose to allow management of content types, and choose to open “Browser Enabled Documents” in Web Pages, rather than the Client Application.
3. After having deployed the solution & activated the feature, you will see that there is a new content type called available called “MyForm”. Use that content type as the default content type of the document library you created above in Step #2.
4. Delete the default “form” content type.
5. That’s it – click “New” and the form should be running browser enabled. w00t!

How to deploy to production?

Simple – hand over the .wsp to your infrastructure guy, turn your phone off, and go have a smoke (or chew gum – whatever might be your thing).