Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom column and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature, and this is why I created SPSource.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with (and has been tested with) WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as either part of the build process, or separately as a CMD file at the root of the project. By using the UI and SPD, items can be created and tested rapidly, then compiled into the WSP for deployment using familiar tools.

Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a pre-existing Visual Studio WSP project. SPSource will also create the file provisioning modules and site Content Type/Column definition files, as well as the lines needed in the ElementManifest section of the Feature.xml file.

Some examples of how SPSource can help:

• Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

• Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

• Add a custom Content Query Web Part (or RSS) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Eventually, I hope to get SPSource working with ListInstances and Workflows, but for right now, it only works with Content Types and Modules.

Check out this screencast where I create a custom Publishing Feature, with a new content type and page layout, execute SPSource on my StsDev Visual Studio project, package it all up in a WSP, and deploy in less than 15 minutes!

SPSource Publishing Feature Demo

Here's a short walk-through example of how SPSource works:

In the 'design' site, create a new Content Type for a Publishing page using the SharePoint UI, adding some new columns

In SharePoint Designer, create a new Page Layout based on the Content Type which was just created

Still in SharePoint Designer, add the new content field controls, a web part zone, and some other markup to the new Page Layout, saving it to the 'design' site Master Page Gallery
 


Now, over in a Visual Studio project, which in this example is based on StsDev, create a new Feature, and create some new Folders in that Feature. The folders aren't important in this case, they just allow for some organization.  SPSource has been tested using WSPBuilder, StsDEv, and WspProjectTemplate, but the type of project in Visual Studio really doesn't matter. It just needs to follow the 12Hive folder structure, which means SPSource does not work with VSEWSS.

In each folder, create a new file with the file extension '.spsource'.  This file extension is important, as the SPSource utility looks for these files to work it's magic.  The SPSource files are nothing more than a type of XML file and are what I call 'reverse manifests' as they are based on the same syntax used to push things into SharePoint, but in the case of SPSource, are used to get things out of SharePoint.

The SPSource file for the Content Type is just like a Content Type definition file, and is even based on the same schema. All we need is the name of the custom Content Type we want to have included in the WSP

The SPSource file for the custom Page Layout is also just like a provisioning module file used to put files into SharePoint. We just need to tell it the source list URL, and the file to include in the WSP

At the root of the Visual Studio project, I've got a CMD file that contains the information needed to execute SPSource


Source of CMD file

After SPSource is executed, there will be some new files in your Visual Studio project.

In the ContentType folder, there are now files for both the Content Type definition, as well as the column definitions.
Content Type definition:

Column definition:
 

The ASPX page in the PageLayouts folder is the same as what we added in SharePoint designer

The pagelayouts.Provisioner.xml file is the provisioning module file needed to put the custom Page Layout in to the correct location when the Feature is activated

The two *.ElementManifest.xml files are there so you have the lines needed to add to the Feature.xml file in the ElementManfiests section.  These lines are not automatically added to the Feature.xml as to provide greater flexibility by you to distinguish what gets included in the Feature.

After I add the lines to the Feature file:
 

Now I can build my project to compile the WSP and deploy it to the 'development' site.  SPSource can also be integrated with the MSBuild process to allow for updates to the files added by SPSource before the WSP is compiled.  This allows the WSP to be upgraded using items changed in the UI and SharePoint Designer.

After the solution is built and deployed, the Feature can be activated, and the pages will be added to the Master Page Gallery
 

Master Page Gallery


When I create a new page, the new Page Layout is available in the list, as expected
 

and, the page looks the way it should

Give SPSource a try, and see how much more efficient your Visual Studio WSP creation process can be!

We've been working on this one for a while, and it's been driving us nuts...

In the current project we're working on, we haven't been able to add any new web parts to pages, nor have we been able to edit the properties on the existing ones.  When we do, we've been seeing the three following errors:

- Cannot save the property settings for this Web Part. Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))
- Unable to add selected web part(s). Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))
- Unable to add selected web part(s). List View Web Part could not be added, list may be hidden.

Even stranger was that it was only occurring in the root web of the current site collection.

In researching the 0x80020008 error when related to web parts, the few people that have found anything have said that it could be caused by disposal of the SPContext.Current.Site or SPContect.Current.Web objects.  We looked all over our code and didn't find that we were doing that anywhere.

