Over the past several weeks, I have been having some serious headaches using the Visual Studio Extensions for WSS 3.0 and it came to a climax today. For a project I'm working on, we have the need to create several content types, several Custom Lists based on these content types, and then a Site Definition that makes use of these content types and lists. I've put a good amount of time into creating a Visual Studio project with several "Project Items" based on the "Visual C# Project Items – SharePoint" templates that get installed with the mentioned extensions, image shown here:

In summary, I performed the following steps to get where I'm at now:

1. Create a new VS C# Project based on the "Blank Site Definition" template
2. Added 4 content type items
3. Added 9 list definitions (some of which are based on the content types I created)

One of the great things about the VS Extensions for WSS is that as I wrote the content types, lists and site definition, I could easily deploy everything to my local SharePoint site collection by right-clicking on the VS Project and selecting deploy.

Things went pretty well for a couple of weeks, but then I started getting the following error when I tried to deploy: "object reference not set to an instance of an object". The error was NOT an error with my code (I know - bold statement), but instead was an exception being thrown by Visual Studio. You see, when you choose to deploy to project, VS actually has to do a good amount of work to re-organize all of the files you've created, create a manifest, create the actual .wsp file (SharePoint Solution File) and then a batch script (setup.bat) which is executed after all is done to actually deploy your SharePoint *stuff* to the server. The exception was occurring during the step within Visual Studio that creates the .wsp and setup.bat files.

For a few weeks I was able to get past this problem by shutting down and then re-launching Visual Studio and then try deploying again and whola… it would work. Lately, however, the problem started occurring more and more often and has gotten harder and harder to work around. Yesterday, it got so bad that my workaround became:

1. Check all code into TFS
2. Shut down Visual Studio
3. Delete the local copy of my code
4. Launch Visual Studio and do an Open from Source Control to get the code
5. Run the Deploy – and it would work… not a single change to any of code or CAML

Then, if I made even the smallest, most insignificant change to any of the files in this project, the Deploy would fail and I'd have to go through the above steps again.

Well… today it got even worse. Now, I can't get it to deploy at all!!! Even if I roll back all my changes to a version that was deploying fine this morning, it still doesn't work… Ugh.

So, over the past 2 hours I've been trying to narrow down the problem by excluding directories in the project (which I had tried before), and narrowed it down to the Site Definition folder. If it's included in the project, the Deploy fails. If it's NOT included in the project, the Deploy works.

-----------------------------------------------------------------------------------------------
----- Took a break here to figure out what's causing the problem ------
-----------------------------------------------------------------------------------------------

OK… I'm back, and I've got a "kind-of-ok" solution, so here it is:

1. Since I had so many Content Type and List definitions in the existing project, I created a new project just for the site definition
2. Now that there's no Site Definition in my original project, I had to remove all the instances of my lists, or they'd get created at the Site Collection Root, which is not where I want them. So, I went through each of the list directories in my original project and if there was a file by the name of "instance.xml", I excluded it from the project.
3. In my new project, I updated the default.aspx and onet.xml files with the contents of the default.aspx and onet.xml files in my original project (which are now excluded from the original project, but I kept them on the hard drive just for this reason).
4. Things are looking good, and both projects are deploying well, but now since the Site Definition and all of the List Definitions are in separate Visual Studio Projects, Visual Studio will no longer do the leg work to make sure that each of the list definitions (which were implemented as Features) are activated in the Web when it gets created, nor will it do the work that creates the instances of the lists which I want instances of. So, I needed to add 2 lines to the onet.xml file in my Site Definition project for each List Definition I wanted to have activated and an instance created for. Those lines are shown below – highlighted.

In the code above, there are two things to note:

1. The Feature Id can be found near the top of the schema.xml file for the list in a comment line (which Visual Studio uses to create the wsp package):
   <!-- _filecategory="ListDefinition" _filetype="Schema" _filename="schema.xml" _uniqueid="ba2bb031-da03-4b55-9e38-170ae9edc59e" -->
2. Be sure that you move the <Lists> section to be BELOW the <SiteFeatures> and <WebFeatures> section since the feature needs to be activated in the web before a list can be created based on the feature.

Now that I have my code re-organized in Visual Studio as stated above, deployment is very smooth. However, it has only been one day since I re-organized as stated above, so only time will tell if this is more stable than my original organization. If this turns out to be troublesome after a few days or weeks, I'll be sure to blog about what I find then.