I hate packaging SharePoint solutions by hand. Once you’ve got it working, it’s not a big deal, but it takes a lot of reading and remembering each time you start one anew. VSeWSS is a nice tool that integrates with Visual Studio 2008 and builds out SharePoint solution files auto-magically. However, it has its quirks. Quirks that irk me to no end because it feels like it’s a constant struggle to get it to do what you want.

I’ve got a templated web part base class that I use on a lot of SharePoint projects because it really helps separate out the UI from the business logic. In the past, we’ve just copied the code from project to project. In an attempt to avoid code strewn about all over the place, I decided to pull it back into a single assembly where it could be maintained more easily. So, after a bunch of work, I went to package things up with VSeWSS and I received the following error:

VSeWSS Service Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

Wonderful. A bit of digging revealed that this is an issue if you’re web parts reference a base class in another assembly. For real? Seems like that’s a pretty big issue since copying and pasting code from project to project is frowned upon in terms of maintainability.

Then I used all of my mental devices and .NET knowledge to create a plan so cunning that it would circumnavigate the issue entirely. Make an dummy class in the project that inherits from my base class in the assembly. As such, the base class would be in the project itself where VSeWSS could see it, but the REAL code would be in the external assembly. Shear genius!

Yeah, that didn’t work. Apparently you can’t have a base class ANYWHERE in the inheritance chain. That left me with a big WTF moment. I was seriously miffed that this would not work. If you look into the error that VSeWSS throws, you’ll see it’s a reflection error. So I hashed together my next, slightly less cunning, plan: throw copies of my assembly everywhere and anywhere that VSeWSS could be looking in the hopes it would magically find it. I ran the VSeWSS packager, and it packaged everything up without error. So then it was a process of elimination as I removed the assembly from the various places I had placed it. In the end, I found that in order for VSeWSS 1.3 to see your external base class, you need to copy your assembly to the following location:

C:Program FilesMicrosoft SharePoint Developer Tools 9.0svcbin

This appears to have worked for my scenario, though I’m not sure if such is always the case. I was also really surprised that putting the assembly in the GAC seemed to have no effect.