I posted about an issue I had been facing with deploying document sets via XML, where things like the custom welcome page and the shared fields (defined in XmlDocuments) wasn’t showing up.

Here’s a further issue I encountered. I defined my Document Set content type in the usual way. A bunch of Site Fields, then the Content Type definition, and then within the FieldRefs section some FieldRef elements for the fields to use.

At some point, I started to experience a strange error - when I was deploying the solution, I would get an error:

SharePoint development is fraught with frustrations. Little things that should be simple, end up taking far longer than they should. Take this example. I’m trying to provision a Document Set content type via XML in a VS feature. I was using this video and the supporting article as a guide. I get all the way through, and everything is working… ish. That is, the Document Set content type is created, but the extra stuff to do with it, such as the custom welcome page and the extra properties (shared fields, etc.), defined in the XmlDocuments section of the content type, don’t appear. No manner of tweaking and reducing code had any effect. I got a hold of the source code from the tutorial - lo and behold, that works fine. So the theory is sound, it should work, and so something somewhere was different. The job was tracking down said difference.

This was a rarity. SharePoint 2010 threw up the error, whilst trying to create a new Web Application:

The error was:

the specified value for the locstringid parameter is outside the bounds of this enum

and there’s nothing extra in the logs about the specifics of the problem. So, as usual, I put that in to Google - and it was completely clueless!

One of the scourges of software development, and it seems especially SharePoint development, is that more often than not, when faced with a new task, Google is your first stop, looking for tutorials or guides. Frequently, however, people posting the tutorials (MSDN/Microsoft included) are guilty of putting up guides and source code that is incorrect, or missing some vital info. I experienced this very issue recently when I needed to create a visual webpart.

The tutorial is good enough, but the actual source code posted, doesn’t work. What’s most infuriating, though, is when the author then goes radio silence, and the comments fill up with bemused readers, all looking to achieve the same goal - but unable to do so.

Quick (annoying) thing. Whilst deploying a solution, you may see this error:

Error occurred in deployment step ‘Activate Features’: Key cannot be null. Parameter name: Key

This is unhelpfully connected to your Content Type definitions where you have FieldRefs and you’re closing them with the long tag, as opposed to the short tag, i.e.,

replace it with this to fix:

Thanks to Dhiraj.

A common method for creating Visual Studio-based SharePoint solutions is to actually create them in the SharePoint GUI first, and then save the site as a template, and import that .wsp file in to Visual Studio as a SharePoint project. This often saves a lot of the hard slog of starting from scratch in Visual Studio, but still giving you the reusability of Visual Studio based solution.

One small issue you may run in to though is the (re-)use of GUIDs in e.g., Site Columns. For safety, you may like to replace the GUIDs, but in the case where you have a lot to replace, doing this by hand could be cumbersome. Step up Visual Studio Macros. You can create a simple Macro to automate virtually any process. The only problem, in this case, though, is that my testing of macro-ing the Find/Replace was that I could easily find GUIDs in a file, but replacing them with a freshly generated one wasn’t obvious. So I created a custom macro.

If you’re using the handy Document Sets feature in SharePoint 2010 you may run in to a small issue where you make some changes to your document set (e.g., add/remove content types from the allowed contents). When you do this, and push changes down to existing document sets, you’ll see a little yellow bar appear on each document set with the message

“Content Types that are available to this Document Set have been added or removed. Click here to update the Document Set.”

The reason is that the document set refresh date needs updating. Quite why SharePoint can’t manage this for you, is beyond me, but nevertheless, if you do click the yellow bar, it disappears. But it still remains for all your other document sets. Irritating. So here’s how to remove the little yellow bar with the message using Powershell. The neatest way is just to provision the document set.

The Exchange Web Services Managed API is a great tool for exposing Exchange Web Services to a .NET programming environment. You are able to work with all the key features of an Exchange Mailbox, such as downloading messages. In my particular case, I’ve been capturing emails and storing them in a SharePoint document library.

The upload to SharePoint can be achieved by passing in a MemoryStream object - that is, you read an EmailMessage to memory, and then upload it to SharePoint. The FileAttachment object has a neat Load() method which allows you to read a FileAttachment to a MemoryStream:

I’ve been working with Kofax Express 2.0 recently to move documents from a scanner directly in to a SharePoint document library. I was using a custom list definition (created in Visual Studio) but was experiencing a strange error. If I created an instance of my list through the UI and then tried to scan from Kofax directly in to SharePoint, it was working no problem. However, if I tried to scan directly to SharePoint to the instance of the list created by the Visual Studio solution, I was getting the common error - “Object reference not set to an instance of an object”. There were no helpful logs on the Kofax or SharePoint end, and it was only through trial and error that I found the issue. I noticed that when the list was created through the UI, it was created with a URL of “/Document Library Name” whereas in my list instance definition in Visual Studio, I had given it a URL of “/Lists/Document Library Name”. It was the Lists part at the beginning which was causing an error. I don’t know why this caused Kofax to fail to find the library, but nevertheless, setting the URL in the list instance as just “/Document Library Name”, resolved the issue.

If you’ve encountered anything like this problem, then you may have had to update the permissions that a specific SQL login has. However, if the user you’re trying to edit is mapped to dbo, then you’re not allowed to make changes.

There are ways to do it, but you need a pretty thorough understanding of what you’re trying to achieve.

There’s a quick way around this using only the GUI. In SSMS, open the properties of the database(s) you need access to. In the ‘Files’ page, you’ll see the Owner of the database. This is quite likely the account you want to add additional permissions to. But since it’s mapped to dbo, you can’t. Therefore you update the owner of the database to something other than your login (e.g., sa). When you do this, you should then be able to add the required permissions to your login.