To get intellisense while editing SharePoint XML configuration files, just copy the WSS.XSD schema to Visual Studio schemas folder.
XCOPY "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\WSS.XSD" "C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas"
This approach does not require exposing the local drives in the remote machine. It also works across multiple remote desktop sessions.
(1) On the remote computer, create a ZIP file containing the files to be copied
(2) On the remote computer, open WordPad, paste the ZIP file into the WordPad document, and copy the ZIP file in the body of the document
(3) On the local computer, open WordPad and paste the ZIP file
You can switch the local and remote roles in this example.
If you define two schemas - MySchema and MySubSchema - where MySchema references MySubschema, you will probably get in trouble if you try to generate .NET classes for those schemas using XSD.EXE.
Here's a quick example: MySchema.xsd is imports MySubschema.xsd and declares an element of type ns2:MySubSchemaRoot
MySchema.xsd
<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns="http://Namespace1" xmlns:ns2="http://Namespace2" targetNamespace="http://Namespace1" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import schemaLocation=".\MySubSchema.xsd" namespace="http://Namespace2" />
<xs:annotation>
<xs:appinfo>
<b:references>
<b:reference targetNamespace="http://Namespace2" />
</b:references>
</xs:appinfo>
</xs:annotation>
<xs:element name="MySchemaRoot">
<xs:complexType>
<xs:sequence>
<xs:element name="Element1" type="xs:string" />
<xs:element ref="ns2:MySubSchemaRoot" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
MySubSchema.xsd
<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns="http://Namespace2" targetNamespace="http://Namespace2" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="MySubSchemaRoot">
<xs:complexType>
<xs:sequence>
<xs:element name="Element1" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
If you run XSD.EXE to generate the .NET class for MySchema…
xsd.exe /c MySchema.xsd
…you'll get this error:
The element 'http://Namespace2:MySubSchemaRoot' is missing.
To workaround this issue, you must also specify MySubSchema.xsd as a parameter for xsd.exe, like this:
xsd.exe /c MySubSchema.xsd MySchema.xsd
This will correctly generate MySchema.cs class
From a simple perspective, customizing a SharePoint Internet Publishing Site means creating new page layouts (templates) based on customized master pages. These page layouts and master pages use many resources, such as style sheets, images, …
The Web Designer may start by creating a static HTML storyboard of your site. Then, he will use SharePoint Designer to integrate the static HTML into customized master pages and page layouts, merging the HTML with the server controls required by SharePoint. Some examples of minimal master pages can be found at http://msdn2.microsoft.com/en-us/library/aa660698.aspx . The customized master pages and page layouts created in SharePoint designer will be stored in the site's Master Page Gallery located at /_catalogs/masterpages of the site.
Meanwhile, developers may be busy programming services and components for the site, such as a sophisticated search control, a workflow tracking page or a Virtual Earth mapping web part. Assuming that each development team member (including the designer) has its own stand-alone development environment, there will come a time when the customizations made by the designer must be integrated with those made by the developers.
For the first time "environment synchronization", the designer may just export its Site to a CAB file that should be imported in each developer workstation. But for subsequent synchronizations, it should be far better to just pack the designer's customizations - not the site itself - into a package, and simply deploy that package on each developer workstation. The same approach should be used to publish design updates to a production site.
In fact, the customized design should be seen as a package that could be deployed and applied to any SharePoint site. It should not be just a set of master pages, page layouts, styles and images stored in the libraries (/_catalogs/masterpages, /Style Library, …) of a specific site. Here's when SharePoint Features come in to place.
Like Web Parts, Workflows or just custom Web Forms, SharePoint Web Design Customizations can be packed into SharePoint Feature. Take a look at the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\PublishingLayouts folder of your SharePoint environment. There you have a good example of a feature created to pack design customizations, including master pages, page layouts, styles and images.
So, to pack your design customization into a SharePoint Feature called MyLayouts, just follow this checklist:
Bellow C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES, create the following folder tree:
MyLayouts
Images
Styles
MasterPages
PageLayouts
Copy your customized masters pages, page layouts, images and styles to each corresponding folder.
Also copy to MyLayouts folder the Feature.xml and ProvisionedFiles.xml files (use the samples from C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\PublishingLayouts)
Create a new GUID and place it on the Feature.xml file.
Edit the ProvisionedFiles.xml, and reference all your components.
For example, if you have created a GIF file MyImage1.gif, add it to the Images module section. Notice that the GIF should be referenced as "images/MyImage1.gif" in the MyStyleSheet1.css, or as "/StyleLibrary/Images/MyImage1.gif" from the page layouts or master pages.
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="MyMasterPages" Url="_catalogs/masterpage" Path="MasterPages" RootWebOnly="TRUE">
<File Url="My.master" Type="GhostableInLibrary">
<Property Name="ContentType" Value="My Main Master Page" />
<Property Name="MasterPageDescription" Value="My Main Master Page Description" />
</File>
…
</Module>
<Module Name="Images" Url="Style Library/Images" Path="Images" RootWebOnly="TRUE">
<File Url="MyImage1.gif" Name="MyImage1.gif" Type="GhostableInLibrary" />
…
</Module>
<Module Name="Styles" Url="Style Library" Path="Styles" RootWebOnly="TRUE">
<File Url="MyStyleSheet1.css" Type="GhostableInLibrary" />
…
</Module>
</Elements>
@set Path=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%
stsadm -o installfeature -filename MyLayouts\feature.xml
stsadm -o activatefeature -filename MyLayouts\feature.xml –url http://www.yoursite.local
From now on, your design components live in the file system, at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\MyLayouts, but are also available in the SharePoint site collection http://www.yoursite.local in libraries such as /Style Library and /_catalogs/masterpage. SharePoint "ghosts" those files because of the GhostableInLibrary attribute used in ProvisionedFiles.xml. To update your design components, just edit the files in the file system a do an IIS Recycle.
Finally, to pack and deploy your design customizations to other developer's environment, you just have to copy the folder C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\MyLayouts and install and activate the feature on the target machine. Simple?
SharePoint Solutions can be packed in a CAB file using the STSADM tool, as described in a previous post.
Whenever you need deploy or redeploy a solution on a particular environment, you have to do a bit more than just run STSADM again. Particularly, you have to:
You want to completely automate these steps and create a full provisioning process, using a script such as this:
ECHO OFF
Set cabFileName=YourSiteDefinition.CAB
set SiteName=http://www.yoursite.local
set siteOwnerEmail=administrator@yoursite.local
set siteOwnerLogin=%computername%\administrator
@set Path=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%
ECHO ON
stsadm -o deletesite -url %siteName%
@Set Path=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%
stsadm -o createsite -url %siteName% -sitetemplate BLANKINTERNET -ownerlogin %siteOwnerLogin% -owneremail %siteOwnerEmail%
stsadm.exe -o import -url %siteName% -includeusersecurity -filename %cabFileName%
Creating and saving this script in your Source Control server, along with the .CAB files containing your Site Definitions, allows the developer to quickly setup and provision the solution in the local development environment, as well publishing updates to test, staging and production environments.
Probably, your Site Definition may use specific components, such as User Controls, Web Forms, Mobile User Forms and so on. The deployment of these components can also be automated, using a batch:
Set SharepointHive= "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE"
Set MobileControlDir=%SharepointHive%\LAYOUTS\MOBILE
Set UserControlDir=%SharepointHive%\CONTROLTEMPLATES
Set MyAssembly= MyUserControls.dll
xcopy /Y usercontrols\*.* %UserControlDir%
xcopy /Y mobilecontrols\*.* %MobileControlDir%
GACUtil /i %MyAssembly% /f
This approach works fine, but more complex solutions may require a more sophisticated deployment process, using WSP Solution packages. A good subject for a future post.
Contributors: Telmo Cruz
Whenever you need to restart a Web Application, it's usually faster to recycle only the associated application pool rather than do an IISRESET.
To accomplish this using a command line, create a batch file (replace MyAppPool with the name of the application pool you want to recycle) as this:
%systemroot%\system32\iisapp.vbs /a MyAppPool /r
To create a shell extension that opens a DOS Command Prompt on the selected folder in Windows Explorer, create and run a CmdHere.reg file:
[HKEY_CLASSES_ROOT\Directory\shell\DosHere]
@="Command &Prompt"
[HKEY_CLASSES_ROOT\Directory\shell\DosHere\command]
@="C:\\WINDOWS\\System32\\cmd.exe /k cd \"%1\""
[HKEY_CLASSES_ROOT\Drive\shell\DosHere]
@="Command &Prompt"
[HKEY_CLASSES_ROOT\Drive\shell\DosHere\command]
@="C:\\WINDOWS\\System32\\cmd.exe /k cd \"%1\""
If you need to open a command prompt window to issues SharePoint administration commands such as stsadm.exe, you'll find this useful.
@Set Path=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%
When developing SharePoint solutions, is often necessary to copy a site and all subsites between environments (ex: from development to production). This requires packaging and deployment of the definitions, features and contents for all sites in the site collection.
This can be done in several ways: (1) stsadm import/export, (2) stsadm backup/restore or (3) programmatically using the SharePoint Content Migration API. Details can be found at http://technet2.microsoft.com/Office/en-us/library/16a7e571-3531-4a4e-baa7-f348a9f9d1d11033.mspx?mfr=true
This article is a walkthrough of option (1).
Supose you developed your solution http://dev.litwareinc.com/ in your development server. Your solution was based on the Publishing Site Definition and uses a custom developed feature named LitwareInc.WebParts.MyWebParts. You want to publish this solution to your development server at http://prod.litwareinc.com/ .
First, you have to export the site collection definitions and content.
Since your site depends on a custom feature LitwareInc.WebParts.MyWebParts containing your web part, you will also need to pack this feature in your development environment, and deploy it on the production environment. If you developed your feature using Visual Studio 2005 Extensions for Windows SharePoint Services, your job is quite easy. In the bin/debug folder of your Visual Studio solution, you will find the following files and folders:
Just copy these files and folders to C:\deploy. You can now copy this folder to the production server and start deploying your solution on that environment.
First, you need to create a blank site definition on which you will deploy your solution. Go to Central Administration, create a new Web Application http://prod.litwareinc.com/ and then create a new site collection using the Blank Site template.
Your're done. Navigate to http://prod.litwareinc.com/ (don't forget to add an entry in your hosts file or DNS server) and check your SharePoint site collection deployed in your production server.
