Thanks for the update, I’ll have to check that. Wes
From: ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of Nigel Witherdin Sent: Thursday, September 12, 2013 4:54 PM To: ozMOSS Subject: Re: Managed Metadata Fields Yeah I do the same thing and hook the mm field up to the termset through code, however if your field declaration includes the WebId or SiteId attributes, or the properties shown in my first post, then the field will appear to correctly hook up to the termset, but won't behave correctly. Instead what will happen is the correct value will be written to he hidden note field in the expected format of "guid | label", but the associated mm or multi mm field won't be set correctly (it won't have a wssid value etc). So i suggest either generate your field declaration by hand and leave this stuff out, or edit the generated declaration and remove these attributes and properties Sent from my iPad On 13/09/2013, at 1:46 AM, "Wes MacDonald" <wmacdon...@like10.com<mailto:wmacdon...@like10.com>> wrote: Hi, In the past I used these two blog posts: http://blogs.msdn.com/b/sharepointdev/archive/2012/04/16/programmatically-create-a-managed-metadata-list-column-mohammed-faizan.aspx http://www.wictorwilen.se/Post/How-to-provision-SharePoint-2010-Managed-Metadata-columns.aspx They both use a feature receiver to link everything up. Wes From: ozmoss-boun...@ozmoss.com<mailto:ozmoss-boun...@ozmoss.com> [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of Nigel Witherdin Sent: Wednesday, September 11, 2013 9:39 PM To: OzMoss Subject: RE: Managed Metadata Fields oops that went a bit early. Finished off below: ________________________________ From: nigel_wither...@hotmail.com<mailto:nigel_wither...@hotmail.com> To: ozmoss@ozmoss.com<mailto:ozmoss@ozmoss.com> Subject: Managed Metadata Fields Date: Thu, 12 Sep 2013 01:31:56 +0000 Hey guys, Not a question this time - just a tip (NB I am working with SP2010, VS 2010). When I am creating solutions, I generally put together a proof of concept which includes the content types, lists, etc, which I then save as a WSP, and then import into Visual Studio to add the rest of the customizations. I generally only import the artifacts I need, not everything for the site, as I like my solutions to be as lean as possible. I have found however that with Managed Metadata fields pulled in this way, the field definition contains the environment specific properties: <Property> <Name>SspId</Name> <Value xmlns:q1="http://www.w3.org/2001/XMLSchema"; p4:type="q1:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance";>7437670e-a4f0-4f53-99ed-a9561766f7c5</Value> </Property> and <Property> <Name>TermSetId</Name> <Value xmlns:q2="http://www.w3.org/2001/XMLSchema"; p4:type="q2:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance";>9a2f696a-af3c-49cf-b186-1031f3f67113</Value> </Property> This means when you deploy this field onto another site collection using different termset Id's the field no longer works. A better way is to edit the field definitions (and schema.xml files if using list instances) and remove every property of a manged metadata field except for "TextField". Alternatively, you can import your field definitions using the CKS toolkit, and it only brings across the "TextId" property. One last thing, edit your field definitions and remove all occurrences of the "Version" property (e.g. Version="1") - having a version defined on a field often means that if you try and update it through the UI after deployment, you will get an error message back saying "field has been modified by another user". I would be interested to hear if others develop and package up field defs, content types etc through any other means?? Hope this helps someone out there.... _______________________________________________ ozmoss mailing list ozmoss@ozmoss.com<mailto:ozmoss@ozmoss.com> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
_______________________________________________ ozmoss mailing list ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
