I must use a list in a webpart and display some data/graph/etc based on the list content (notice: this is simplified, so please do not give it much importance).

To be used the list must have a precise structure: it must contain a set of fields with the expected types, some specific properties should be set (example: versioning, retention ecc). Problem is that some user can decide to modify the list without comunicate it (classical problem, and already happened in the past) or otherwise performs some sort of tampering (nice string column here, let's make it a number), thus giving the need for some sort of check that would validate the list to have all required caratteristic.

I am therefore wondering if I am stuck manually validating each element I need to with some custom logic or some better solution exists. Manual validation would mean browse all expectedfield and types, validate single settings one by one and such... which could be less than desiderable if the number of lists and aspect to check grows.

I am thinking that maybee I can do something like this with some creative use of the list xml schema, but no simple way comes to mind. Has anyone worked with this problem in the past? There is some simplier method tho achieve this? Any idea?

PS: if it can help, I am currently using SP 2010, so fell free to suggest solutions that won't work on 2007.


To answer to the suggestions that were posted. My precise obiective here is to find a way (assuming it exists) to avoid the need to check each "aspect" of the list that needs to be validated manually. So, to be clear, looping on the list of fields an check the types one by one is what I am trying to prevent.

Also, about a content type option, sorry if I didn't added this before but I cannot use them as now. Even if I could, then I would only have a check "I am still using the expected content type" which would not ensure that the content type hasn't been tampered (may sound paranoic, but structure tampering is exactly the problem that I am trying to resolve).

To further elaborate: if the list was a simple table, I could somehow store the metadata info for the table and then check if at runtime the table still match the metadata. Some framework actually provide ways to do this (nhibernate should have something, entity framework also provide basic checks) and would return me an error message with the differences found. Does SharePoint allow for something similar? Can somehow I use the list schema to check if the structure match the expected one? I have had a look at it but didn't found any pratical solution.

  • The reason that the Entity Framework has that check is because the schema is defined. So to replicate this, you must, in some way, define the schema in code or a file of some sort. What do you want to do if you find that the schema is wrong? Maybe add a better overview of your goal to the question. Jan 11, 2013 at 14:54
  • @thantos - Simple. Suppose I store a "validated schema" somewhere. What I want is to be able to see if the list match that partial schema (which is only a minor part of the actual schema you can get from the SchemaXML property on the list) and if it doesn't match, output a list of differences. I know I can manually programm this - to have a configurable set of checks for a list, but I am wondering if some out of box functionalities exist.
    – SPArcheon
    Jan 11, 2013 at 14:58

3 Answers 3


To go the opposite extreme of Thantos' answer about using SPList.Fields and checking a bunch of individual properties you can do a massive check of many properties using SPList.SchemaXml

The drawback is this may be far too much to do an exact comparison against because it would remove some flexibility for the end users to make changes. In addition, this may not cover all cases / properties you want to check on the list and you may end up doing some individual comparisons anyway.

For a little more control you could use SPField.SchemaXml. This reduces your checks from multiple per field (required, length, data type, display name, etc) to possibly a single check per field.

EDIT: you can use SPField.SchemaXml in conjunction with a linq query to find the issues / different attributes in the expected schemaXml and the actual SchemaXml. See for example this question on the main Stack site: Compare two xml and print the difference using LINQ. Just remember to modify the linq queries to only include the attributes in the expected schema.

  • If the number of manual check is reduced that would be good enough for me. Problem is that as I said in the question, the schema contains to much info to be usable as is. For example it contains info about views or lookup ids that are mutable - so while I belive this could be a valid approach, this would need much work to be actually usefull.
    – SPArcheon
    Jan 11, 2013 at 14:47
  • You could at the very least use some sort of XML parsing to get just the relevant areas but at that point you'll probably have to do some testing to determine if parsing XML is better than just doing all teh checks. Also, have you considered using SPField.SchemaXml? This reduces your checks from multiple per field (required, length, data type, display name, etc) to possibly a single check per field Jan 11, 2013 at 14:56
  • Yes Todd, you read my mind. I am now looking at a solution that would intersect SPField.SchemaXml with a "copy" that only contains the values to check, and then provides a list of differences. I guess that if this solution works, I will accept your answer as the most usefull - maybee I will leave an edit with the actual code snippet if you agree. Don't want to auto-answer again.
    – SPArcheon
    Jan 11, 2013 at 15:08
  • For sure. Only mark the answer that is the answer. I've also updated my answer to include what I said in my comment regarding the SPField.SchemaXml. Jan 11, 2013 at 15:22
  • As promised - accepted answer. As said, I have leaved a little edit that points to the question on StackExchange that gived me the idea of using a linq query to find the list of different attributes between the expected and the actual schema.
    – SPArcheon
    Jan 22, 2013 at 10:55

You can use the SPList.Fields collection to see each field and it's information to see what the exact schema looks like.

  • Yes Thantos, I know that, and I fear that in the end I will use a similar solution. But as now I am searching for an alternate way that wouldn't require to manually check all field. See also the edit to the original question.
    – SPArcheon
    Jan 11, 2013 at 14:20
  • Figured, I don't think it would hurt to check a few fields. What are you hitting it from (COM field would be more taxing that SPOM)? Could you just go until you error then check for missing/changed fields and display as needed? Jan 11, 2013 at 14:27
  • It is a pretty long custom job that must configure some site based on the configuration found in some lists and such. I have experienced in the past some field to magically disappear or have subtle change in type (string[100] becomes string[75] for example). I can test field by field as I need them in a just in time perspective, but I would like to be able to perform all checks in one go (that way, I could also run them "on demand" if I need to)
    – SPArcheon
    Jan 11, 2013 at 14:41

Why not create a SPContentType with all the fields you need and assign it to the SPList on creation? The List will have all the columns you need, because they will be inherited from the SPContentType.

  • Wish I could use content type, but I am stuck with field because of a strange requirement. Anyway, even with a content type, any user with sufficient rights could edit the content type, thus invalidating the list anyway.
    – SPArcheon
    Jan 11, 2013 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.