How to protect your code from breaking when user renames a list?

Question

When you access a list using web.Lists["Title"], you depend on list title being unchanged. What are the best practices for preventing such failures?

Answer 1

Just to add a SharePoint 2010 slant here - this issue becomes even more important if you have code which uses Linq, since there you have generated classes against the current schema of the list, and failures will occur if this schema changes and the classes are not in sync.

My recommendation here is:

• Lists which have Linq or similar code written against them should be permissioned such that users cannot make such schema changes
• There is a 'list schema changed' event in SharePoint 2010 which can be used to trap this happening

I prefer the first option though. Suggest that's a good way to treat lists which have code written against them, they are effectively 'system/application lists'.

Answer 2

Option 1. Use list GUID for indexing.

This method may fail if the list is recreated from a template.

Answer 3

Option 2. Use the List's Web Relative Url which doesn't change and the web.GetViewFromUrl(url) method.

Example:

SPList list = web.GetViewFromUrl(web.Url + "/Lists/" + listTitle + "/AllItems.aspx").ParentList;
SPList doclib = web.GetViewFromUrl(web.Site.Url + web.ServerRelativeUrl + "/" + doclibTitle + "/Forms/AllItems.aspx").ParentList;

This will break if the default (AllItems.aspx) view Url is no longer available for the list which is possible but less likely than the List title being changed.

This method may also fail if someone changes the List URL using SharePoint Designer which is even less likely, but still possible.

Answer 4

There is no perfect solution, user should have contribute rights only. User who rename lists is an admin.

Option 1: if you save the site as a template (stp) and create from that template a new one, you will get a new guid for the list.

Option 2: changing url is possible using SPD and

      web.Site.Url + web.ServerRelativeUrl = web.Url !
      you also have SPList.RootFolder.Url instead of that "dangerous" concatenation !