Category Archives: Visual Studio

SharePoint TechFest 2009 – Dallas, TX

I want to thank everyone who attended my session on SharePoint Workflow with Visual Studio at our TechFest event yesterday.  Please feel free to post any comments (good or bad) about my presentation or the event. 

Demo source code is posted on Nakido until the Techfest site is updated with session content.

SharePoint WorkFlow with Visual Studio – Downloads

SharePoint WorkFlow with Visual Studio – References it!

digg it!





Visual Studio 2008 Workflow Project Wizard – SharePoint Not Installed


I’m creating a SharePoint Sequential Workflow using Visual Studio 2008 (SP1) with .Net 3.5 SP1 installed.  This is on a Windows 2003 R2 VPC with SharePoint 2007 (MOSS Enterprise) installed on the local machine for development.  A Collaboration Portal is installed on a web site with host headers (portal) assigned to port 80.

When I create a new workflow project, the wizard asks for a path to the SharePoint site.  I type in my url (http://portal in my case), and the project wizard fails, saying “SharePoint server not installed. Please run Microsoft Office SharePoint Server 2007 setup.”  


I’m logged in as the farm administrator.  I thought it might be a permissions issue (my farm admin doesn’t have full rights on the domain), so I went back and gave it full Domain Admin rights in case that was the problem.  Still failing!!

What the hell?


It turns out that the wizard does some funny business behind the scenes, calling the database directly.  When I give my development account (farm admin) account full rights (dbo) to the SharePoint content database for my portal site, bingo!  Works like a champ. 

After only an hour or two spinning my wheels.  Sigh…. it!

digg it!




SharePoint – WSPBuilder Workflow Failed On Start

Building a SharePoint 2007 workflow using WSPBuilder and Visual Studio 2008.  Love, love, love the WSPBuilder tool, but the workflow templates could use some work.  Ran into this one today…


I was receiving “Failed on Start (retrying)” errors.  SharePoint logs showed “The workflow failed validation” exceptions.  This usually means a problem with the .rules files associated with a Declarative Rule Condition.  

I changed my While activities to use code conditions instead, and the problem went away.  But I really wanted to find the source of the issue.  After much trial and error and fruitless searches on the web, I finally found it.  Turns out, it was a missing import target declaration in the .csproj file created by WSPBuilder when I created a workflow project using the “WSPBuilder Workflow with Workflow” project template.


To fix the problem, opened up the project file and added the missing import target line (in green), below. Evidently, this line tells studio to include the .rules in the assembly.

     <Import Project=”$(MSBuildBinPath)\Microsoft.CSharp.targets” />
     <Import Project=”$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets” />

Reopened the project, recompile, build wsp, redeploy.  Bingo!  Now my workflow works with Declarative Rule Conditions, as it should!


Thanks to Greg G’s post here that pointed me in the right direction.

: it!

digg it!




WPF / WF – What Is A Dependency Property?

A new type of property, called a dependency property, was added to the .Net Framework with the release of .Net 3.0.  Dependency properties are used in both Windows Presentation Foundation (WPF) and Workflow Foundations (WF).  They are very similar in both frameworks, but are used for different purposes.

Dependency properties provides the plumbing for property value resolution, change notification, data binding, styling, validation, etc. for properties exposed in Windows Presentation Foundation (WPF) UI elements and Workflow Foundations (WF) custom activities.  Each dependency property is registered with a central repository that handles the change event notifications for you. 

Key Point – The Value of Dependency Properties Are Resolved

The ultimate goal of a dependency property, like any property, is to manage state.  But unlike normal .Net properties, the local property value is not stored in an instance variable. 

Instead, dependency properties are registered with the dependency property framework, and the underlying property value is resolved – meaning the value is determined by the dependency property framework based on rules defined by the property registration.

How To Create A Dependency Property

All WPF UI elements and Workflow Activities are derived from a high-level base classes called DependencyObject, which provides the basic functionality required to implement dependency properties.

public class MySampleControl : Control
    // Step 1: Register the dependency property 
    public static readonly DependencyProperty SpecialBrushProperty =
            DependencyProperty.Register("SpecialBrush", typeof(Brush), 

    // Step 2: Provide set/get accessors for the property
    public Brush SpecialBrush
        // IMPORTANT!!
        // -----------
        // Dependency property accessors should not include custom logic 
        // because the framework may call the base.GetValue() and 
        // SetValue() methods directly
        get { return (Brush)base.GetValue(SpecialBrushProperty); }
        set { base.SetValue(SpecialBrushProperty, value); }

As show in the code, there are two steps involved in creating a dependency property:

  1. Create a static field to hold a DependencyProperty object
    • By convention, the field should be named with the normal property name, followed by a “Property” suffix
    • This field will not contain the value of the property.  It simply defines the property that is registered with the dependency system
    • This field should be defined as a public, static, read-only field
      • The property must be available at all times, possibly shared among classes
      • The field is defined with the read-only keyword, meaning it can only be set in the static constructor of the type.
    • The field must be instantiated with a call to the static DependencyPropert.Register() method, passing:
      • The name of the property
      • The type of the property 
      • The type of the class that owns the property
      • Optionally, metadata used to define how the property is treated by the WPF framework
        • Meta-data flags to specify how the property affects the layout of the element (AffectsMeasure, AffectsArrange, AffectsRender, etc.)
        • Callbacks for handling property value changes (PropertyChangedCallback)
        • Callbacks to define custom value logic (CoerceValueCallback) 
        • Callbacks to validate values (ValidateValueCallback)
      • Optionally, metadata used to define how the property is treated by the WF framework
        • Include DependencyPropertyOptions enumerated value to specify additional characteristics for the property (ReadOnly, MetaData, etc.)
  2. Create property accessors (get / set)
    • Call DependencyProperty.SetValue() and GetValue() methods to set local values
    • DependencyObject is a high-level framework base class for WPF UI elements and WF activities
    • DependencyObject exposes the GetValue() and SetValue() methods

Isn’t That A Lot of Code for a Property?

At first glance, yes, this looks like an extremely complicated way to declare a property.  OK, at second glance, it’s still pretty complex.  But once you understand the power of dependency properties provide, especially in the Windows Presentation Framework (WPF), they’ll become a welcome addition to your coding toolbox. 

The convention takes a little getting used to. But after you’ve created a few, it comes quite naturally.  Visual Studio also includes some snippets to help add dependency properties:

  • Insert Snippet > NetFX30 > Define a DependencyProperty
  • Insert Snippet > Other > Workflow > DependencyProperty > Property

Subtle Differences Between in WPF and WF

While WPF and WF both use a similar dependency property frameworks, they are not identical!!

WPF UI elements and WF activities derive from a base DependencyObject class, and use a DependencyProperty class to register properties and get/set property values.  Despite the shared names, they are not the same classes!!

  • DependencyObject and DependencyProperty classes used by WPF reside in the System.Windows namespace
  • DependencyObject and DependencyProperty classes used by WF reside in the System.Workflow.ComponentModel namespace

Though their usage and function are very similar, they are not directly related to one another.

How are Dependency Property Values Resolved?

Property values for dependency properties are resolved automatically by the framework according to the following order of precedence:

  1. Property system coercion
  2. Active animations or animations with a hold behavior (WPF)
  3. Local value
  4. TemplateParent template properties (WPF)
  5. Implicit style (WPF)
  6. Style triggers (WPF)
  7. Template triggers (WPF)
  8. Style setters (WPF)
  9. Default (theme) style (WPF)
  10. Inheritance
  11. Default value from dependency property metadata

Note that the local value is 3rd in the order of precedence.  This means that a property may have a value, even if a local value for the property has never been set.  Also, if a property does have a local value, it may be overridden by higher level precedence items like an animation or data binding.

When Should I Use Dependency Properties In WPF?

Dependency properties are one of the most important concepts within WPF.  In WPF, dependency properties are required to support:

  • Data Binding
  • Animation
  • Styling
  • Value expressions
  • Property invalidation
  • Per-type default values

In short, it makes sense to expose dependency properties any time you expose a property for a custom UI element or control. 

When Should I Use Dependency Properties In WF?

Dependency properties are not used as heavily in Workflow Foundations (WF) as they are in Windows Presentation Foundation (WPF) , but they are still an important part of the WF framework.  They are used primarily when developing custom workflow activities that expose properties to support the following scenarios:

  • Activity Binding
    • This is the most common use of dependency properties in WF
    • Allows activities to expose properties that can be used to bind state to another activity
    • For example, binding the input of one workflow activity to the output of another workflow activity
  • Attached Properties
    • Attached properties are used to create a parent activity that can manage the state of it’s child activities
    • For example, the Conditioned Activity Group can attach a When property to each child
  • Meta Properties
    • Meta properties are defined by including new PropertyMetadata(DependencyPropertyOptions.Metadata) in the DependencyProperty.Register() method call 
    • Meta properties are set at design time and cannot be changed at run-time
    • Meta properties exist to guarantee the integrity of an activity
    • For example, at runtime, you can’t change the InterfaceType of an CallExternalMethod activity because InterfaceType is a meta-property

Sources it!

digg it!




SQL Server 2008 – How To Build and Deploy AdventureWorks OLAP Cubes

I’m trying to setup a simple OLAP demo, using MOSS 2007 Excel Services to display pivot tables and other spreadsheet data, connecting to SQL Server 2008 Analysis Services OLAP cubes.  In this case, I want to get it working with the AdventureWorksDW sample database.  I’m documenting the steps here to help others, and so that I can do it again without the pain!

To complete these steps, you will need SQL Server 2008 installed with the database engine, Analysis Services, FILESTREAM and Full Text Search services enabled.  You’ll also need the Visual Studio Business Intelligence project templates installed to build and deploy your cube using SQL Server Business Intelligence Development Studio (BIDS).

1. Install the AdventureWorksDW Sample Database

First, you’ll need to install the AdventureWorkdsDW sample database from CodePlex.  To install it, you’ll need FILESTREAM and Full Text Search enabled.  For more detailed instructions, see my blog post, SQL Server 2008 – Installing the AdventureWorks Sample Databases.

2. Install and Deploy the AdventureWorks Cubes

After you’ve installed the AdventureWorks DW database, you need to setup a SQL Server Business Intelligence Developer Studio (BIDS) project to create and deploy a cube.  You can find the sample BIDS project located at C:\Program Files\Microsoft SQL Server\100\Tools\Samples\AdventureWorks 2008 Analysis Services Project.  There are 2 projects there, depending on your version of SQL Server you’re using.

  1. Open the sample Adventure Works.sln BI solution using Visual Studio
  2. Change the data connection options for the source database
    1. Expand the solution folders in the Solution Explorer and double-click the Adventure Works.ds data source to open the properties.  This is a data connection to the AdventureWorksDW database, which will serve as the source database for the cubes we’re creating
    2. Edit the connection string and set the connection properties.  I just changed localhost to server name of my database server, using the default Windows Authentication mode.
    3. Click the Test Connection button to test your connection
    4. Exit the configuration dialog to save your changes
  3. Change the data connection options for the Analysis Services database
    1. Select Project > Properties from the Visual Studio menu to open the project options dialog
    2. Select the Deployment options
    3. Change the server to the database server / instance here Analysis Services is installed.  This is where your cube will be created.
    4. By default, the database name is Adventure Works DW 2008.  This is the Analysis Services database that will be created to host the cubes.
    5. Click OK to exit the properties dialog and save your changes
  4. Build the project
    1. Select Build > Build Solution from the Visual Studio menu to build the solution and check for errors.
    2. Select Build > Deploy Solution from the Visual Studio menu to deploy the project.  This will create the cubes and other Bi database objects in the database. 

3. Browse the AdventureWorks Cubes

After your cube has been deployed, you can browse your cube data in the Visual Studio BIDS interface, or in SQL Server Management Studio:

Browse cube data in Visual Studio

  1. Select the AdventureWorks cube in the cubes folder of your BIDS project
  2. Right-click the cube and select Browse from the context menu
  3. Drag/drop measure and dimension data to play with your cube data

Browsing OLAP Cube Using Visual Studio

Browse cube data in SQL Server Management Studio

  1. Open SQL Server Management Studio (Start > Programs > MIcrosoft SQL Server 2008 > SQL Server Management Studio)
  2. Connect to the Analysis Services database
    1. Select File > Connect Object Explorer from the SQL Server Management Studio menu
    2. Select Analysis Services in the Server Type dropdown
    3. Enter the server name and authentication options and click Connect
    4. Expand the Analysis Services server in the object explorer and browse to the Adventure Works DW 2008 > Cubes
    5. Select the AdventureWorks cube, right-click, and select Browse from the context menu
    6. Drag/drop measure and dimension data to play with your cube data, as show below

Browsing OLAP Cube Using SSMS it!

digg it!




What is OBA anyway?

OBA (Office Business Applications) is using Microsoft Office products and related applications to put your applications in the hands of users where they spend most of their time every day, in Office applications.  It’s a ubiquitous term, but at the heart of it, OBA solutions deliver information and functionality from a variety of systems to the user where they need it most.

OBA’s can expose data from custom applications and ERP systems, or even merged data from multiple systems, and deliver custom UI’s and custom automation interfaces available directly in Word, Excel, PowerPoint or Outlook.  You can use VSTO tools to build Office Add-Ins and templates that can inject data from these applications into their documents, or simply to display inside these applications as users work. 

With Visual Studio 2008 and VSTO, Microsoft has made it easy to surface your data inside the Office suite in a variety of ways.  The flexibility is stunning, and will spin your head a bit.  The new toolset, and the integration of Office and Visual Studio, Microsoft has given us the power to build some amazing applications.

When you build OBA’s, you’ll be leveraging the following tools:

Microsoft Office SharePoint Server 2007 (MOSS)

  • Web Site Provisioning
  • Custom Lists and Document Libraries
  • Content Types
  • Business Data Catalog
  • Forms Server
  • Excel Services
  • BI Dashboards and KPI’s
  • Custom Features and Solutions
    • Custom Content Types
    • Custom Lists
    • Workflow
    • Event Receivers
    • Custom web parts

Office 2007

  • Document Information Panels
  • Custom Ribbon Add-In’s
  • Custom Task and Action Panes
  • Custom Add-Ins
  • Code-Behind Templates
  • Custom XML Parts
  • Word Custom Controls
  • Excel List Databinding
  • Excel User-Defined Functions

Visual Studio 2008 and the .Net Framework

  • SharePoint Project Types
  • Office Project Types
  • Integrated Debugging and UI Support
  • Click-Once Deployment

Here’s a list of resources to get you going

Transitioning to SharePoint 2007 (MOSS) Development

My background is in ASP.Net C# development.  I recently transitioned to SharePoint 2007 (MOSS) and OBA (Office Business Application) development.  As I learn, I hope to share my experiences here.

MOSS + Office + Visual Studio is a powerful toolkit – a platform for building productivity applications that goes way beyond building portals.  Throw in some Reporting Services, InfoPath, BI, AJAX, and SilverLight and things really get interesting.  It’s also a huge space, with a steep learning curve. I’ve learned a few things along the way, and I hope to find time to document some of them here to help others that want to make the transition or learn more about MOSS and OBA.

To get started, I recommend the following books, to be followed in the order listed.  Read them, build out your own lab environment, do the labs, absorb as much as possible, and you’ll be on your way.  It’s an exciting space, with much more to come.

Microsoft SharePoint: Building Office 2007 Solutions in C# 2005 (Expert’s Voice in Sharepoint) by Scot P. Hillier
An excellent overview of the functionality and capabilities of SharePoint 2007, WSS and MOSS. If you’re getting your feet wet with MOSS development, this is a great place to start. Includes complete labs that walk you through setting up a networked MOSS environment using VPC’s. My copy is heavily abused, I refer to it often.

Workflow in the 2007 Microsoft Office System by David Mann
A great reference for MOSS Workflow development. This is the only WF book I’ve found that covers custom MOSS workflow in-depth. If you’re doing your first custom MOSS workflow in Visual Studio, this book will save you lots of time and frustration.

Pro SharePoint Solution Development: Combining .NET, SharePoint and Office 2007 (Expert’s Voice in Sharepoint) by Ed Hild
Covers a bare minimum of MOSS basics and dives deep into custom Office solution development with real-world samples projects building OBA’s leveraging MOSS, Word, Excel, PowerPoint and Outlook. Covers custom feature development including content types, custom lists, custom actions and event receivers, BDC’s, Workflow, and Open Xml and document packaging code samples. Lots of useful code goodies.

Microsoft® Office SharePoint® Server 2007 Administrator’s Companion by Bill English
This book is a great reference book for SharePoint Administrative tasks and guidelines. Makes for a very boring read, but is an excellent reference for SharePoint infrastructure guidelines.