Sitecore Serialization – System.ArgumentException: Illegal characters in path

So, I was trying to use Sitecore Serialisation, and I got the following error:

System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
at System.IO.Path.IsPathRooted(String path)
at Sitecore.Data.Serialization.PathUtils.MapItemPath(String itemPath, String root)


Joy. Sadly, this pad doesn’t give a clue what the problem item actually is. The log files don’t show an exception – but I can see the last item processed, and it looks funny:


So, if that’s the item throwing the exception then a) serialisation isn’t logging the exception, which sucks, and b) some items in this tree have newline or carriage return characters (\n or \r)

To try and find these, I ran SQL against the database…

SELECT * FROM [MASTER].[dbo].[Items]
where Name like '%' + CHAR(10) + '%'
or Name like '%' + CHAR(13) + '%'

This found a bunch of items with \r in their names. Lord knows how they were put there. I suspect copy and paste from some of the actual content.

Sitecore Serialization – System.ArgumentException: Illegal characters in path

SPWeb.Properties serialization in the Sandbox

I was trying to store and retrieve some properties on an SPWeb object inside the sandbox. SPWeb has SetProperty() and GetProperty() methods, which accept and retrieve objects. I thought I’d use an enumeration to represent my value, and I’d cast my enumeration value when I retrieve it. However, when I tried this I got an exception of the form:

System.Runtime.Serialization.SerializationException was unhandled Message=Unable to find assembly ‘<my assembly strong name>’

Interesting. I tried similar code within a Console application using the full SharePoint API… Continue reading “SPWeb.Properties serialization in the Sandbox”

SPWeb.Properties serialization in the Sandbox

When saving data into Web Part Properties, remember [Serializable]

So, previously I’d described using a Web Part Property of an ArrayList to store a list of things. In that demo, I’d been just storing strings.

Well, my requirements got a little more complex, so I started trying to store my own objects in there – really, just objects storing data, no logic. However, when I added things to the property and ran .SetPersonalizationDirty() my data wasn’t saved. Worse, the values of other (unchanged) web part properties were lost! They kept coming through as null, rather than the values I’d set previously. There was no indication of error.

Well, here is Andy’s tip for folks who manage to forget the basics of C# development – don’t forget the [Serializable] attribute.

Without it, my data objects can’t, well, be serialized – that is, saved. So it’s unsurprising that my data wasn’t saved! What was unfortunate and threw me off the sent was that there were no errors shown, and that wiping out the values of the other web part properties did rather thrown me off the scent! I guess I was really having an off day when I wrote that…

When saving data into Web Part Properties, remember [Serializable]