Jason Specland: An Occasionally Funny Software Guy

Making it up as I go along. Always.

Tag: visual studio

Hey, SharePoint: Why Do You Screw Up My Content Type When I Deploy It Through Visual Studio?

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.

Debugging WCF Services In Visual Studio 2008 in 32-bit Mode on a 64-bit Architecture

This is for my own reference, (and for the sake of anyone Googling) since this has been driving me crazy for months. Feel free to ignore if you’re not a geek. Feel free to correct it if you are.

When building a WCF project for the x86 architecture on an x64 machine/OS (like, say, Windows 7), you will get a BadFormatException when you try to debug it. This is because WcfSvcHost.exe will run in the mode defined by your architecture, regardless of your particular build environment. Microsoft says that this is working as intended. I say boloney, but I’m a VS version behind now. (I haven’t tested VS 2010 yet.)

Here is a link to part of the solution.

corflags /32BIT+ WcfSvcHost.exe

However, the signature of this assembly is now broken, and won’t load. So to bypass that:

sn -Vr WcfSvcHost.exe

to remove strong name signature verification.

Don’t do that unless you know what you’re doing! That opens up a huge security risk. Do not do that in a production environment! Only do it on your dev box!

Why not just build the app in x64 or (even better) Any CPU? Because I can’t get Oracle.DataAccess in 64-bit.