Things you need to watch out for when publishing InfoPath forms with Content Types -from within the InfoPath forms designer- to SharePoint.
I used to have InfoPath forms (with and without code) directly deployed to the server. I never had any issues with content types when installing it on the server. However, since our organization decided to bring SharePoint into the “cloud” no more code or deployments on the servers are allowed. Why? Because SysAds are “scared” (remember ScarePoint) of anything being loaded onto their servers that could bring them down, cause trouble, or simply cause work. Theoretically cloud computing may work, but in reality it doesn’t, at least in my opinion. Now we have a pretty much handicapped SharePoint. When I hear cloud computing I throw up. Sorry.
To the issues I had to face when developing no code InfoPath forms with content types:
Do not publish the InfoPath form before you have not completely finished it in the designer. Why?
1. If you for example try to add fields or simply try to change a text field into a number field later on. You might be out of luck. For me it did not reflect the changes on the SharePoint site. Very bad if you need to filter or make calculations on number fields. You can’t make calculations with text field values. I had no other choice than to blow away the entire site and recreate it.
2. Once you published the InfoPath form you cannot remove unwanted content type fields. There is a workaround on the web but it involves going into the database to identify and kill the fields (of course not recommended by MS).
3. I even had issues publishing forms. I got errors that InfoPath was unable to create the content types on the SharePoint site. I don’t know maybe the form had too many fields (approx. more than 40) I wanted to populate to the library. Never had a limit when installing the forms on the server, but there might be one when publishing through the client. What to do? No idea. We were able to fix it by publishing it without using content types – as a form template. It was OK for now since that form does not require changes in the future.
Always be aware that you cannot overwrite an InfoPath form if the existing forms in SharePoint are digitally signed. It will make those signatures invalid.
That’s why it is good to publish with content types. It allows to publish different form versions with different file names.
4. Creating no code InfoPath forms with Visual Studio. For some reason several client computers could not open the form. I found out it had something to do with the .dll that Visual Studio creates when it packages the form. No matter what I tried, it created an empty .dll (even though there is no code). You know that you can rename the ***.xsn form file to ***.cab and unpack it using Winzip or any other packaging tool.
Most computers didn’t mind the dll. Some computers could not open the form for whatever reason. The web said it has something to do how Office and .Net was installed. The best thing to do was to redo the form with the InfoPath forms designer application and the problem was gone.
This issue is fixed with Visual Studio 2010, because 2010 does not come with an InfoPath forms designer anymore… LOL
5. Which leads me to the next problem I ran into. There is a difference between the population of fields through the “form options menu” and through the publishing process. Prefer adding the fields you want to populate to the SharePoint library through the publishing process. You actually have more control over the process.
I had to redo a form once (see above) and ended up with duplicate content types on the library. Painful if you need to work with the field values afterwards. You end up with trial and error on which field is the one with the value and which one is the empty one. Since you cannot delete the duplicates you would have to delete and redo the entire site again.
In simple words. Finish the InfoPath form before publishing it or create a testing site you can publish it to before deploying it to your production site. Use the field population through SharePoint publishing and do not populate too many fields.