So, we all love the way Visual Studio 2010 allows us to debug our SharePoint code with a single bounce on the F5 button, right? Isn’t it nice the way we can deploy with confidence, knowing that we debugged our code in the dev environment? Surely, our code and configurations will act exactly the same way when we deploy them with Add-SPSolution as they do when we deploy them with F5. Right?

Well then what the hell is up with this:

I’m doing something that I think is pretty typical. I’ve created a content type, descended from Document, to go into a document library, like so:

[sourcecode language=”xml”]


And I’ve created a document library to hold documents of this content type, like so:

[sourcecode language=”xml”]

(blah blah blah)

(blah blah blah blah blah)


So can you tell me why I see the following when I hit my F5 key?

A SharePoint List Configuration Screen

Hm, that’s odd. I called my content type “Project Document” not “Project Documents.” Project Documents is the name of the document library itself. Let’s take a closer look at that content type, shall we?

A SharePoint Content Type Configuration Screen

What the WHAT? That’s no content type, that’s a list instance! I wondered what I’d done wrong. It’s certainly not out of the question for me to screw up a SharePoint XML configuration somewhere. Hell, screwing that up is most of what I do all day. So I went to my test server, where I’d deployed a slightly different earlier version. The document library and content type appeared normal. Could there possibly be some difference in the way I deployed the project? I deployed the .wsp manually on the dev box… the very same .wsp I’d just debugged with F5.

A SharePoint List Configuration Screen, from a manually deployed project.

But that looks perfectly normal. What about the content type itself?

A SharePoint Content Type configuration Screen.

So… I guess this means I can’t trust content deployed through Visual Studio anymore. Hey, it’s not like I needed a streamlined workflow or anything.