Author: Suzanne George, Senior Technical Architect, Perficient
If you are looking to upgrade your SharePoint 2010 site to SharePoint 2013, you may be wondering how to deal with your existing InfoPath developed forms. After much Bing searching, there just isn’t a lot out there to help you — even from Microsoft. Recently, I was given the challenge to upgrade several InfoPath forms to SP2013 and found the process less painful than one might imagine.
First and foremost InfoPath 2013 supports Visual Studio 2012! I can’t tell you how nice it is to have a full, robust, development environment. The forms I set out to upgrade had the following features:
- Fairly large schema with 7-8 views and lots of InfoPath rules
- Code behind (approx 1500 lines) to do customized tasks
- Visual Studio Workflows activated on a SharePoint list
- Deployed via Central Administration and activated via Feature on a specific site/list
- Developed on a machine named ‘InfoPathDev.SomeCompany.com’ (for the purposes of this article)
Tools you will need in order to develop the form in InfoPath 2013:
- SharePoint Server 2013
- InfoPath 2013
- Visual Studio 2012
- Visual Studio Tools for Applications 11 Add-On
- NotePad ++ (or equivalent editor)
- WinGrep
Steps I took to upgrade my forms. Yours may vary depending upon your development environment.
Step 1 – Prep the form
Make sure you have all of the current source code and form data and that you have ‘exported source files’ we are going to need to edit a few of the files manually. (how to do this)
Step 2 – Verify SharePoint 2013 User Profile Service
I had a bit of trouble getting SharePoint User Profile and User Group information and after some research it was an issue with the User Profile Service configuration. Make sure this is setup and functioning before beginning the migration process.
Step 3 – Copy the form over to the new development platform
This sounds simple and easy – but wait not so fast. For those of you using code-behind in your forms changing the folder names of the Code behind is a royal pain and can cause much hair pulling. To make life easy for you copy the folder and code behind to the exact same folder structure on the new development server. If this isn’t possible here is a guide to help you move the code behind to the new location with as little pain as possible:
- Copy the xsn files and code behind folders to the new location (ie: c:\Test\InfoPath). For example: c:\test\InfoPath\xsnFiles for the exported source files and c:\test\InfoPath\xsnCode for the code.
- Open the form in design view by right-clicking on the c:\Test\InfoPath\xsnFiles\manifest.xml file and clicking design.
- Click on the developer tab.
- Click on language.
- Click ‘browse’ to navigate to the new folder and you should see the new ‘csproj’ file there.
NOTE: If you don’t see the csproj file, you will need to click on the ‘Remove Code’ and add the code back. If you don’t see the csproj file you will have to create a new VS project and manually copy your .cs files and re-link your references.
- Save/Close the form.
NOTE: Your form may recompile back into a single xsn file when you save the form. Be sure to re-export source files before continuing.
Step 4 – Modify the Manifest.xml file
In my case the actual server name changed and although I was using data connection files in a SharePoint list, I was unable to publish because the form had hard-coded the development server name for all of the connections. I thought I could simply modify the data connections and relink them to the new server, but unfortunately this didn’t work out so well for me.
- Open your favorite editor and open the Manifest.xml file. (Make sure it is not open in InfoPath Designer)
- Replace all occurrences of the old dev host name with the new development server name: for example, replace InfoPath2010devHost with InfoPath2013devHost.
- You may have had a different publishing host server name such as shptdev.domain.com, if so, replace all occurrences of the publish name with the new host name as well.
- Save the file and exit.
Step 5 – Update the User Profile Service data connections
If you have data connections to the User Profile Service, you may (or may not know) that the account you used when setting up the data connection is hard-coded in the data connection. Wherever your data connections are stored look for the file with a name like GetUserProfileByName… and look for the xml property <tns:GetUserProfileByName>. Be sure the name is a valid user you want to use – in our case we changed it to a generic user called ‘InfoPathUser’.
Step 6 – A quick look for the old dev hostname in other files
Use WinGrep to search through all the xml files and/or data connections for links to your old server names. I generate my data connections via powershell so I didn’t have many changes. This is especially helpful when migrating from a dev environment to test and production.
Step 7 – Re-compile any code behind
Open the form in design view and open the code behind using the ‘Code Editor’ from the developer tab. You will need to change the target framework to .Net 4.5 before compiling.
- Double-Click on the project properties.
- On the application tab, change the target framework.
- Save the file.
- Check your references!! If they don’t link correctly, you will need to fix them. You can do this via Visual Studio or by editing the csproj file for the project – either way works.
- Compile – but do not close Visual Studio.
Step 8 – Publish the form
Go back to the InfoPath Designer and publish your form… it should all work.
Step 9 – Check your form
I found in one or two cases my data connection filter rules got corrupted during the migration and I had to delete / re-create them. Double check your filters and rules to make sure everything is working properly.
That’s it… Your form is migrated. The only issue I have seen so far is I have to keep changing the code behind to use the target framework of .Net 4.5 when I open the form in design view and want to publish. I am still working on the permanent fix for that one and will update the blog when I found the solution that works.
To get more InfoPath tips and tricks, see my presentation at SharePoint Fest in Denver on Tuesday, March 19th! In the meantime, check out this blog post for more on InfoPath.
If you have questions or comments, please feel free to contact me on Twitter @spgenie.
About Suzanne George
Suzanne is an expert in Microsoft SharePoint and .Net technologies. Suzanne is a Microsoft Certified Technology Specialist: Web Applications and SharePoint Application Developer who presents at various SharePoint conferences and has participated in Microsoft’s “Born to Learn” blog and is a contributing author of SharePoint 2010 books and an avid speaker at Technology conferences.
Suzanne has been in internet technologies since 1994 and has been working on SharePoint for 10 years. She has led and participated on teams doing analysis, design, development, implementations, and enhancements and testing of applications in these areas: Microsoft SharePoint, ESRI ArcServer, and custom developed Internet web sites.
Can you use InfoPath 2013 to develop forms for SharePoint 2010? I ask because I’m running into some issues and it seems it’s not backward compatible for this type of env.
In 2013 are you using claims authentication? If so, I had several issues getting the user profile service to work. What I had to do was the following in the code behind…
public void FormEvents_Loading(object sender, LoadingEventArgs e)
{
string currentAccName = “domainName\\” + SPContext.Current.Web.CurrentUser.Name;
DataSources[“GetUserProfileByName”].CreateNavigator().SelectSingleNode(“/dfs:myFields/dfs:queryFields/tns:GetUserProfileByName/tns:AccountName”, NamespaceManager).SetValue(currentAccName);
this.DataConnections[“GetUserProfileByName”].Execute();
string querystr = “/dfs:myFields/dfs:dataFields/tns:GetUserProfileByNameResponse/tns:GetUserProfileByNameResult/tns:PropertyData/tns:Values/tns:ValueData/tns:Value”;
XPathNodeIterator rows = DataSources[“GetUserProfileByName”].CreateNavigator().Select(querystr, NamespaceManager);
}
No you can’t develop infopath 2013 forms and use them in SP2010, the classes and .Net libraries are not compatible.
Hi Suzanna,
The code you specified to get the user profile information working with the infopath form, please advise where and how I insert this into my form.
Thanks
Correct, it is not backwards compatible. InfoPath 2013 uses the .Net 4 framework and SharePoint 2010 uses 3.5
Suzanne,
Would you have a small sample InfoPath 2013 project that uses VS2012 to write code for say buttons? We develop in Visual Basic in VS2012 and thought this would be something simple to do and it’s turning out to not be. We have created a sample InfoPath project and when we try and code using VB in VS2012, nothing seems to work like we are use to. For instance we can’t even access say some radio buttons or text boxes on the InfoPath form. Is there any simple project you have that could try out?
Thanks.
Can you point me to some instructions on how to publish an InfoPath 2013 form via Central Admin and then use features within sites to enable the forms for specific lists?
Other question: we are experiencing performance issues with InfoPath 2010 forms. Any pointers for troubleshooting? The list contains 180 columns of which 16 look-up columns. The page takes 6 seconds to load.
Hoping this posting is still active and that I may get a reply but, will this process work for a situation where an SP2010 farm is upgraded to an SP2013 farm by means of transferring the content database, along with all of it’s site collections and leaving those collections in SP2010 compatibility mode? We’re having issues with InfoPath forms and workflows no working properly, but the site collections and the associated InfoPath forms and workflows are still in SP2010 compatibility mode.
Great article by the way!