This is the second post in a series exploring InfoPath Forms Services in SharePoint 2010. See Part 1: The InfoPath Clients. Additional posts will be published in the coming weeks.
What’s the Same
Before diving too deep into the new features of InfoPath Forms Services, I’d like to highlight a few things that are the same. These aspects should be familiar to MOSS / InfoPath 2007 veterans, allowing you to get up to speed more quickly.
XSN File Structure
I’vre pored through the underlying file structure of InfoPath form templates and can confirm that the organization is virtually unchanged. An “XSN” file is still just a CAB archive as created via the System.IO.Packaging namespace.
The CAB archive still contains the same files. At their heart is the “Manifest.xml” file which defines overall structure and constraints. In only a few places has the schema been modified to accomodate new functionality. Notably, conditional formatting and rules are more tightly combined.
The good news here is that any legacy code that generates InfoPath 2007 form templates can be amended to support InfoPath 2010 relatively painlessly.
Workflow Forms
When working with SharePoint workflows based on InfoPath, the four custom form types are unchanged. Association, instantiation / initialization, change, and task forms function as before.
VSTA / VSTO Code
If you need to customize your form through managed code, the process is the exact same as before. Despite SharePoint 2010 being built on the .NET 3.5 SP1 framework, managed code for InfoPath 2010 is still compiled as a 32-bit .NET 2.0 assembly.
This has several implications. First, this means that you won’t be using LINQ, WCF, CodeContract, or any other powerful .NET 3.0+ features. Second, InfoPath managed code is not optimized for x64 architectures. Moreover, the object model exposed by InfoPath to Visual Studio Tools for Applications / Office is completely unchanged.
What’s the Same
Before diving too deep into the new features of InfoPath Forms Services, I’d like to highlight a few things that are the same. These aspects should be familiar to MOSS / InfoPath 2007 veterans, allowing you to get up to speed more quickly.
XSN File Structure
I’vre pored through the underlying file structure of InfoPath form templates and can confirm that the organization is virtually unchanged. An “XSN” file is still just a CAB archive as created via the System.IO.Packaging namespace.
The CAB archive still contains the same files. At their heart is the “Manifest.xml” file which defines overall structure and constraints. In only a few places has the schema been modified to accomodate new functionality. Notably, conditional formatting and rules are more tightly combined.
The good news here is that any legacy code that generates InfoPath 2007 form templates can be amended to support InfoPath 2010 relatively painlessly.
Workflow Forms
When working with SharePoint workflows based on InfoPath, the four custom form types are unchanged. Association, instantiation / initialization, change, and task forms function as before.
VSTA / VSTO Code
If you need to customize your form through managed code, the process is the exact same as before. Despite SharePoint 2010 being built on the .NET 3.5 SP1 framework, managed code for InfoPath 2010 is still compiled as a 32-bit .NET 2.0 assembly.
This has several implications. First, this means that you won’t be using LINQ, WCF, CodeContract, or any other powerful .NET 3.0+ features. Second, InfoPath managed code is not optimized for x64 architectures. Moreover, the object model exposed by InfoPath to Visual Studio Tools for Applications / Office is completely unchanged.
