Okay so this will be a pretty short one, but hopefully help some folks that are upgrading their solutions from SharePoint 2010 to SharePoint 2013.
While developing fields, content types and the likes in SharePoint 2010, there’s always a few good rules and practices to follow. A good rule of thumb that I tend to stick to is to never use any reserved or system-name for your fields that you create. In this quick post I’ll talk about how to fix the “Duplicate field name was found” after you upgrade from 2010 to SharePoint 2013 and try to deploy and activate your feature(s).
In one of my projects that I am involved in, I was tasked to upgrade their existing SharePoint 2010 solutions to SharePoint 2013 – and this is where these problems hit us, hard.
A duplicate field name “Name” was found
If you have upgraded your solution from SharePoint 2010 to SharePoint 2013 and you deploy your code, only to find out that you are getting the notorious error message saying “A duplicate field name ‘fieldname’ was found” you might think you did something wrong in the deployment steps or otherwise failed to successfully upgrade your solution. What actually might have happened is a case of the “don’t use any reserved or system names, please” fever.
After some digging around our 30 projects, I found that the features and finally fields it were complaining about. While investigating the xml here, I noted that the “Name”****was the failing factor. If we changed the Name property to something unique (hence, not a built-in field name), it seems to work out nicely.
Field xml for the SharePoint 2010 project
Field xml for the modified 2013 project, after modification
What’s the difference?
So if you look at the two basic samples above, you can see that the small difference is what’s in the “Name” property. If I changed the value to something unique, it started working immediately.
But, doing this will of course bring up other questions that you need to take into consideration and think about.
- Is there any code reliant on your field’s name property?
- Will it break any functionality in your code or configured lists/views etc?
- What happens to data that potentially will be migrated from the old environment into the new environment? Can you map the data to the correct fields properly?
Summary
I thought I’d post this to save someone else from having to spend a few hours digging into the various bits and pieces of an enterprise project to find out where it breaks down after the upgrade. Should you encounter the error message in the title of this post immediately after upgrading your solutions, this may very well be the cause.
Please also make note that this solution is one solution to the problem. Perhaps there’s more solutions available to we can use to fix these issues. Should you know of any such solution, don’t hesitate to comment on the post and I’ll update it and give you the cred :-)
SharePoint Server 2013 is an awesome product that is still uncharted territory for many organizations, but I’m seeing a huge increase in the adoption of 2013 locally and with that we’ll have plenty of time to dig into these fine bits of SharePoint magic :-)
Comments are closed
Archived comments
thank you for this it was just in time!!! i have struggling with this for a long time and cannot see what was the problem but trying this fixed it for me too after upgrading my project to sharepoint 2013.
but what happens to all lists and views and web parts that is using this fields? will them still work?
Thank you for the comment John,
Glad to see that this fixed you problem - just make sure you are aware of what things may break if you perform this change in the field name. You'll most likely want to do some tests to see whether the fields will continue to work like you expect or not.
Cheers,
Tobias.
Nice article Tobias.
Few Content Type which I am using SP 2010 are clashing with system name and facing same issue while converting solution to SP 2013.
My question is: Is it possible to change internal names of columns which are used inside custom content type and push down same to other list and libraries which are inherited from parent. Assuming List content type is not customized locally.
Any thoughts?
Thanks,
Sudarshan S Vatturkar
Any updates?
This one helped me alot. Thanks Tobias!
Cheers, I'm glad it helped.
Is there a complete list of these reserved words? I have just already spent 2 days changing field names and I can see no end of the migration process...
Some of the fields Sharepoint complained were: Name, FirstName, Duration, EventType. Is it possible that all these words are reserved or am I doing anything wrong?
Can you tell me where is the path of fileds xml? Thank you very much
Hi Jeffery,
That depends on where you've deployed them. Supposing it's custom code, they are most likely located in the SharePointRoot, but you shouldn't be in there digging around - instead you should look in your Visual Studio project to fix the problem from that end.
Cheers,
Tobias.
Better to change DisplayName instead of 'Name' and then rename it once the site has been created (probably using an event receiver).
The problem comes with the Name field, which collides with built-in fields in SharePoint, so changing the displayname wouldn't do anything to solve it. Refactoring the solutions to use better naming standards though, works.
We didn't succeed with changing the display name for our fields, not before nor after the upgrade. The Name-field though, does the trick.
Cheers,
Tobias.
Great article. I just wanted to add an important tip.
1) As discussed in this article, change the name of the field in your Site Collection level feature. MOSS 2013 wants you to use field names that do not conflict with their base fields at the Site Collection level.
2) For backwards compatibility and to avoid data loss, do NOT bother changing the Name attribute in the ContentType FieldRef section. Use the original name in the ContentType FieldRef Name attribute.
3) In your list schema, where you once again define the Field, leave the Name with the original name, as well.
Therefore, you only need to change the Name attribute in the Site Collection Level Feature where you first define the field. The ContentType definition and list schema can remain unchanged with the original name of your field.
If you change the fieldref name attribute and the list schema field name, it will result in data loss if you upgrade the solution onto a site that has data in the fields already.