Building VS 2010 projects for SharePoint 2010 & 2007

Question

I am curious if anybody else out there is trying to development a single SharePoint product that works with both SP2007 and SP2010, and what approach you have taken to structure your Visual Studio projects and solutions.

We have a Visual Studio 2010 solution that contains 6 class library projects originally created for SharePoint 2007. They are NOT VS SharePoint projects, but each project is used to generate a WSP. We use WSP Builder to generate the WSPs and deploy them.

Our approach has been to have two VS solutions, one for each version of SharePoint we support. In each solution, the projects all have the same names and contain (mostly) the same code files. They are separate .csproj files, though, because they need to reference different versions of the Microsoft.SharePoint.* assemblies. The SP2007 and SP2010 versions of each .csproj file live in the same directory in TFS and reference the same code files.

Since we use WSP Builder, the SP2007 .csproj files all contain a folder called "SharePointRoot07", which contains all of our SharePoint resources. Similarly, each SP2010 .csproj file contains a "SharePointRoot10" folder. To accomodate WSP Builder, each project has a postbuild script that creates a junction on the file system between "SharePointRootXX" and the junction folder "SharePointRoot". This allows WSP Builder to find the correct resources depending on the project being built.

This is the approach we've been using for over a year now, and it works, but with a few caveats:

• If a new file is added to one project (i.e. the SP2007 project), the developer has to remember to add it to the other (the SP2010 project)
• Likewise for removing files from a project
• We have twice as many projects as we used to have before SharePoint 2010 came about. When the next version of SharePoint comes out, we'll have 3 times as many.
• We are still reliant on WSP Builder for all of our WSP generation, and cannot use the built-in Visual Studio tools
• We are reliant on postbuild scripts to do the junction
• Adding a new project is difficult, since you have to create two projects and then copy the resulting .csproj file for one of them into the other one's directory.

Given that our process works, but it's not ideal, I'm curious what other people in a similar situation are doing. We are considering switching over to a build configuration based approach, but see same downfalls to that, too. I appreciate any insight or suggestions that anyone has to offer.

Answer 1

This is purely opinion and conjecture, so I suggest this be community wiki

This opinion is further down entirely to the dynamics of the market you operate in or the customers that you serve, but I have found it far more economical and simpler to freeze continual development in SP2007 and build only for SP2010.

Continue to support customers on SP2007 by releasing fixes and patches, but new features should only be added to the SP2010 branch of your code, and fix and publicly announce a date after which you will no longer support SharePoint 2007 customers. Use the new Visual Studio development features, because by vNext, you'll be two generations behind the coding norm, and the supportability of your coding practices by yourself, and others, including Microsoft, will fall further and further behind.

Like I said, this will be ultimately down to your situation and the numbers of your customers that are on SP2007 with no plans to upgrade soon.