Generate .NET classes with XSD.EXE based on schemas with import declarations

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

How to Create a Site Layout Feature

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:

1. Create the feature files
   

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)

 

1. Edit Feature.xml and ProvisionedFiles.xml
   

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>

 

1. Install and activate the MyLayouts Feature
   

@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?

How to Automate SharePoint Site Provisioning

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:

• Delete the existing site http://www.yoursite.local
  
• Create a blank site at http://www.yoursite.local
  
• Run STSADM to import the Site Definition from the CAB file
  

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.

Installing additional components

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

 

Going further

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