Yep, that is correct. Often the 'code' approach is all you can do (add/update fieldlinks with code).
Regards, Paul Turner Senior Solutions Specialist M: 0412 748 168 P: 08 8238 0912 F: 08 8234 5966 A: 66 Henley Beach Road, Mile End SA 5031 E: paul.tur...@dws.com.au<mailto:paul.tur...@dws.com.au> W: www.dws.com.au<https://webmail.dws.com.au/owa/UrlBlockedError.aspx> <http://www.msteched.com/australia/Public/default.aspx> ADVANCED BUSINESS SOLUTIONS LTD This email and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient you have received this email in error and are requested to delete it immediately. Any opinion expressed in this e-mail may not necessarily be that of DWS Pty Ltd. Please consider the environment before printing this email. ________________________________ From: ozmoss@ozmoss.com [ozm...@ozmoss.com] On Behalf Of Sezai Komur [sharepointse...@gmail.com] Sent: Tuesday, 21 July 2009 12:55 PM To: ozmoss@ozmoss.com Subject: Re: Upgrading solution for CT You shouldn't be modifying a content type definition in a solution upgrade, it isn't supported. Updating Content Types http://msdn.microsoft.com/en-us/library/aa543504.aspx See this note: [http://i.msdn.microsoft.com/Aa543504.important(en-us,office.12).gif]Important: Do not, under any circumstances, update the content type definition file for a content type after you have installed and activated that content type. Windows SharePoint Services does not track all the changes made to the content type definition file. Therefore, you have no reliable method for pushing down all the changes made to site content types to the child content types. Content Type definitions implemented as Features are read when the content type is provisioned, changing the feature file after creating a content type should be avoided. Once created you need to modify the content type programmatically. Content Type Change Control http://msdn.microsoft.com/en-us/library/ms434692.aspx This page has a note about read-only content types. Setting the CType to read-only in the UI most probably sets the SPContentType.ReadOnly property to true http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spcontenttype.readonly.aspx Now back to your original question... Create a Feature Receiver to programatically update your content type in use, you can then switch the read-only property if needed, or switch it in the UI before activating your feature. You could also modify your content type directly in the UI, the easy way, afaik this is supported. It comes back to the type of change you are making to your content type really.... Sezai. On Tue, Jul 21, 2009 at 11:05 AM, Paul Noone <paul.no...@ceosyd.catholic.edu.au<mailto:paul.no...@ceosyd.catholic.edu.au>> wrote: Hi all, Quick question. If a CT is set to read-only through the UI will it still be updated via a solution upgrade?! Regards, Paul Online Developer, ICT CEO Sydney ________________________________ Support procedure: https://www.codify.com/lists/support List address: ozmoss@ozmoss.com<mailto:ozmoss@ozmoss.com> Subscribe: ozmoss-subscr...@ozmoss.com<mailto:ozmoss-subscr...@ozmoss.com> Unsubscribe: ozmoss-unsubscr...@ozmoss.com<mailto:ozmoss-unsubscr...@ozmoss.com> List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: ozmoss@ozmoss.com Subscribe: ozmoss-subscr...@ozmoss.com Unsubscribe: ozmoss-unsubscr...@ozmoss.com List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists -------------------------------------------------------------------------------- Support procedure: http://www.codify.com/lists/support List address: ozmoss@ozmoss.com Subscribe: ozmoss-subscr...@ozmoss.com Unsubscribe: ozmoss-unsubscr...@ozmoss.com List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists
