I was wondering if anyone here has any experience with updating the schema.xml file after deployment.  I have a solution that I will outline in this post, but I feel like it is a delicately balanced hack instead of a real solution.  Any Information that you can provide is greatly appreciated!

To begin, I am trying to create a new taxonomy site column, use this new site column in place of an old one in an existing content type, and update the list definition (and all existing lists) to show the new site column instead of the old.

The content type was originally deployed via an elements.xml file.  From what I understand, once deployed this file should never be modified.  So, via code I define my new site column, add the site column to the content type, and delete the old site column from the content type.  I perform an update(true) on the content type so that the change is pushed to all list instances.  At this point, I can go to any list and the new/edit form for each of those lists does not show the old site column but does show the new.  So far so good!

There are two problems at this point.  If I try to create a new list from the definition, I get a list that contains the site column that I deleted AND the new site column.  Also, the deleted site column name still appears in the default view. 

I tried removing the old and adding my new site column to the schema.xml, but this breaks all existing lists that were made from this schema.xml (specifically, it is a taxonomy field and none of the taxonomy fields work after updating).  I can create a new list from the list definition that works fine, but I still need existing lists to work. 

The solution that I ended up on was JUST removing the no-longer-necessary field from the schema.xml, and then adding my new field to the ViewFields list in the schema.xml.  If I do this, everything is happy even though the only mention of the new field in the schema.xml is in the ViewFields section.

So, with all of that said... does this make sense?  Am I doing this the correct way, or does this just work for now... and it will blow up later?

Thanks in advance!

Hi,

This is how I would do that.

1. Make the old field hidden in field xml file. Don't delete the field because it's being used by existing lists. You shouldn't delete a site column from definition while it's being used by lists.
   
2. Deactivate the content type/site column feature which would unprovision the content type/site columns from site collection.
3. Deploy the new WSP solution and active the content type/site column feature which would provision new content type and updated site column. If needed pushed the content type changes in to list level to add newly added field in existing lists.
   
4. If needed would run a script to move data from old to new column
5. Modify existing list views to make sure old field is not showing anywhere in existing lists.
   

At this point I'm happy the new field is added and data is moved to new field and old field is hidden. Now let's focus on removing the old field (if you have energy, time and if you really care about the old field).

• Delete the old field from all existing lists. Remember the old field still exists but not associated with any content type. You need to make sure the old field is not used anywhere is the site before deleting from Visual Studio.
  
• Deactivate the content type/site column feature. Now please make sure the old column doesn't exist in the site. You can use tools like SharePoint manager to find out if the old site column is gone from the site.
• Delete the site column from Visual Studio solution and redeploy.
• Activate the site columns/content type feature.

Simply you need to make sure before deleting any field definition the field is not used anywhere in the s

Thank you for your response!

I understand what you are saying, and it makes sense with what I have seen. 

I do, however, have 2 questions:

1.  Wouldn't removing a field from the content type elements.xml file be against the best practice that indicates that you should not modify the definition file after it has been deployed?

2.  Doesn't this still leave the schema.xml in tact?  If it remains unchanged, future deployments of the list definition will still contain the now-removed field b/c it is used in that schema.xml.

Thanks!

Hi,

I mistyped and removed the first step (remove field from content type) from my last answer. I'm not sure if we are in the same page based on your questions. But Anyway here's my answer:

1. You should not modify the content type elements.xml file from SharePoint Directory (c:\program files\..) - yes this is not suggested. But you can edit the elements.xml file in Visual Studio and deploy. You should not make any changes directly in the file system. And making changes through Visual Studio is good practice and  you can do the changes (in content type, site columns) throughout your project life cycle.
2. You need to make similar changes in List Definition schema file also. If you make changes in Visual Studio - not in file system directly and then deploy the WSP file, then the updated schema file will be deployed and any future lists created based on this list definition will have updated definition. However existing list definition need to be updated to push content type changes.

Thanks again.

I guess I am most confused because I am seeing the opposite of what you describe.

1. Isn't changing the elements.xml via Visual Studio and deploying the same as changing it directly? I have tried numerous times to change a content type elements.xml file and then perform a content type update(true) in code to push the changes to all child content types... and it doesn't change the lists version of the content type.  This is why I thought that guidance of "don't change the definition file" applied to elements.xml altogether after deploying.  Either way, my code approach for getting these fields updated is working, so I can probably just proceed with that approach.
2. This is where it gets very strange.  I see everyone indicate that a schema.xml change does not affect existing lists that were made from a list definition.  I am 100% seeing the opposite of this.  When I update the schema.xml file, my views (in existing lists) change to match the new schema.xml as soon as I deploy the changes.  I don't know if this is working differently in 2013 than it did before.

I do appreciate the help.  It is just very frustrating that things are not working as expected.

Thanks!

Just to confirm:

• You are not making any changes in SharePoint deployed content types/fields?
• You are deploying your content types/fields through Visual Studio? If yes, then why you need to change the xml file directly from file system. You should deploy your changes through Visual Studio. You can make changes in file system directly but is it a good approach??

So if you make your changes directly in file system then I can tell you this is no way a good approach. You should use Visual Studio with a source control to manage deployment/source control etc. You SHOULD always deploy your changes through WSP, but not manual changes in file system files.

Here's any answers:

1. From non-developer (or end-users) point of view it's the same but from a pure developer/architect points of view, it's not recommended. SharePoint is a big enterprise product and making any changes in unsupported way might have adverse effects. You should keep all the custom SharePoint artifacts (content types, features, site columns, master pages etc) in a single place (which is Visual Studio) and deploy by only one means (Powershell command). If you go and make changes directly you are not going through the suggested way of deploying which might be:Make Changes in Visual Studio -> Generate WSP -> Deactive existing Feature -> Uninstall existing feature -> Retract Existing WSP -> Remove Existing WSP -> -> Add new WSP -> Deploy new WSP -> Active Feature. Also the guidance 'do not change definition file' must be followed for SharePoint deployed artifacts. If you have your own artifacts (content types, field etc.) you can customize those through out your project life.
   
2. It depends what changes you have made. I've never tried changing the xml file directly in file system (as it's not recommended) so can't confirm you what happens if you change the file in file system directly. But making changes in non-suggested way might behave in different way than the general/suggested approaches.

I am sorry if I have caused confusion.  I am not doing what you think that I am doing :)

All of my issues that I reference above are encountered when I deploy via WSP/Powershell.  I am not changing any files directly in SharePoint.  When I mentioned changing the elements.xml and schema.xml files above, I am talking about in Visual Studio prior to packaging everything in WSP and redeploying.  I will re-word my previous post to better emphasize my questions:

1. Isn't changing the elements.xml via Visual Studio and deploying the same as changing it directly? I have tried numerous times to change a content type elements.xml file in Visual Studio, Deactivate/Retract/Remove/Install/Deploy/Activate the new version via WSP, and then perform a content type update(true) in the feature activated to push the changes to all child content types... and it doesn't change the lists version of the content type.  This is why I thought that guidance of "don't change the definition file" applied to elements.xml altogether after deploying.  Either way, my code approach for getting these fields updated is working, so I can probably just proceed with that approach.
2. This is where it gets very strange.  I see everyone indicate that a schema.xmlchange does not affect existing lists that were made from a list definition when updating the package in Visual Studio, Deactivating/Retracting/Removing/Installing/Deploying/Activating the new version via WSP.  I am 100% seeing the opposite of this.  When I update the schema.xml file in Visual Studio and then deploy via WSP/Powershell, my views (in existing lists) change to match the new schema.xml as soon as I deploy the changes.  I don't know if this is working differently in 2013 than it did before.

Hopefully this better indicates the situation.  My apologies!

Thanks again!

I am sorry if I have caused confusion.  I am not doing what you think that I am doing :)

All of my issues that I reference above are encountered when I deploy via WSP/Powershell.  I am not changing any files directly in SharePoint.  When I mentioned changing the elements.xml and schema.xml files above, I am talking about in Visual Studio prior to packaging everything in WSP and redeploying.  I will re-word my previous post to better emphasize my questions:

1. Isn't changing the elements.xml via Visual Studio and deploying the same as changing it directly? I have tried numerous times to change a content type elements.xml file in Visual Studio, Deactivate/Retract/Remove/Install/Deploy/Activate the new version via WSP, and then perform a content type update(true) in the feature activated to push the changes to all child content types... and it doesn't change the lists version of the content type.  This is why I thought that guidance of "don't change the definition file" applied to elements.xml altogether after deploying.  Either way, my code approach for getting these fields updated is working, so I can probably just proceed with that approach.
2. This is where it gets very strange.  I see everyone indicate that a schema.xmlchange does not affect existing lists that were made from a list definition when updating the package in Visual Studio, Deactivating/Retracting/Removing/Installing/Deploying/Activating the new version via WSP.  I am 100% seeing the opposite of this.  When I update the schema.xml file in Visual Studio and then deploy via WSP/Powershell, my views (in existing lists) change to match the new schema.xml as soon as I deploy the changes.  I don't know if this is working differently in 2013 than it did before.

Hopefully this better indicates the situation.  My apologies!

Thanks again!

Hi,

Do you have a solution for case 2)?

I just confirmed for case 2), you are right. This happened for both SP2010 and SP2013.

I've tried to add more column in the schema.xml, then re-deploy solution. After that, all existed lists are effected the new schema.xml. However, by the work as design of SharePoint OOTB, it could not be effected because after creating a list, all schema.xml is copied to database and it will work on the separate space. It's so strange.

if you have a solution to fix or found out something else, please share it.

Thanks

/hai