Today (October 11, PDT) the Office team reached a major milestone going RTM with the entire Office suite (both client, server and cloud services). This means that the bits for SharePoint 2013 are final and ready to ship! You can read more about it here:
Archive for October, 2012
If you get an error message saying “The server was unable to create your template. Please notify your server administrator” when you try to save a reusable workflow as template, the reason could be that the name is too long.
When I ran into this I looked in the ULS log and found this:
SPSolutionExporter: System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
After renaming the workflow to a shorter name it worked (in my case only 10 characters worked). Looking at the ULS some more I found out that the original name I chose was still used in combination with the new name. So if you still want that long name for your workflow you could first create the workflow with a short name, publish it and then rename it to the long name. Now you can hopefully save it as a template.
If you ever find yourself working with document sets through the SharePoint API, don’t use Linq on the Collections in DocumentSetTemplate. Even though they implement IEnumerable<T> they have not wired everything up internally so you will get NullReferenceException (Object reference not set to an instance of an object) when using any Linq statement on them. This applies to AllowedContentTypes, DefaultDocuments, SharedFields and WelcomePageFields.
You can easily reproduce this by running this code:
var ct = web.ContentTypes["Document Set"]; var template = DocumentSetTemplate.GetDocumentSetTemplate(ct); template.AllowedContentTypes.Any();
Hopefully this will be fixed some day in the API
I was working with a customer that had an InfoPath form with code behind running as a sandboxed solution. The forms library also had an event receiver with both ItemAdded and ItemUpdated. We could debug ItemUpdated but not ItemAdded. I finally found that if the form has code behind running as a sandboxed solution you have to attach to the SPUCWorkerProcessProxy.exe process to debug ItemAdded. Even using Attach to All SharePoint Processes in CKSDev won’t do it since the SPUCWorkerProcessProxy.exe process is not attached. ItemUpdated will run in the normal SharePoint process and not in SPUCWorkerProcessProxy.exe.