<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Document Set on Matt Thornton</title>
    <link>https://matt-thornton.net/tags/document-set/</link>
    <description>Recent content in Document Set on Matt Thornton</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Thu, 15 Sep 2011 12:57:34 +0000</lastBuildDate><atom:link href="https://matt-thornton.net/tags/document-set/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>More fun with deploying Document Sets via XML</title>
      <link>https://matt-thornton.net/tech/sharepoint/more-fun-with-deploying-document-sets-via-xml/</link>
      <pubDate>Thu, 15 Sep 2011 12:57:34 +0000</pubDate>
      
      <guid>https://matt-thornton.net/tech/sharepoint/more-fun-with-deploying-document-sets-via-xml/</guid>
      
        <description>&lt;p&gt;To finish a set of posts about the fun I&amp;rsquo;ve had in deploying document sets as XML content types, here&amp;rsquo;s a fun little &lt;span style=&#34;text-decoration: line-through;&#34;&gt;bug&lt;/span&gt; vagary I encountered. In the &lt;a href=&#34;http://www.youtube.com/watch?v=t3bynskrnpA&#34;&gt;video walkthrough&lt;/a&gt;, there&amp;rsquo;s a section on deploying the custom WelcomePage to your site, and provisioning some WebParts automatically to that page.&lt;/p&gt;
&lt;p&gt;You achieve this in the Elements.xml file of your WelcomePage module by including some &lt;AllUsersWebPart&gt;&amp;gt; sections. Within those tags, you enter the definition of the webpart, and you can reuse the built-in webparts.&lt;/p&gt;
&lt;p&gt;(Hint: to get at the required definition for &lt;strong&gt;built-in SP webparts&lt;/strong&gt;, find the webpart in the Webparts Gallery in Site Settings, save a copy of the file to your hard drive (as a .dwp file) and then open that file in Visual Studio. You get the required info. Neat.)&lt;/p&gt;
&lt;p&gt;You can then deploy your feature, and assuming you&amp;rsquo;ve &lt;a href=&#34;https://www.matt-thornton.net/tech/sharepoint/provision-document-set-xmldocuments-and&#34;&gt;covered all the bases&lt;/a&gt; your Document Sets, with custom Welcome Page should be deployed. But here&amp;rsquo;s a problem. Let&amp;rsquo;s say you make some changes to it, and redeploy the feature. You may experience one of a series of behaviours:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;None of your changes are displayed&lt;/li&gt;
&lt;li&gt;Your changes are displayed OK&lt;/li&gt;
&lt;li&gt;You end up with multiple webparts on your custom Welcome Page.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;It&amp;rsquo;s the third issue I tripped over, and it seems to occur if/when you manually deactivate and reactivate your feature (using the “deploy” feature from VS doesn&amp;rsquo;t seem to cause this.) It makes some sense - the Elements.xml file says “add these webparts to this page”. Assuming you&amp;rsquo;ve not added any FeatureDeactivating event receiver to remove the webparts when the feature is deactivated, well, you&amp;rsquo;ll end up with lots of webparts on the one page.&lt;/p&gt;
&lt;p&gt;This being the case, how do you actually go about getting rid of the extra webparts on the page? Retracting the solution doesn&amp;rsquo;t help. You could completely bin your site content type, site or even site collection. That would probably do it. But it&amp;rsquo;s a bit drastic. The alternative? Update the database manually. You can decide if this is more drastic than the previous options.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;To be clear, you should never, ever, on any account, ever, manually hack the SharePoint content database!&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;But if you want to do it, here&amp;rsquo;s how:&lt;/p&gt;</description>
      
    </item>
    
    <item>
      <title>Updating declarative XML content types</title>
      <link>https://matt-thornton.net/tech/updating-declarative-xml-content-types/</link>
      <pubDate>Thu, 15 Sep 2011 11:37:01 +0000</pubDate>
      
      <guid>https://matt-thornton.net/tech/updating-declarative-xml-content-types/</guid>
      
        <description>&lt;p&gt;Becoming a SharePoint developer is always a journey - every new day you spend doing something, the more you learn. More often than not, the more “little subtleties” you uncover about the great wide SharePoint platform. I recently tripped over one such example. This “issue” is not new in SharePoint development - it certainly goes back as far as MOSS2007, but unless you&amp;rsquo;re actually doing it, it&amp;rsquo;s not something you&amp;rsquo;d instinctively just know.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Creating content types via XML Visual Studio&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;As soon as you start building SharePoint solutions of any real size and complexity, you&amp;rsquo;ll quickly learn that creating fields and content types via the UI, or SharePoint Designer, is not a great solution. For instance, there&amp;rsquo;s no &lt;em&gt;supported&lt;/em&gt; way to move a SPD designed solution from e.g., Dev to Live - that is, with SPD, you design directly against live. This can be OK for initial deployments, but as soon as the system has data in and you need to start potentially breaking things, this is not a good place to be in. The alternative to this is develop Visual Studio solutions and features, which are deployable pretty much wherever you&amp;rsquo;d like. You can define &lt;a href=&#34;http://msdn.microsoft.com/en-us/library/gg295290.aspx&#34;&gt;fields and content types in XML&lt;/a&gt;, and when you&amp;rsquo;re finished, package it all up and deploy. Simple, right? Well, no, not necessarily - as &lt;a href=&#34;https://www.matt-thornton.net/tech/provision-document-set-xmldocuments-and&#34;&gt;I mentioned recently&lt;/a&gt;, this process is not without its bugs and issues.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve deployed a few solutions in this way, and was (until today) singing the praises of deploying content types via XML, thinking how wonderful it was to have the flexibility to build in dev, test and then deploy (i.e. what you can&amp;rsquo;t do with SPD). And of course, if you make any changes, you can update your solution and hey presto, nice neat update.&lt;/p&gt;</description>
      
    </item>
    
    <item>
      <title>Provision Document Set &#43; XMLDocuments and ???</title>
      <link>https://matt-thornton.net/tech/sharepoint/provision-document-set-xmldocuments-and/</link>
      <pubDate>Mon, 12 Sep 2011 08:18:36 +0000</pubDate>
      
      <guid>https://matt-thornton.net/tech/sharepoint/provision-document-set-xmldocuments-and/</guid>
      
        <description>&lt;p&gt;SharePoint development is fraught with frustrations. Little things that should be simple, end up taking far longer than they should. Take this example. I&amp;rsquo;m trying to provision a Document Set content type via XML in a VS feature. I was using &lt;a href=&#34;http://www.youtube.com/watch?v=t3bynskrnpA&#34;&gt;this video&lt;/a&gt; and the &lt;a href=&#34;http://msdn.microsoft.com/en-us/library/gg581064.aspx&#34;&gt;supporting article&lt;/a&gt; as a guide. I get all the way through, and everything is working&amp;hellip; &lt;em&gt;ish&lt;/em&gt;. That is, the Document Set content type is created, but the extra stuff to do with it, such as the custom welcome page and the extra properties (shared fields, etc.), defined in the XmlDocuments section of the content type, don&amp;rsquo;t appear. No manner of tweaking and reducing code had any effect. I got a hold of the source code from the tutorial - lo and behold, that works fine. So the theory is sound, it &lt;em&gt;should&lt;/em&gt; work, and so something somewhere was different. The job was tracking down said difference.&lt;/p&gt;</description>
      
    </item>
    
  </channel>
</rss>