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> 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] 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 > To: 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 > http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
_______________________________________________ ozmoss mailing list ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
_______________________________________________ ozmoss mailing list ozmoss@ozmoss.com http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
