SharePoint Products > SharePoint 2010 Forums > SharePoint 2010 - Using SharePoint Designer, Infopath, and other customization > Content Deployment between different environments (InfoPath, SharePoint Designer Workflow, Content Type) in SharePoint 2010

Answered Content Deployment between different environments (InfoPath, SharePoint Designer Workflow, Content Type) in SharePoint 2010

  • Monday, October 31, 2011 10:40 PM
     
     

    I have read many discussions on this (or similar topic) and still would like to post this again to see if I can get real answers:

    1. I have InfoPath forms.
    2. These forms are published as content types. 
    3. I have reusable SharePoint Designer workflows.  
    4. I have document libraries created to use these content types.
    5. I have security groups.

    How do I move these things from DEV to TEST, UAT all the way into PROD.  

    As to #3:  GUID is driving me crazy.

Answers

  • Friday, November 11, 2011 12:42 PM
     
     Answered

    Technically, while I "think" it's possible to include the InfoPath form in the WSP, but I have always done this separately.  

    So I divide the deployment into two stages:

     

    1. The WSP only contains the Content Type and Site Columns.  And I only ever re-deploy the WSP package if I have new promoted columns.  I almost never create new Content Types.

    2. I deploy InfoPath via the Publish wizard, since I'm pretty sure it tweaks the form template prior to publishing it to SharePoint regarding the domain of the form.  This logic isn't something I want to do myself in my WSP.

    3. In InfoPath you can deploy directly to a list.  In this case, just point your form to publish to your production site's Forms Library.  Select the new Content Type that you had deployed via step #1.

    4. If you deploy via Central Administration, form server will push the form back to /FormServerTemplates/ - in your production Form Library, you should first set up manage content types, add your new Content Type, and then change the template for your content type to point to the template deployed via Central Administration in /FormServerTemplates/myformtemplate.xsn

     

     


    jliu - johnliu.net - sharepointgurus.net

