Wednesday, February 18, 2009

Deploy a WSP without WSPBuilder using STSADM

For SharePoint development I typically use Visual Studio and WSPBuilder to do all my packaging/deployment of my code through .WSP(s). However its important to remmember the procedures for doing it directly through STSADM. At a DOS prompt you want to do the following:

1. Go to the directory where the .WSP file is located.

2. Add the directory containing STSADM to the DOS path.
@set PATH=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%

3. Add the solution:
stsadm -o addsolution -filename AlexSolution.wsp
stsadm -o execadmsvcjobs

4. Deploy the solution:
stsadm -o deploysolution -name AlexSolution.wsp -immediate -allcontenturls -allowGacDeployment -allowCasPolicies
stsadm -o execadmsvcjobs

5. Activate the feature in the solution:
stsadm -o activatefeature -name AlexFeature -url http://localhost

What version of SharePoint am I running?

1. Find out your server name and the port number for SharePoint Central Administration. In my case its moss2007vm1 and 41819.

2. Go to the Settings.aspx page in the Layouts folder - i.e. http://moss2007vm1:41819/_layouts/settings.aspx

3. Look for Version under Site Information. In my case its 12.0.0.6219.

Which one?

MOSS 2007 or WSS 3.0 Cumulative update (KB956056 & KB956057) 12.0.0.6327
MOSS 2007 or WSS 3.0 Infrastructure Update (KB951695 & KB951297) 12.0.0.6318
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB948945) 12.0.0.6303
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB941274) 12.0.0.6301
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB941422) 12.0.0.6300
MOSS 2007 or WSS 3.0 SP1 12.0.0.6219
MOSS 2007 or WSS 3.0 October public update 12.0.0.6039
MOSS 2007 or WSS 3.0 August 24, 2007 hotfix package 12.0.0.6036
MOSS 2007 or WSS 3.0 RTM 12.0.0.4518
MOSS 2007 or WSS 3.0 Beta 2 TR: 12.0.0.4407
MOSS 2007 or WSS 3.0 Beta 2: 12.0.0.4017



Source: Penny Coventry's blog at http://www.mindsharpblogs.com/penny/articles/481.aspx

Monday, February 16, 2009

Creating Custom Lists in SharePoint Features

One of the fastest ways to feel extremely ill as an IT worker is to read and analyze a schema.xml file associated with a SharePoint list of a SharePoint feature solution in Visual Studio. These files are thousands of lines long, cumbersome to read and make the Oracle SQL*Forms files I dealt with on my first internship in 1989 look like a piece of cake. There must be a better way to create/customize SharePoint Lists for a custom Feature. The good news is that there is and here are the steps:

 


1. On your dev SharePoint site create the custom list with all the attributes needed. For this example I'll suppose the site URL is http://moss2007vm1:81 and the new custom list is named MyCustomList.

 


2. Create an empty subdirectory in the c:\temp drive of the dev virtual machine called MyCustomListCode.

 


3. Go to a DOS prompt on the C: drive of this virtual machine and type in: CD "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"

 


4. Type in: STSADM.EXE -o ocdexportlist -url http://moss2007vm1:81 -name "MyCustomList" -dir c:\temp\MyCustomListCode

 


5. Examine the contents of the c:\temp\MyCustomListCode directory and see that there is a schema.xml file and a few .ASPX files for the custom list. Move these files into the MyCustomList subdirectory of your Feature in Visual Studio.

 


6. Compile the Feature and build the WSP. Verify that the Feature is not activated on your site and that the custom list is not on your site. Then deploy the WSP to your dev site and activate the Feature and verify that the custom list was successfully created.

 


Suggestion: If you need to add lookups or dependencies on other features/lists this is possible with the schema.xml file and other XML config files in your solution and associated Features staplings. However I recommend adding such things AFTER the lists are created in custom code called from the Feature's FeatureActivated event handler.