November 22, 2013
Posted by on
In an earlier post, https://suehernandez.wordpress.com/2013/11/22/deploy-infopath-2010-with-code-as-solution-feature/, I explained how to implement an InfoPath 2010 form as a Feature in SharePoint 2010.
As I was trying to deploy this feature, I kept getting the error:
Registering of form templates deployed through object model is not supported
It turns out that what happened is that up until that point I had been deploying my InfoPath forms through Central Administration. It’s easiest and usually quickest to do it this way (although once you deploy the same form like 50 times it starts getting really slow to deploy).
But I had not changed the “Identifier” per se of the form. Let me show you a couple of pictures that shows what I’m talking about:
Where it says “urn:schemas-microsofr-com….” that is the identifier of the form. If you publish the form, and then copy it and change the name of it, it does NOT change the identifier. So if you’ve already got that ID in Central Admin under Manage Form Templates, and then you try to deploy the same form as a feature, you get this error message.
One of the ways you can fix this is to either manually change this URN ID, or just open up the form in InfoPath Designer in design mode and do a Save-As. It will automatically change your ID to match the new name of the form.
In the mean time, delete the form from Central Admin and try your Solution Deployment again.
November 22, 2013
Posted by on
This one will be somewhat long of a post. Here we will examine deploying an InfoPath 2010 form with CodeBehind as a custom Feature to SharePoint 2010.
- Change the properties of your form to Full Trust
- Publish your form to a SharePoint Server
Publish Step 1
- Choose your URL to the site where you’re going to be using the file. Note that it will put this form in the Form Templates (url is FormServerTemplates) library at the top of your Site Collection
Publish Step 2
- Make sure that it is checked off to enable the form to be filled out by a browser, and choose Administrator Approved Template
Publish Step 3
- Choose the location on your desktop or local computer or shared drive where you want to save the Published form template to
Publish Step 4
- Create your Visual Studio solution. Create it as a SharePoint 2010 Empty SharePoint Project
Create new Empty SP Project
- Choose to deploy as Farm Solution
Deploy as Farm Solution
- Add a Feature to the project
- Rename the feature to something that makes more sense, so you can more easily find it later through PowerShell or in the 14 hive
- Open the feature in Visual Studio into Design view and set the properties of the feature at the top.
Set Properties of Feature
- Add a Module to the project
- Rename the module and remove the Sample.txt file
Rename Module and remove Sample txt
- Add your Module Files. Here you will be adding the published form that you completed in Step 5 here, as well as the dll. (You can get the .dll by going into design view in InfoPath, pressing Publish, and pressing Export Source Files – give it a folder to put the source files in, and find your .dll in there)
Note that I have a little naming change here versus what I have in step 5. I am showing you a “real” project file and had to blot out part of the name. But this will be your published file – not the file you use to make the changes to the form.
Add Module Files
- Open the Elements file in the NewFormModule. You will have to make changes. Here’s the file as it looks before:
and here’s the file as it looks after:
- Open back up the Feature in Design mode, and press the button to switch it to Manifest mode. Expand Edit Options and add the 2 properties shown below, with your Feature Name and your Published InfoPath form name as the values:
Update the Manifest
- Get the Properties window up for the Feature. You will be adding a Receiver Assembly and a Receiver Class
ReceiverAssembly=”Microsoft.Office.InfoPath.Server, Version=18.104.22.168, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
Feature Props add Receiver info
- OPTIONAL: Add Activation dependency. NOTE: if you are going to mark your feature as Hidden=TRUE, you cannot add this dependency. We will discuss later why you may want to make your feature Hidden.
Feature Activation Dependencies
- Now in your solution explorer, you will want to highlight the Elements file and get the properties. Clear out the Deployment Path and make sure it’s of type ElementManifest
- Next highlight the XSN published form and get its properties. Clear the Deployment Path and make sure it is of type ElementFile
- Repeat the previous step for the DLL file
- Open up your Feature in Design mode just to look at it. Your Manifest file should look similar to the following (if you added the Activation Dependency):
Making the feature Hidden
The problem with adding the published file to Central Administration – Managed Form Templates is twofold: (1) It puts in every version you create into the manifest; and (2) It makes the feature available to EVERY site collection in your Farm. Similarly, if you don’t make the feature Hidden, all site collections will be able to see this feature.
Depending on your project, you may opt to hide the feature so that no one can turn it on, and only activate it to the Site Collection using PowerShell.
If you choose to make your feature hidden, you cannot have the Activation Dependency of the Enterprise Features. Just realize this means is that if you don’t have Enterprise Features turned on, this Content Type will not work.
Here’s a picture of where you’d make the feature hidden – it’s just another one of the properties on the feature:
Is Hidden is True
Deploy the feature, Activate it, and Use it
Once you deploy the solution package (.WSP file) and activate it to the site collection you’re going to use it in, it will now be a Content Type that you add to your Form Library. Any fields which you promoted in the Publishing process will automatically be added to your Form Library and will sync to the data in the form.
I got bits and pieces from a lot of places, but here’s some main ones that I got a lot of detail from:
October 25, 2013
Posted by on
Wow – I should have recognized this a LONG time ago. But hey, I’m human.
When you use code such as the following:
using (SPSite site = newSPSite(urlToSite))
using (SPWeb web = site.OpenWeb())
// Do something
if you use that code in a Web Part, Application Page, or I think Event Handler – i.e. any code that has Context inside SharePoint – the code runs as expected and will elevate your permissions to the Application Pool account.
However, if you try to use that same code in your Console application, and let’s say you update a list item, and you run it either in debug mode or just “regularly” by double-clicking the exe file, you will notice that last modified by is YOU – NOT your Application Pool account.
This is because there’s no SharePoint context.
Instead, you can create a batch file (like if you have input parameters) and use the “RunAs” method that Windows gives you (example, in Windows Server 2008 R2 you have to hold down Shift and Right-click the batch file, in order to get the Run As option). If you’re setting up the job as a scheduled task through Windows, you simply have to set the account to the Application Pool account and specify that it should run whether or not the account is logged in.