We switched the master page back to the default.master, and we could add and edit web parts without any issues, so we then started whittling down the server controls on the custom master page until we found three custom server controls that were present when the web part errors occur.  Taking a closer look, these three controls all had the following lines in common.

            using (SPWeb
rootWeb = SPContext.Current.Site.RootWeb) { //code }

Commenting out of the code caused the errors to go away.  What's going on here? 

Turns out that there's something that the Best Practices: Using Disposable Windows SharePoint Services Objects post and Roger Lamb's SharePoint 2007 and WSS 3.0 Dispose Patterns by Example should point out a little clearer.  If you look at the bottom of Roger's post, there's a comment by Stephen Kaye where he hits the nail on the head:

If your current context’s web is the root web of you current context’s site then the RootWeb property of the site will reference the same object return by SPControl.GetContextWeb and SPContext.Current.Web and should therefore not be disposed.

So, this means that if you are in the root web of your site collection, and you dispose of SPContext.Current.Site.RootWeb, you're actually disposing of SPContext.Current.Web.  Not good.

Here's how we changed the code to ensure that we could use the RootWeb SPWeb object, but not dispose it if the SPContext.Current.Web is the RootWeb:

SPWeb rootWeb = null; if (SPContext.Current.Web.IsRootWeb)
rootWeb = SPContext.Current.Web; else rootWeb
= SPContext.Current.Site.RootWeb; //codeif (!SPContext.Current.Web.IsRootWeb)
rootWeb.Dispose();

In our current SharePoint project, we have a custom site definition based on the out-of-box Publishing Site with Workflow. We found a little problem with this though, because when the out-of-box Features for Publishing and it's Parallel Approval workflow are activated, the default SharePoint Approvers group is the only group that is set to approve a publishing page that has been sent into the workflow. The problem is, we want to inherit the parent site's workflow settings - otherwise known as the association data - because our application has 'channels' of content that each has a different group who can approve the content in their appropriate channel.

The group that can approve publishing pages in each channel is defined in the root web of the channel by doing nothing more than editing the Parallel Approval workflow on the Pages list, and then setting the correct group on the People Picker for the workflow approvers property. Since channel owners can create new sites in their channel using our custom provisioning process, we don't want them to have to go into the Pages list workflow settings to set the correct group every time, because as we all know, people make mistakes. Why not automate this process and set the right approvers group for the channel owner when the new site is created?

To do this, we created a Feature that we included in our custom site definition.  When a new site is created and the Feature is activated, we execute the following code:

            

              using System; using System.Collections.Generic; using System.Text; using Microsoft.SharePoint; using System.Diagnostics; using Microsoft.SharePoint.Workflow; using System.Xml; using Microsoft.SharePoint.Publishing; namespace Demo
{ publicclass FeatureReceiver
: SPFeatureReceiver { publicoverridevoid FeatureActivated(SPFeatureReceiverProperties
properties) { //get the SPWeb object for the Feature's
scope SPWeb currentWeb = properties.Feature.Parent as SPWeb; //set
the AllowUnsafeUpdates property to true so we can apply the change to the workflow currentWeb.AllowUnsafeUpdates
= true; //get the
parent web of the current web - this is where the correct workflow settings are SPWeb
parentWeb = currentWeb.ParentWeb; //get the Pages list
from the current web using the PublishingWeb object SPList currentWebPublishingList
= PublishingWeb.GetPublishingWeb(currentWeb).PagesList; //get
the current web Pages list's workflows SPWorkflowAssociationCollection currentWebWorkflows
= currentWebPublishingList.WorkflowAssociations; //if
the site has workflows, we need to get the parent web's workflow and apply the same
approvers to itif (currentWebWorkflows.Count
>= 1) { //find the parallel approval workflow SPWorkflowAssociation
currentWorkflowAssociation = currentWebWorkflows.GetAssociationByName("Parallel
Approval", currentWeb.Locale); //empty container
for the parent pages list workflow SPWorkflowAssociation parentWorkflowAssociation
= null; //get the
parent site's pages list SPList parentPagesList = PublishingWeb.GetPublishingWeb(parentWeb).PagesList; //if
there's workflows attached, we need to find the Parallel Approval workflowif (parentPagesList.WorkflowAssociations.Count
> 0) { parentWorkflowAssociation = parentPagesList.WorkflowAssociations.GetAssociationByName("Parallel
Approval", parentWeb.Locale); } //if we have the
parent workflow, we need to copy the review settings to the childif (parentWorkflowAssociation
!= null) { //xmldoc
for the parent association data XmlDocument parentAssociationData = new XmlDocument();
parentAssociationData.LoadXml(parentWorkflowAssociation.AssociationData); //xmldoc
for the child workflow association data XmlDocument currentAssociationData
= new XmlDocument(); currentAssociationData.LoadXml(currentWorkflowAssociation.AssociationData); //we
need to create a namespace manager object because the xml data we want is //namespaced
with 'xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD"'//the
following code was obtained from John Wood's blog//url:
http://www.dotnetjunkies.com/WebLog/johnwood/archive/2005/08/25/132153.aspx//this
code will add all namespaces in the xml to the namespace manager, allowing us to correctly//create
XPath queries to retrive the data we need XmlNamespaceManager nsmgr = new XmlNamespaceManager(parentAssociationData.NameTable); foreach (XmlAttribute
attr in parentAssociationData.SelectSingleNode("/*").Attributes)
{ if (attr.Prefix == "xmlns")
nsmgr.AddNamespace(attr.LocalName, attr.Value); } //get
the Reviewers node from the parent workflow XmlNode parentReviewers = parentAssociationData.SelectSingleNode("//my:Reviewers",
nsmgr); //get the Reviewers node from the child workflow XmlNode
currentReviewers = currentAssociationData.SelectSingleNode("//my:Reviewers",
nsmgr); //set the Reviewer node of the child workflow
to be the same as the parent currentReviewers.InnerXml = parentReviewers.InnerXml; //update
the child workflow's association data currentWorkflowAssociation.AssociationData
= currentAssociationData.OuterXml; //update the child
workflow association in the database currentWebPublishingList.UpdateWorkflowAssociation(currentWorkflowAssociation);
} } //make sure you dispose of the parentWeb object parentWeb.Dispose();
} publicoverridevoid FeatureDeactivating(SPFeatureReceiverProperties
properties) { } publicoverridevoid FeatureInstalled(SPFeatureReceiverProperties
properties) { } publicoverridevoid FeatureUninstalling(SPFeatureReceiverProperties
properties) { } } } 

          

I just updated the Ajaxify MOSS codeplex release to include the needed web.config entries for using the .Net 3.5 version of System.Web.Extensions.

There is, however, one manual step you still have to perform to the web.config files in order to get this to work right. You still need to add the dependentAssembly elements to the configuration/runtime/assemblyBinding element, as shown below:
 

I tried a whole bunch of different ways to get the xpath in the SPWebConfigModification object to try and get it to work, but I think the problem is that it's either too ambiguous because there's no unique identifier available on the dependentAssembly element, or the namespace on the assemblyBinding element is causing problems.

All the other entries are being applied correctly, though.  Also, I try and help out a little by outputting the nodes in the stsadm command output after the nodes are applied :) - see:

Just mark and copy the lines from there, and you're halfway there.

The command names are on the releases tab in the codeplex project.  If you're upgrading from the ASP.Net AJAX 1.0 framework, make sure you uninstall the config mods first, before you add the 3.5 config mods.

Final note: I hope to be adding the needed lines for SilverLight pretty soon.

A few days ago, I mentioned that we're trying to automate as much as possible in our new SharePoint based product, and I explained how we are creating custom search scopes in a Feature Receiver.

Another component we're automating is the creation of Crawl Rules for the search engine in the SSP the site collection is associated.

According to MSDN crawl rules are defined as follows:

Crawl rules provide you with the ability to set the behavior of the Enterprise Search index engine when you want to crawl content from a particular path. By using these rules, you can:

• Prevent content within a particular path from being crawled. 

• Indicate that a particular path that would otherwise be excluded from the crawl should be crawled.

Here's how we're creating the crawl rules in code using a similar Feature Receiver as before:

            using System; using System.Collections.Generic; using System.Text; using Microsoft.SharePoint; using Microsoft.Office.Server.Search.Administration; using System.Diagnostics; publicclass FeatureReceiver
: SPFeatureReceiver { SPSite currentSite = null; publicoverridevoid FeatureActivated(SPFeatureReceiverProperties
properties) { //Debugger.Launch();this.currentSite
= properties.Feature.Parent as SPSite; createCrawlRules();
} privatevoid createCrawlRules()
{ //get the site SSP's search server instance SearchContext
searchContext = SearchContext.GetContext(this.currentSite); //For
this example, I'll just show how to exclude the Explorer view of a list//Notice
how we're using wildcard characters to specify that every /Forms/WebFldr.aspx page//
will be excluded regaurdless of protocol or location in the site collectionstring crawlRule
= " *://*/Forms/WebFldr.aspx"; //get
the content source for the search server Content sspContent = new Content(searchContext); //check
to see if the crawl rule exists, and create it if it doesn'tif (!sspContent.CrawlRules.Exists(rule))
{ 

            

              //create the crawl rule, setting the type of crawl rule
and the crawl rule string CrawlRule crawlRule = sspContent.CrawlRules.Create(CrawlRuleType.ExclusionRule,
rule); //we want to make sure that the rule still works
if there are querystring variables crawlRule.FollowComplexUrls = true; //at
this point, you can set other properties such as authentication information to crawl//
content using a different identity or authentication method//
for more info , check out http://technet.microsoft.com/en-us/library/cc263150(TechNet.10).aspx//commit
the rule in the database crawlRule.Update(); } } 

            

              

                public
                override
                void FeatureDeactivating(SPFeatureReceiverProperties
properties){} 

              

                public
                override
                void FeatureInstalled(SPFeatureReceiverProperties
properties){} 

              

                public
                override
                void FeatureUninstalling(SPFeatureReceiverProperties
properties){} 

            
            

}

          

I've recently been working on a SharePoint project which is being offered to clients as a product built on top of the SharePoint framework.  While I can't describe in too much detail exactly what the product is, I figured it might be beneficial to discuss how we've built out certain aspects of the solution.  At the very least, I can compile some notes of my own so I can remember later how tackled some of the issues we had during the dev process.

To give a little background on the product, at the core, this is primarily a publishing-based solution that is deployed into a site collection. One of the goals in the development of the product has been to automate the creation of the site collection as much as possible when a new client purchases the product.  We're handling the bulk of the new client deployment through a Feature called 'Product.SiteConfiguration' that when activated, executes a Feature Receiver that both creates some higher-level components and populates 'default' data in areas of the site that are required for the product to function properly.

One of the things we're creating in the SiteConfiguration Feature Receiver is a locally defined, custom search scope that is specific to the site collection of the product. A search scope allows the narrowing of search results based on rules defined within the scope, so we wanted to create a scope that is specific to the product so that when a user searches from the product's generic search box, only items from within the product are returned.

Here's sample code used to create a new scope in a site collection:

            using System; using System.Collections.Generic; using System.Text; using Microsoft.SharePoint; using Microsoft.Office.Server.Search.Administration; using System.Diagnostics; namespace LocalDev.Demo.Code
{ publicclass SiteConfiguration
: SPFeatureReceiver { SPSite currentSite = null; publicoverridevoid FeatureActivated(SPFeatureReceiverProperties
properties) { string scopeName = "ProductScope"; this.currentSite
= properties.Feature.Parent as SPSite; //get
the site SSP's search server instance SearchContext searchContext = SearchContext.GetContext(this.currentSite); //get
the current scopes defined in the search server Scopes scopes = new Scopes(searchContext); //create
a URI object for the current site - used in checking for the scope we're creatingstring siteUrl
= this.currentSite.Url; Uri siteUri = new Uri(siteUrl); //create
scope object for the new scope Scope newScope = null; try { //this
is a little bit of a hack, but if it bombs, we know the scope doesn't exist newScope
= scopes.GetScope(siteUri, scopeName); } catch { //create
the new scope newScope = scopes.AllScopes.Create(scopeName, scopeName + "
Description", siteUri, true, "/_layouts/product/customsearchresults.aspx",
ScopeCompilationType.AlwaysCompile); //create the scopes
rules for the new scope//for example, include
content from the site newScope.Rules.CreateUrlRule(ScopeRuleFilterBehavior.Include,
UrlScopeRuleType.Folder, siteUrl); //save the changes
to the SSP Content Database scopes.Update(); //start
compilation of the scope scopes.StartCompilation(); } } publicoverridevoid FeatureDeactivating(SPFeatureReceiverProperties
properties) { } publicoverridevoid FeatureInstalled(SPFeatureReceiverProperties
properties) { } publicoverridevoid FeatureUninstalling(SPFeatureReceiverProperties
properties) { } } }

I've started getting tired of following the steps on Mike Ammerlaan's blog for Integrating ASP.NET AJAX with SharePoint.  It's not that the steps are difficult to follow, but there's a lot of stuff you need to get right if you want to have all the ASP.NET AJAX functionality available in MOSS.

To ease my own pains with this process - and hopefully yours, too - I've published to CodePlex some STSADM extensions for adding and removing the needed ASP.NET AJAX entries to the web.config file.

Much thanks to Gary Lapointe for providing the source code for his STSADM extensions.  It served as a great starting place for me and decreased the ramp-up time for creating my own custom STSADM commands tremendously.

View CodePlex site to download STSADM extensions for ASP.NET AJAX

<update date="6/19/08">

Telerik has released the MOSS compatable version of the RadEditor that places all needed files as class resource files in the _wpresource directory.  They've also made some very nice improvements over the previous release that make extending and customizing the editor very easy.  If you purchase and deploy the Full-Featrured RadEditor, you get ALL of the controls in the Telerik ASP.NET AJAX control suite available to you in MOSS.  Very nice...

</update>

Yesterday I posted about using the new RadControls for ASP.NET AJAX in MOSS, and I started moving the old controls in my current project over to the new ones.  Just now, I found a problem when I was converting the RadEditor from the old to the new.

In the Telerik online documentation for getting started with the RadEditor, they say that in a standard ASP.NET AJAX application, you need to utilize the App_GlobalResources and App_Data ASP.NET folders in order to use the RadEditor.

That's not any different for MOSS.

In the root of your SharePoint Web Application (\Inetpub\wwwroot\wss\VirtualDirectories\YourWebApp) create a folder named App_Data.  Drop in the RadSpell folder from the App_Data folder of the RadControls install directory (C:\Program Files\Telerik\RadControls for ASPNET AJAX Q1 2008).  Then, drop the RESX files from the App_GlobalResources directory located at the Telerik install root into the already present App_GlobalResources directory in your SharePoint Web Application root.

I think there's probably a better a way to do this using a Solution, but I'll worry about that later.  Not sure if we can deploy into those folders via a WSP - I don't think so.  I know there's a public property on the RadEditor that allows you to point to where the RadSpell directory is, but can't find anything for the RESX files.

Also, make sure you add the following line to the HttpHandlers section of your web config file, or else, spellcheck won't work:
<addverb="*"validate="false"path="Telerik.Web.UI.SpellCheckHandler.axd"type="Telerik.Web.UI.SpellCheckHandler, Telerik.Web.UI"/>

Anyway, here's a screen shot of the unskinned and unmodified RadEditor running in my local MOSS environment.  This is not tied into a publishing placeholder, but that's not what I'm using it for right now...

I've been a huge proponent of Telerik because of their very impressive controls, support, and documentation - let alone for the fact they are very easy to use.  Now that I've been working with SharePoint 2007 for a few years, I've found that Telerik's controls fit very nicely into MOSS.  Andrew Connell even created an integration whitepaper and some nice utility EXEs to help package the individual controls into WSPs to deploy them into MOSS.

Then, on April 15 of this year, Telerik released version 2008.1 of their new RadControls Suite for ASP.NET AJAX, formerly named 'Prometheus'.  I purchased my upgrade from the old RadControl suite to the Prometheus controls yesterday, and there was something that I noticed immediately which frightened me a little.  There's only one assembly - Telerik.Web.UI.ddl - and nowhere that I could see on the Telerik site that allowed me to get an individual control.

Uh oh. 

How do I get these amazing controls into SharePoint and start benefiting from that ASP.NET AJAX goodness?  Do I package the whole thing into a WSP? I hope not! That'll be a huge WSP file with all those skins getting packaged up!

I was worried, and started thinking that I was going to be stuck with a legacy version of some great controls, being forced to sit  here watching new versions go sailing past every three months.  No way!!!

I figured that there had to be a way, and if it took a massive WSP, so be it, so I started poking around the new control suite to see how it ticked.  There's no RadControls directory, so AC's walk-through documentation won't work.

I tested the RadSlider locally, and I asked myself, where do the images come from in the control?

I got out my trusty IE Dev Toolbar and took a peak.  I liked what I saw.

WebResource.axd!

Now, I don't care if this image is an embedded resource file or not.  It's not a direct reference to an image, and that's what matters.  What happens if a skin is applied? Where's the image then?

Office2007 skin:

IE Dev Toolbar:

Still a WebResource.axd. Excellent!

So - here's the deal.  Install the entire RadControls EXE which you get via your Telerik account on your SharePoint server.  Deploy the Telerik.Web.UI.dll to your SharePoint application's bin, and add the following line to the SafeControls block in the web.config

That's it...

Then, you can use any control in the entire suite just by adding the following Register tag to the page where you're using it

No more individual control references anywhere! Sweet!

For example - the RadTreeView control:

You can even deploy this inside your custom WSP by using the various Visual Studio project templates available on CodePlex.  I know of three that support deploying other assemblies, so finding them shouldn't be hard.  I'm partial to this one, and I know stsdev is really nice, as well.  You can even reference the Telerik control assembly server-side, too.  Just make sure you set the CopyLocal property of the reference to False.

You won't get IntelliSense for the controls, but as far as MOSS dev goes - what else is new, right?  There's plenty of documentation on Telerik's site to help with the control properties and client-side API.

Here's the new RadSlider with the Office2007 skin running in one of my MOSS environment:

I've started moving over all of the controls in my current project from the old version of the suite to the new version, and there's been some minor changes, but nothing of a pain at all.  The changes I have seen have been good ones, so it's been worth it so far.  Besides, these controls ROCK!  I haven't gone through and seen which ones work and which don't, but I'm sure it'll be similar to the old version of the suite.  I know the RadSplitter was a hassle before, will have to try it again with the new ones.  I've even noticed some performance gains over the old controls.

So, if you haven't picked up on it, I highly recommend these controls.  Not only will they completely expand your MOSS UI potential, but they will get you to install Service Pack 1 and configure ASP.NET AJAX in SharePoint if you haven't yet.  Remember, SP1 is required if you want to use ASP.NET AJAX, therefore, it's required to use these controls.

Having spent a great deal of time developing Microsoft Content Management Server 2002 solutions, I've found there's a bunch of stuff I miss from the MCMS API.  The single thing I miss the most:

CmsContext.Searches.GetByGuid(string) as HierarchyItem;

Being able to get any object - Channel, Template, Posting, Resource - by just it's guid was huge.  Even cooler was that you could grab an object out of anywhere in the hierarchy/taxonomy.  In SharePoint, you have to know the Web, List, and Item guid to find anything.  This one method in MCMS allowed a huge number of possibilities for custom dev with very limited coding time.

Another thing I miss from MCMS is the functionality of Connected Postings/Templates and an API that could CRUD them without hardly any effort.  I know Variations in SharePoint comes close, but IMO, it just doesn't seem to be at the same level and simplicity of MCMS.  Also, there's very little documentation around any of the Variation related objects because they've all been marked as internal.

Luckily, Michiel Lankamp figured this out - a long time ago - using Reflector (duh) and exposed that yes, everything in SharePoint is a list(thanks Matt). As Michiel points out, there's two variation lists. One called VariationSettings and one called VariationLabels who's guids are stored as Properties on the root web of the site collection.

Once you get the lists, how do you create the hierarchy? Check out Michiel's post to see how. Pretty clever...

I haven't tried this, and based on the four comments, not many other people have, either.  Also looks like it could be buggy.

Enable variations programmatically - Michiel Lankamp

When creating a WSP in WSSv3, the common development practice is to create a project in Visual Studio using the Class Library project template.  The problem with this is that none of the Workflow item templates are present when you try and add a new item, so how can you add a Workflow without having a one-off Visual Studio project just for your Workflow Feature?

The answer is that you need to make some changes to the project file in Visual Studio to make it happen.  The project file (YourProject.csproj - for example) is the file which tells the IDE what files, references, folders, etc. are present so that when the project is built, MSBuild knows how to compile the assembly correctly.

The steps I'll walk you through are intended for Visual Studio 2005.  You need to make sure you have the latest version of the Office Server SDK available from MSDN.  The steps are pretty much identical for Visual Studio 2008, you just need to make sure you change the targeted version of the .NET Framework to be version 3.0.

First thing - if you have the project under source control, you want to make sure the project file is checked out or else you won't be able to edit it.

Now, you want to unload the project in the IDE.  To do this, right-click the project and choose 'Unload Project'

Once the project has been unloaded, right-click the project again and choose 'Edit YOURPROJECT.csproj'  This will open the project file for editing in Visual Studio.

Locate the first PropertyGroup in the file at the top, and paste in the following code

            <
            ProjectTypeGuids
            >{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

as shown below

Now you need to make sure that the proper references are included

Locate the ItemGroup in the project file with the references

Paste in the following references after the last reference in the ItemGroup

            <
            Reference
            Include
            ="microsoft.office.workflow.tasks"
            />
            <
            Reference
            Include
            ="Microsoft.Sharepoint.WorkflowActions"
            />
            <
            Reference
            Include
            ="System.Workflow.Activities"
            />
            <
            Reference
            Include
            ="System.Workflow.ComponentModel"
            />
            <
            Reference
            Include
            ="System.Workflow.Runtime"
            />
            <!--
you probably already have the following -->
            <
            Reference
            Include
            ="Microsoft.SharePoint"
            />
          

Save the project file and reload the project

Now you have the Workflow item templates available, along with the support of the Workflow designer.

The final step is to change the base class for the Workflows you create. 

If you are creating a Sequential Workflow, you need to make sure the workflow class inherits from Microsoft.SharePoint.WorkflowActions.SharePointSequentialWorkflowActivity.  This will enable the SharePoint Workflow Activities in the Visual Studio Toolbox.  There is no base class for the SharePoint State Machine workflow other than the standard System.Workflow.Activities.StateMachineWorkflowActivity. 

The one main piece of advice I have is to make sure you set the base class of the Workflow class before you start working on it.  When you change the base class, all child activities will be removed from the Workflow.  At least they were removed for me!

Being Asp.Net developers, we all know we can send email from within custom code using the virtual SMPT server running on the Web Front End server where our code is running, but what if you want to use the same SMTP/Exchange settings you configured in Central Administration?

Luckily, there's a way to do so.

I like to create an object I call SPEmail for encapsulation, then within the Send method go dig for the info I need from the SPAdministrationWebApplication.Local and it's OutboundMailServerInstance property.  Once you have these objects, the information entered in Central Admin can be obtained and be used to set up the standard System.Net.Mail SmtpClient and MailMessage objects. 

No messing with the web.config file. Nice.

Here's the code for my SPEmail object:

            public
            class SPEmail
{ #region Constructors public SPEmail()
{ } #endregion#region Private
Members string _To = string.Empty; string _Subject
= string.Empty; string _Body
= string.Empty; bool _HTML
= false; #endregion#region Public
Properties publicstring To
{ get { returnthis._To;
} set { this._To = value;
} } publicstring Subject
{ get { returnthis._Subject;
} set { this._Subject = value;
} } publicstring Body
{ get { returnthis._Body;
} set { this._Body = value;
} } publicbool IsHtml
{ get { returnthis._HTML;
} set { this._HTML = value;
} } #endregionpublicvoid Send()
{ string smtp = string.Empty; string fromAddress
= string.Empty; string replyToAddress
= string.Empty; SPSecurity.RunWithElevatedPrivileges(delegate()
{ SPAdministrationWebApplication adminApp = Microsoft.SharePoint.Administration.SPAdministrationWebApplication.Local;
SPOutboundMailServiceInstance emailService = adminApp.OutboundMailServiceInstance;
smtp = emailService.Server.Address; fromAddress = adminApp.OutboundMailSenderAddress;
replyToAddress = adminApp.OutboundMailReplyToAddress; if (!string.IsNullOrEmpty(this.To))
{ SmtpClient mail = new SmtpClient(); MailMessage
message = new MailMessage(); message.From = new MailAddress(fromAddress);
message.To.Add(this.To); if (!string.IsNullOrEmpty(replyToAddress))
message.ReplyTo = new MailAddress(replyToAddress); if (!string.IsNullOrEmpty(this.Subject))
message.Subject = this.Subject; if (!string.IsNullOrEmpty(this.Body))
message.Body = this.Body; message.IsBodyHtml = this.IsHtml;
mail.Host = smtp; mail.Send(message); } }); } }

So - if you want to write your own, there you go!

Sigh...

After I put this together, I found that you can send email from within the SPUtility object.  SPUtility.SendEmail() will take care of all this for you, too. 

I'm working on a site which uses Forms Based Authentication, and I want to extend the standard user profile with some of my own custom properties.

I knew you could define a ProfileProvider in the MOSS web.config file, but the tricky part was getting and setting the values since the framework is unaware of the provider.  You can't access the properties at design-time like a normal Asp.Net Web Application, and I couldn't find any documentation for accessing Profile Provider Properties as a collection like propcollection["propname"].  I've seen a couple places where people talk about creating and using custom profile provider properties in MOSS, but there was nowhere that explained how to do it.

Then, yesterday there was the post on the MOSS Team Blog about the Profile Import Tool being released on CodePlex - which is very cool in itself.  I figured, CodePlex - open source; Profile Import - I bet they have code in their project that gets the properties out in the way I need since it's a dynamic process for importing profile property values.  Bingo!  Thank you Steve, Ron, and Lawrence!

Here's the code I used to Get/Set a custom profile property named 'UserCity' for the current user in MOSS, most of which was pulled and pieced together from the Profile Import Tool project:

Profile section in MOSS web.config:

            <
            profile
            defaultProvider
            ="MOSSPortalProfile"
            enabled
            ="true"
            automaticSaveEnabled
            ="true"
            >
            <
            providers
            >
            <
            add
            connectionStringName
            ="AspNetDb_ConnectionString"
            applicationName
            ="MOSSPortal"
            name
            ="MOSSPortalProfile"
            type
            ="System.Web.Profile.SqlProfileProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"
            />
            </
            providers
            >
            <
            properties
            >
            <
            add
            name
            ="UserCity"
            customProviderData
            ="DisplayName=City;"
            />
            </
            properties
            >
            </
            profile
            >
          

Get/Set C# code:

            //object
to hold the profile properties defined in the web config SettingsPropertyCollection
profileProperties = new SettingsPropertyCollection(); //get
the profile section from the web config ProfileSection profileConfigSection
= (ProfileSection)ConfigurationManager.GetSection("system.web/profile"); //get
the collection of defined properties RootProfilePropertySettingsCollection
configProperties = profileConfigSection.PropertySettings; //create
collection to contains properties to pass to the profile provider SettingsPropertyCollection
propertiesToReturn = new SettingsPropertyCollection(); //populate
the collection with properties from the web configforeach (ProfilePropertySettings
configProperty in configProperties) { SettingsProperty
profileProperty = new SettingsProperty(configProperty.Name);
profileProperty.PropertyType = Type.GetType(configProperty.Type); if (profileProperty.PropertyType
== null) { profileProperty.PropertyType = typeof(System.String);
} profileProperty.DefaultValue = configProperty.DefaultValue; propertiesToReturn.Add(profileProperty);
} //get the profile provider ProfileProvider provider
= ProfileManager.Providers["MOSSPortalProfile"]; //create
a SettingsContext for the current user SettingsContext userContext = new SettingsContext();
userContext["UserName"] = SPContext.Current.Web.CurrentUser.Name;
userContext["IsAuthenticated"] = true; //get
the values of the properties for the current user from the database SettingsPropertyValueCollection
returnVal = provider.GetPropertyValues(userContext, propertiesToReturn); //get
the value out of the collectionstring contactCity
= Convert.ToString(returnVal["UserCity"].PropertyValue); if (contactCity
== string.Empty) { contactCity = "Denver";
} //set value returnVal["UserCity"].PropertyValue
= contactCity; //save user profile properties back to
the database provider.SetPropertyValues(userContext, returnVal);