Skip to main content

Transfer SharePoint solution from VS 2008 to VS 2010

Scenario

There is a solution for SharePoint created in Visual Studio 2008 for SharePoint 2007. The task is to transfer this application to Visual Studio 2010 in order to deploy the same functionality on SharePoint 2010.

Initial solution structure

1. List Event Handler
2. Feature that on activating: creates a sub-site, content types, lists and initial data, registers list event handler for the list and sets up permissions for the sub-site
3. Web Part
4. Application page which is deployed to _LAYOUTS folder and where the Web Part is displayed.

Ok girls and boys, the process

1. Create a new project of type Empty SharePoint Project in Visual Studio 2010:


2. When the project is being created select a "Deploy as farm solution" option:


3. Empty project created! Now we will add List Event Handler:





We choose Custom List as a list type and "An item is being updated" as an event type to handle:


The full list of available event types is as follows:



Here we go - new event handler was added:


4. Now we add a new feature to our project by selecting "Add Feature" command in the context menu for Features node in Solution Explorer:


5. Good, new features was added and we can see the following screen to manage our new feature:


6. We rename the feature in Soultion Explorer and then add an Event Receiver:


When Event receiver is added I put all the code from my initial Feature Event Receiver. It just worked, because the API I used is fully compatible with SharePoint 2010.

I have just made one change though. My initial code contained the List Event Handler registration logic as follows:

string assemblyName = "SlavasAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=11a1bcd111e1111f";


string itemReceiverName = "EventHandlerClassNameWithNamespace";

list.EventReceivers.Add(SPEventReceiverType.ItemUpdating, assemblyName, itemReceiverName);
 
What we can do in SharePoint 2010 is using the $SharePoint.Project.AssemblyFullName$ expression instead of the real assembly. So what I have done is put:
 
string assemblyName = "$SharePoint.Project.AssemblyFullName$";
 
It's very handy, because it saves time. Otherwise I would use some tools like this one - http://www.andrewconnell.com/blog/archive/2006/09/15/4587.aspx - to generate PublicKeyToken.
 
7. Then we will add a Web Part:


I have just copied my source code from initial solution to the new Web part source code as before.

If we look at the .webpart file we will see that assembly name expression again:




8. Adding application page. First we have to add Layouts mapped folder to our solution:




It's very good, because now if the folder changes from 12 to 14 or 16 it doesn't really matter to us, because it will be server relevant and not hard-coded.

9. Adding application page. In the Layouts folder context menu choose Add New Item command and you will see the following options. Select Application Page:



Because I have some custom import directives to use my functionality on the application page I copied the initial source code, but change the directives to use $SharePoint.Project.AssemblyFullName$ expression:



10. Right. Now packaging and installer creation. Packaging is easy, just choose Package command for the solution:


When this is done you can see the .wsp file created in your bin directory for the solution. This is your package.

For installer I used the following Power Shell comands:

Add-SPSolution -LiteralPath SlavasSolution.wsp
Install-SPSolution -Identity SlavasSolution.wsp -WebApplication http://solutions.slava.com -GACDeployment
 
Cool. All done. I can now use my solution on SharePoint 2010 server! :)
 
Stay tuned.

Comments

Popular posts from this blog

Setting up External Content Type for SQL Server database using SQL Server authentication - SharePoint 2010 Foundation

This post is a follow up on the issues that I have got setting up External Content Type (ECT) on SharePoint 2010 Foundation that was going to connect to remote SQL Server database for information. I cannot use my SharePoint user accounts to access SQL Server. According to the information I have discovered ECT and Business Connectivity Services are available in the SharePoint 2010 Foundation, but there are some issues if you want to use authentication methods in your external connections that are different from Windows Identity or Current User Identity. This is because there is no Secure Store Service in SharePoint 2010 Foundation which serves as an impersonation hub and is only available in SharePoint 2010 Server edition. The issues are coming from the fact that you can actually create ECT in SharePoint Designer 2010 providing just Secure Store ID and system would ask you for credentials and here you go, but when you try to use your ECT in External Lists or as a lookup columns you w...

SharePoint 2013 Development and Consulting - Laptop & Conferencing Experience with Lync

Have just jumped on a brand new SharePoint 2013 massive Intranet project and because of specific working conditions have found some items that required addressing almost immediately in order to continue the job. Maybe this will be interesting to someone else who is about to start SharePoint 2013 development to have an idea of what might be necessary. I started working with SharePoint using my own infrastructure in 2009. I used iMac with 320GB HDD and 4GB RAM running VMWare Fusion to virtualise Windows  environment ( SQL Server 2008, standalone SharePoint 2007, Visual Studio 2008, Office 2007). It was all-in-one virtual machine. A bit slow, but enough for any SharePoint work that I had at that time. For communication with colleagues and partners we used GoToMeeting . Great tool that worked (and still works) without any problems. Voice, video, screen-sharing - all worked well using built-in audio/video hardware. In 2010 I got a MacBook Pro  with 500GB HDD and 8GB ...

InfoPath 2013 Preview - URL not valid error when publishing

In InfoPath 2010 there is a problem when you try to publish a Form to a SharePoint site that doesn't have root site collection. You will get an error message "The following url is not valid". It's described here:   http://support.microsoft.com/kb/981854 The solution is to create root site collection for the Web application. Same problem is with InfoPath 2013: In my situation I didn't create the root site collection initially, but used "/sites" managed path instead for all site collections. To solve the problem with InfoPath I had to create it. Used a new site template "Project Site". Will get a chance to research that too. :)