This blog post will outline the steps required to upgrade a SharePoint 2007 Visual Studio Project to a SharePoint 2010 Visual Studio Project using the VSeWSS Import Tool for Visual Studio 2010 (http://archive.msdn.microsoft.com/VSeWSSImport). The tool is kind of old at this point, but it is still very useful and I haven’t found a better tool.
This post will be helpful to you if you have created custom SharePoint 2007 solutions using the VSeWSS Visual Studio extensions. The tool above can be used to easily upgrade these projects to SharePoint 2010 projects. This post should be especially useful if you are upgrading existing SharePoint 2007 sites to SharePoint 2010 that already have these Web Parts added and you would like the ability to add additional modifications to these projects.
Installing the VSeWSS Import Tool
The VSeWSS tool is actually provided as a Visual Studio Project, which needs to be compiled in order to build the executable to install the tool into Visual Studio. One other thing to note is that in order to open the solution in Visual Studio 2010, you need to install the Visual Studio 2010 SDK (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en). Why this isn’t included in Visual Studio by default is beyond me. Or why it is not mentioned in the VSeWSS Import Tool installation instructions is also beyond me.
So basically, install the SDK, and then follow the instructions to install the new project type.
Importing Your Projects
To get started you want to copy any old Visual Studio project directories over to computer where you will be writing your Visual Studio 2010 solutions.
Once you have your old projects ready and have everything installed go ahead and fire up Visual Studio 2010. Click New Project and you will now have a new project template called Import VSeVSS Project (if the installation went well). See below:
Next, name your new projects exactly like they are in the old solutions in order to ensure your solutions upgrade correctly. Once you have named the project click the “OK” button. You should see the import dialog like this:
In the dialog, set a debug URL if needed, and change the trust level to full-trust. Next, click the “Browse” button and browse to one of your old projects. Select the “Project configuration” file and click “Open“. Finally, click “Finish“.
The tool will then go through and upgrade the files to reflect the new layout of a SharePoint 2010 Visual Studio solution. Once the upgrade is complete, if there were no errors, you should see the new project laid out in the Solution Explorer. If you have not created any SharePoint 2010 solutions you will notice that the solutions are organized in a much more intuitive fashion (in my opinion at least). If you are upgrading something that deploys as a feature (like a Web Part) you will notice a Feature folder as well as the Package folder. Your solution explorer should look something like this:
So that officially upgrades your solution! Technically you should be able to just run the deployment inside Visual Studio and deploy your solution as is, however I have found this to not always be the case.
Final Updates and Fixes
Below you will find a list of items that I make it a habit of checking before I consider the project officially upgraded. You may or may not need to make these changes. Hopefully these will save you some time as I spent about a week figuring most of these out on my own.
- Update Feature Title, Description, and Scope – for some reason when I upgraded some of my Web Parts the feature title and description did not get carried over. To update these expand the Features folder and double click on the item(s) within. Then just fill in the boxes. Also, my Scope was changed to Web for many of my features that were originally set to Site. Just change that in the drop down.
- Update the Deployment Path (this one is just me being a little bit retentive) – By default the feature will be deployed to the Feature directory in the form of <NAMESPACE_FEATURE>. For me the feature part was unnecessary so to remove this, while updating the section above you will see a property called Deployment Path in the Properties window. In this property you will see something like $SharePoint.Project.FileNameWithoutExtension$_$SharePoint.Feature.FileNameWithoutExtension$. You want to remove $_$SharePoint.Feature.FileNameWithoutExtension$.
- Add SafeControl entry to spdata file (if your project is a Web Part you may need to make this change) – The spdata file specifies the contents and behavior of a SharePoint project item. In order to see this file, click the “Show All Files” button at the top of the Solution Explorer. You should see the spdata file within your individual project directory. In the file paste the following below the Files element (replace the placeholders):
<SafeControls>
<SafeControl Name=”SafeControlEntry1” Assembly=”$SharePoint.Project.AssemblyFullName$” Namespace=”<NAMESPACE>”
TypeName=”<TYPENAME>” IsSafe=”True” IsSafeAgainstScript=”False” />
</SafeControls>
- Update Elements.xml – My elements.xml (actually not named elements.xml in my case) file is actually the file which caused me the most grief. For things like Web Parts, this file is what is used to specify what happens when the feature is enabled. For some reason when I would try to add a Web Part after enabling the feature I would get the following error:
It turned out that the Web Part was actually being added to a folder within the Web Part catalog, which is why the error notes a directory. I’m not sure if this has something to do with differences in SharePoint 2007/SharePoint 2010 Web Parts or if it was an issue in the upgrade, but either way it needed to be fixed for every one of my Web Parts that are added as features.
To fix this issue, remove the directory part of the URL in the Url property of the Elements.xml file. More specifically within the File xml element you will see a Path and a Url. If within the Url you see something like <DIRECTORYexample.webpart>, remove “Directory.” This one drove me crazy because when I enabled the feature a file was getting added to the Web Part Gallery, but it wasn’t an XML file. It actually came down to me writing a PowerShell script to determine what exactly the file was.
Two more things that are probably just for good measure are to add “Type=GhostableInLibrary” to the File element and to specify a value for a group. Here is what mine looked like after everything was updated:
<?xml version=”1.0” encoding=”utf-8”?>
<Elements Id=”<ID>” xmlns=”http://schema.microsoft.com/sharepoint/”>
<Module Name=”Test” List=”113” Url=”_catalogs/wp”>
<File Path=”TestTest.webpart” Url=”Test.webpart” Type=”GhostableInLibrary”>
<Property Name=”Group” Value=”Custom” />
</File>
< /Module>
</Elements>
I hope this post is informative and time saving for you and I hope it will allow people to deploy much cleaner solutions to their brand new SharePoint 2010 environment. As always, please leave a comment if you have any questions, additional tips on this topic, or if you have a better solution to share. Thanks!
