VSeWSS v1.3 and source control revisited
Back in May I blogged about my experiences of using the latest version of the Visual Studio extensions for Windows SharePoint Services (VSeWSS). Having had confirmation from Paul Andrew that there would be a supported upgrade path for solutions developed using the extensions to Visual Studio 2010 I have exclusively used them on all projects for all my clients since.
Like most other developers in the SharePoint space I am really looking forward to building solutions using Visual Studio 2010 with all the built in support for SharePoint. However, that is exclusively for SharePoint 2010 onwards with no support for previous versions so it won’t aid my current projects and clients right now. There haven’t been any updates since my blog post in May and despite talk about possible and desired updates I’m not sure this is where the focus will be now.
All that said, having developed exclusively with the extensions for over 6 months now I am happy to report that I only have one real issue which is to do with usability. As per my previous post the recommended approach is to include the ‘pkg’ subfolder in your Visual Studio project and therefore source control and also the WSP and .bat files created in the output (bin) folder. Visual Studio will fail with an error if the WSP and .bat files are not checked out for edit when you attempt to deploy your solution which could be a real pain in team development and/or continual/automated build environments. Also, the feature.xml file in the ‘pkg’ subfolder will be automatically checked out during the deploy process even though no changes will be made which is inconvenient at best but could also be a real issue if someone else in the team has it checked out.
I’ve also experienced an intermittent and inconsistent (major) issue with Site Definition solutions where the ‘pkg’ subfolder is included in source control. Even with the entire solution checked out for edit, during the deployment process the ElementManifest node in the feature.xml file gets duplicated causing the deployment to fail and the solution to become corrupted. When this happens I have found that excluding the ‘pkg’ subfolder from the Visual Studio solution and therefore source control is the only way to recover.
So overall, my goal of finding a simplified and consistent supported means of developing and deploying SharePoint solutions hasn’t quite been achieved. My overriding requirement is for developers who are not necessarily fully aware of how SharePoint works to be able to understand and maintain the solutions. I wonder though if that will always be a compromise even with the more advanced integration of SharePoint support into Visual Studio 2010?
