SharePoint2013 Beta AddToLatestVersion

Scenario: When you install SharePoint 2013 beta, you will observe there will be both 14 hive and 15 hive. So you have been given a solution pkg (.Wsp) developed in VisualStudio2010. How will you deploy the solution so that all the artifiacts inside the .WSP get deployed to 15 hive.

Solution: By default when you excecute the "Install-SPSolution" PowerShell cmdlet it deploys the WSP artifacts to 14 hive. To force the artifacts of the WSP to be deployed to 15 hive, you have to use "AddToLatestVersion" switch as below.

Install-SPSolution -AddToLatestVersion -Identity $wspFilename -WebApplication $webapp -GACDeployment

Migrate SharePoint 2010 project to SharePoint 2013 Beta

Scenario: I was tasked with migrating one of the SharePoint2010 project to SharePoint 2013 Beta. Basically to deploy the SharaPoint2010 Project developed in VS2010 on SharePoint2013 Beta and make it work. Below are some of the issues I faced while doing this

Solution:
Issue1: When I deployed the 2010 solution(.wsp) on 2013. I observed that custom Central Admin pages were not showing up.

Resolution: Add the DDLs that central admin pages are referencing to GAC
From visual studio solution explorer, double click on Package.package --> Click on "Advanced" button -->click "Add" button -->Add Existing Assembly
Browse to the required Sharepoint Dlls refrenced in the pages that are not getting displayed. Then build the solution and deploy new WSP and my custom central admin pages are getting displayed without any issue

Issue2: Custom webparts in 2010 were not showing up in 2013

Resolution: SharePoint2013 beta version has both 14 hive and 15 hive. So If I deploy the solution to 15 hive the webparts were not showing up. I then deployed it to 14 hive and the webparts are getting added without any issue.
The reason webparts were not showing up when deployed to 15 hive was because the webpart was loading a user control which were referencing version 14 bits\assemblies.

SharePoint 2010 Modifying deployed/existing content types

Scenario: You have created a custom content type with required site columns declaratively (XML) and deployed it to production environment. Later business requirement has been changed and you have been asked to modify existing content type by adding a new site column. And push down the new site column to all the lists that are referencing this content type

Solution: The best approach is when you are creating site columns, content types initially, it is recommended to create them declaratively. Later if you have to add/modify existing site columns or content types it is recommended to do it programmatically.

public override void FeatureActivated(SPFeatureReceiverProperties properties)

        {

            SPWeb curWeb = ((SPSite) properties.Feature.Parent).RootWeb;

            //Create Custom Site Column

            curWeb.AllowUnsafeUpdates = true;

            string fieldNamev2 = curWeb.Fields.Add("SriSCV2", SPFieldType.Text, false);

            SPFieldText v2Field = (SPFieldText)curWeb.Fields.GetFieldByInternalName(fieldNamev2);           

            v2Field.Update();

            curWeb.Update();

            SPContentType ct = curWeb.ContentTypes["SriniTestCTSC"];

                            if(ct != null)

                            {

                                SPFieldLink FieldRef = new SPFieldLink(v2Field);                               

                                ct.FieldLinks.Add(FieldRef);

                                ct.Update(true,true);

                            }

                            curWeb.Update();

                            curWeb.AllowUnsafeUpdates = false;                       

        }