0

I have a solution with some field definitions and content type definitions as part of a Site scoped feature.

One of the field definitions was originally this:

<Field ID="{GUID}"
        Name="MyField"
        DisplayName="My Field"
        Type="TaxonomyFieldType"
        ShowField="Term1033"
        DisplaceOnUpgrade="TRUE"
        Overwrite="TRUE"
        Group="My Columns">
  <Customization>
    <ArrayOfProperty>
      <Property>
          <Name>TextField</Name>
          <Value xmlns:q6="http://www.w3.org/2001/XMLSchema"
                  p4:type="q6:string"
                  xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">
            {GUID of TaxHTField0 field}
          </Value>
      </Property>
      <Property>
          <Name>IsPathRendered</Name>
          <Value xmlns:q7="http://www.w3.org/2001/XMLSchema"
                  p4:type="q7:boolean"
                  xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">
            TRUE
          </Value>
      </Property>
    </ArrayOfProperty>
  </Customization>
</Field>

I deployed the solution to my dev farm, went to a site to check everything out, and when activating the feature something went wrong and I got an error page. I collected the correlation ID, and went to the logs to see what happened.

I found some errors that called out that field specifically by name, and gave an error that

The string 'TRUE' is not a valid Boolean value.

Ok, I figured that came from the IsPathRendered setting. Not a big deal if I have to configure that manually, so I removed that property from the field definition, cleaned and re-published the project, and ran Update-SPSolution to deploy the updated WSP.

When trying to activate the feature again, I once again got the "string TRUE is not a valid boolean" error, although it no longer called out my field by name.

Since then I have tried

  • Update-SPSolution -Force
  • Uninstall-SPsolution, Remove-SPSolution -Force, reboot server, Add-SPsolution, Install-SpSolution -Force

and other attempts to remove/reinstall the solution, and every time, when I go to activate the feature, I keep getting the same error.

That field was the ONLY field that had the extra property on it. There are a couple other taxonomy field definitions in the feature, but they only have the string property that has the GUID of the related TaxHT0Field note field.

So apparently, that little remnant of XML from the original field definition is still stored/cached in the Farm somewhere, even though I have repeatedly tried to re-add or update the solution/feature.

WHERE IS IT?? Where can I look to get rid of the bad XML so I can get my feature activated?

Keep in mind, the feature has never been successfully activated anywhere, so doing something with a Feature upgrade is not really possible, because there's nothing to upgrade that way.


Update:

I changed the field's ID in the definition and tried deploying again, this time on feature activation, the errors once again called out the field by name, specifically, there were errors thrown by some process retrieving a field by internal name. (The ultimate error, though, was still the same, not being able to parse the string "TRUE" as a boolean.)

I then also changed the internal name of the field in the definition and tried deployment / activation again, and finally it worked.

However, all that still seems to indicate that somewhere in SharePoint, there is stored the XML of my original field definition, referenced by internal name, that is not overwritten despite many attempts to -Force an installation or update of the solution that contains that definition.

So my question still stands: where is that, and how can I get rid of the bad definition and overwrite it with a good one?

Your Answer

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

Browse other questions tagged or ask your own question.