0

I have a requirement to always use the internal field name for columns in custom Visual Studio projects. I want to use the internal string value of the field name consistently and have the following two methods defined.

An example of how and when I need to use the internal field name is as follows:

properties.ListItem["My Field Name"] = "";

In place of "My Field Name" I always want to use the internal field name. In lots of instances site collection owners will rename fields from "MyOriginalInternalFieldName" to "My Field Name", for example. The code above still needs to work.

Are the below methods the best way to always use the internal field name string value?

(NOTE: I found them here: http://apicollection.wikia.com/wiki/Get_And_Set_Value_By_Field_Internal_Name )

        public object GetValueInternalName(SPListItem item, string fieldInternalName)
    {
        if (item == null)
            throw new ArgumentNullException("item");

        if (item.Fields.ContainsField(fieldInternalName))
        {
            SPField field = item.Fields.GetFieldByInternalName(fieldInternalName);
            if (item[field.Id] != null || string.IsNullOrEmpty(field.DefaultValue))
                return item[field.Id];
            else if (field.FieldValueType == typeof(Boolean))
                return bool.Parse((field.DefaultValue == "0") ? bool.FalseString : bool.TrueString);
            else
                return Convert.ChangeType((field.DefaultValueTyped != null) ? field.DefaultValueTyped : field.DefaultValue, field.FieldValueType);
        }

        return null;
    }

    public void SetValueInternalName(SPListItem item, string fieldInternalName, object value)
    {
        SPField field = item.Fields.GetFieldByInternalName(fieldInternalName);
        if (value is DateTime && (DateTime)value == DateTime.MinValue)
            item[field.Id] = null;
        else
            item[field.Id] = value;
    }

Is there a way I could include a custom "utilities" class that I could reuse across projects so that I don't have to put these two methods in multiple times into the classes where I need to use them?

  • Given that a user with proper permissions can change the display name of a field. But you have all the control in the code. If you know the internal name of the field, you should always use that in code. Remember it is you who is provisoning the fields and you know what internal name you are giving them at the time of creation. That will always remain same. – Nadeem Yousuf-AIS Feb 9 '15 at 15:34
  • @NadeemYousuf That is the question I am asking. How can I consistently do this? If a new field is created by the user after the initial solution is deployed then I will still need to get the internal name of that field. – motionpotion Feb 9 '15 at 16:28
  • The best way to always use the Internal Name is to always use the Internal Name. Sorry to downvote, but this question makes no sense whatsoever. – Derek Gusoff Feb 9 '15 at 18:44
  • @DerekGusoff Great that you downvote a question you think doesn't make sense. But could you explain a little further Why it doesn't make any sense? That way you give OP a chanse to edit the question according to your suggestion. Thank you! – Benny Skogberg Feb 10 '15 at 11:22
  • Fair enough, Benny, I've given some thought and will take a shot at an answer. – Derek Gusoff Feb 11 '15 at 13:49
1

You seem to have a chicken and egg problem. If you are trying to access a field via its name, but don't know what the name is, you need to somehow determine its name. You might try iterating the fields on the list item until you get the one you're looking for, but the question remains, how do you know which is the right one? (That approach will also have performance implications as well.) Bottom line, we use internal names because they are consistent and unchangeable, but in your case they seem not to be (at least from instance to instance), so you lose the benefits.

The method definitions you posted are not quite what I would write but if they work for you, they should do fine.

Finally, to answer your final question, you can make those methods reusable across projects by putting them in a separate project of type "Class Library". Just add a reference to the DLL from that project into any projects that consume it.

  • yes. Once the solution is deployed then people with correct permissions take on the management of the site. They may add columns so that is the difficulty (and the flexibility of SharePoint solutions). If you can add better method definitions to your answer then that is what I am looking for. – motionpotion Feb 11 '15 at 14:32
  • You have still not defined the requirement clearly enough to provide an answer. What is your code actually trying to do? – Derek Gusoff Feb 11 '15 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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