All Replies

  • Tuesday, November 01, 2011 1:47 PM
     
     

     

    The only way I have ever got all the environments to obey my command regarding content types is to use Solution Packages.

    Try this development workflow.

    1. Create InfoPath form in DEV, use Content Type, and Site Columns.

    2. Once the Content Type and Site Columns are created, package them into a WSP.  From now on, always deploy content type and site columns using WSP.  This forces All the GUIDS to be identical across all farms, which makes everything work nice.

    3. Reusable SharePoint designer workflows can be tied to these content type / site columns, so can document library.

    4. Deploy package to TEST, you can create document libraries with feature as well, or configure them manually.  I deploy InfoPath forms to TEST by publishing from InfoPath to the TEST environment, depending on whether you are doing:

    Site content type: publish to the destination list - it should automatically pick up the content type since the GUID are the same.  Site columns will match too.
    Central admin forms - deploy via central admin, this places the form template back in /FormTemplates/ on the root site, hook this back using Content Type / advanced / form template in each list.

    InfoPath forms always have data connections (since InfoPath can't do anything), you should convert all data connections to connection files hosted relatively on each DEV, TEST, etc environment, this way you don't need to modify the form template, and depending which environment it's published to, it'll go and find the right sets of data.

     

     

    Problems:

    Oh boy workflows.

    I always hate deploying workflows.  Jumped on Nintex a long time ago sorry :-(

    There are really complex solutions for this.  I often wonder if I'd just suck the workflow from SPD into VS.NET and then go forward with a VS.NET workflow.  But anyway, these steps from Stuart Roberts looks pretty solid.

    http://www.stuartroberts.net/index.php/2011/01/19/package-deploy-sharepoint-designer-workflow/

     

    Security groups.

    Use Active Directory groups.  Don't muck around with SharePoint groups unless you really have to.

     

    Anyway, this is how "I" do it, but I'm super keen to hear what other people do!

     

     


    jliu - johnliu.net - sharepointgurus.net
  • Wednesday, November 02, 2011 4:09 PM
     
     
    Can you expand on packaging the InfoPath content type to a WSP?... there are some solutions out there but they seem to apply to SP 2007 in particular. Any links/references/discussion to the approach you took?
    Alex Talarico
  • Wednesday, November 02, 2011 4:27 PM
     
     

    In VS.NET, I use the tools in CKS extensions to import content type and site columns into a new empty WSP project.

    I can try to sit down and write the steps down over the weekend, which parts do you want to know about in detail?


    jliu - johnliu.net - sharepointgurus.net
  • Thursday, November 03, 2011 4:45 PM
     
     

    John, once the Content Type and Site Columns are created, package them into a WSP? how do you package them into a WSP? saving the entire site as a template?

  • Monday, November 07, 2011 11:14 PM
     
     

    I use VS.NET 2010.

    Here are some screenshot I took from my environment.

    http://johnliu.net/blog/2011/11/7/infopath-packaging-site-columns-and-content-types.html

     


    jliu - johnliu.net - sharepointgurus.net
  • Thursday, November 10, 2011 11:53 PM
     
     

    Thanks John.

    Your post is really good. It helps me a lot. With your help, I can package InfoPath generated content types and site columns successfully. this is all good.

    Do you know how to include InfoPath forms to be part of the WSP package?

    After the content types and site columns were created using a WSP package, I tried to upload my InfoPath forms manually to match the path required by the content type.  It worked partially. The InforPath form was always opened in a browser, even I have changed the document library setting.

    To further investigate this problem, I added another InfoPath designer published content type to the same document library. When I tried to create an form using that content type. the form was open in the browser.

    so, I guess I cannot just update the infopath forms, I have to somehow register them.

    Your thoughts?

  • Friday, November 11, 2011 2:48 AM
     
     

    Try and verify if you can actually open in client.

    http://server/library/123.xml?OpenIn=Client

    http://msdn.microsoft.com/en-us/library/ms772417.aspx

     

    When you export the content type it may have embedded the OpenIn=Browser somewhere in the definition.  If this isn't what you are after I'd check the content type XML


    jliu - johnliu.net - sharepointgurus.net
  • Friday, November 11, 2011 6:50 AM
     
     

    John, do you have it functioning in your test? here is content type XML.

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

      <ContentType ID="0x010101005DE00AA0EF834043A90C4AF917442152" Name="POC4Deployment" Description="Fill out this form." Group="Microsoft InfoPath" Inherits="true" Hidden="false" ReadOnly="false" Sealed="false">

        <DocumentTemplate TargetName="/Form Definitions/POC4Deployment.xsn" xmlns="http://schemas.microsoft.com/sharepoint/"/>

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

          <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/xmlform">

            <XmlDocument xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/xmlform">

              <Namespaces>xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2011-11-11T05:27:26"</Namespaces>

            </XmlDocument>

          </XmlDocument>

          <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">

            <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">

              <Display>DocumentLibraryForm</Display>

              <Edit>DocumentLibraryForm</Edit>

              <New>DocumentLibraryForm</New>

            </FormTemplates>

          </XmlDocument>

        </XmlDocuments>

      </ContentType>

    </Elements>

  • Friday, November 11, 2011 12:42 PM
     
     Answered

    Technically, while I "think" it's possible to include the InfoPath form in the WSP, but I have always done this separately.  

    So I divide the deployment into two stages:

     

    1. The WSP only contains the Content Type and Site Columns.  And I only ever re-deploy the WSP package if I have new promoted columns.  I almost never create new Content Types.

    2. I deploy InfoPath via the Publish wizard, since I'm pretty sure it tweaks the form template prior to publishing it to SharePoint regarding the domain of the form.  This logic isn't something I want to do myself in my WSP.

    3. In InfoPath you can deploy directly to a list.  In this case, just point your form to publish to your production site's Forms Library.  Select the new Content Type that you had deployed via step #1.

    4. If you deploy via Central Administration, form server will push the form back to /FormServerTemplates/ - in your production Form Library, you should first set up manage content types, add your new Content Type, and then change the template for your content type to point to the template deployed via Central Administration in /FormServerTemplates/myformtemplate.xsn

     

     


    jliu - johnliu.net - sharepointgurus.net
  • Monday, November 14, 2011 6:19 AM
     
     

    Hi John,  thanks for your help.

    I think I figured out why my form was open in InfoPath filler other than browser

    I think you were referring to property RequireClientRenderingOnNew.

    What I found out is that (at least for me) you can set it to false in your content definition before packaging it up, this value is still true (i used SharePoint manager to dig this out).

    So i had to use the following PowerShell script to manipulate this property.

    $TargetSite ="http://xxx.xxx.xxx/

    $name ="MyContentType"

    $site = Get-SPSite $TargetSite

    $web = $site.RootWeb 

    $ct = $web.ContentTypes[$name]

    $ct.RequireClientRenderingOnNew = $false

    $ct.update()

  • Monday, November 14, 2011 6:30 AM
     
     

    Ah that's good to know.  It's strange that it doesn't work properly in the package.  

    http://msdn.microsoft.com/en-us/library/aa544268.aspx

    Did you try using "FALSE" instead of "false"?  

     

    I guess if the solution requires code, you can also add a feature receiver in your WSP package to do this on the feature activated event of your feature.


    jliu - johnliu.net - sharepointgurus.net
  • Tuesday, November 22, 2011 3:38 AM
     
     

    I wanted to quickly update this thread.

    When you publish via Central Administration - it likes to control the Content Type ID, this makes my approach above very tricky.

     

    At the moment, for central administration forms, I publish via SharePoint and don't use my own package.

    Please do test in your environment.


    jliu - johnliu.net - sharepointgurus.net