Contents tagged with SharePoint

  • SharePoint.DesignFactory.ContentFiles - Installation

    The SharePoint.DesignFactory.ContentFiles tooling can be used to develop, test, package and deploy SharePoint files and metadata that can be uploaded to the SharePoint content database. Use this tooling for developing and packaging your master pages, page layouts, style library files, web part configurations and any file you can think of that can be uploaded to the SharePoint content database. Works on SharePoint 2007 (on SharePoint server), SharePoint 2010 (on SharePoint server or remote) and Office365 (remote).

  • SharePoint.DesignFactory.ContentFiles NuGet package released

    Wouldn’t it be great to edit your SharePoint 2007/2010/Office365 content files like master pages, page layouts, web part files, style library files etc. etc. in Visual Studio, use intellisense, source control and the XSLT debugger, but without the overhead of creating complex xml files, manifest files and WSP packages? Wouldn’t it be great if you could package those file and deploy them through Dev, Test, Acceptation and Production without WSP packages? Now you can!

  • SharePoint.DesignFactory.ContentFiles

    Welcome to the landing page of the SharePoint.DesignFactory.ContentFiles NuGet package.

    Please see the following blog posts:

    Documentation SharePoint.DesignFactory.ContentFiles


    The DesignFactory.SharePoint.ContentFiles mechanism is designed for deploying SharePoint files with optional meta data to a SharePoint environment. This SharePoint environment can be:

    • a local environment, running on the same machine as where you are developing or deploying your content files
    • a remote environment, running on either the same machine or a machine that is accessible remotely over http.

    In both scenario's the files will end up in the SharePoint content database, as if they were uploaded by hand. This means that files are deployed in another way than if they were deployed using a WSP package using features and modules. Files are deployed as customized files. See Understanding and Creating Customized and Uncustomized Files in Windows SharePoint Services 3.0 for a good article on customized and uncustomized files.

    Project structure

    A SharePoint.DesignFactory.ContentFiles project has the following strucure:

    • ProjectFolder
      • _MachineConfiguration - configuration files describing connections to SharePoint web (SPWeb)
        • Default.ps1 - configuration file used if there is no specific configuration file for the currenty machine (MACHINE.ps1)
        • Machine1.ps1 - machine specific configuration file
        • Machine2.ps1 - machine specific configuration file
        • SPDesign.ps1 - configuration file for SharePoint web to be used for importing artifacts in project folder if no specific configuration file to use for import is specified [not used yet]
      • _Tools
        • Deploy.cmd - command for deploying all changed files in project
        • Redeploy.cmd - command for deploying all files in project
        • Package.cmd - command for packaging the files in the project
        • Clean.cmd - command to mark all files in the project for redeployment
        • SharePoint.DesignFactory.ContentFiles.ps1 - the script implementing all functionality. Can be called directly as well for more advanced features
        • ContextExtensions... - folder containing extension functions that can be used in ObjectModel and ClientObjectModel
        • Documentation... - folder containing documentation
        • Lib... - folder containing a library of reuseable functions
        • MSBuild... - folder containing a SharePoint.DesignFactory.ContentFiles specific MSBuild targets file
      • MasterPages - A folder mapped in Mappings.xml for deployment to SharePoint
        • MyMaster.master - file to be deployed to SharePoint
        • - metadata for the file to be deployed to SharePoint
        • ...
      • PageLayouts
        • ...
      • ...

    Some remarks on the above project structure:

    • The project structure can be used from any tool that is your favorite HTML editor, like:
      • Visual Studio 2010 (lower versions are supported, but not through nuget package installation)
      • WebMatrix 2.0 (still in beta, does support nuget package installation)
      • ... enter your vaforite web editor here ...
    • Visual Studio 2010 has many enhancements for working with SharePoint.DesignFactory.ContentFiles


    The Mappings.xml file describes a relationship between the project folder and where artifacts in the project folder should be deployed in to SharePoint. The Mappings.xml file looks like:

    <ContentFilesMappings xmlns="">
            <Mapping projectFolder="RootFolder" destinationFolder="/" />
            <Mapping projectFolder="Documents" destinationFolder="/documents" />
            <Mapping projectFolder="Masterpages" destinationFolder="/_catalogs/masterpage" />
            <Mapping projectFolder="PageLayouts" destinationFolder="/_catalogs/masterpage" />
            <Mapping projectFolder="Style Library" destinationFolder="/Style Library" />

    A Mapping node describes the mapping from a project folder to a SharePoint folder.

    The Mapping node attribute projectFolder':

    • refers to a folder within the project
    • must be specified
    • may not be empty
    • may not point to the root folder of the project, only files from subfolders can be uploaded

    ProjectFolders for multiple Mapping elements must be disjunct; e.g. valid is:

    <Mapping projectFolder="sub1" ... >
    <Mapping projectFolder="sub2" ... >

    invalid is:

    <Mapping projectFolder="sub1" ... >
    <Mapping projectFolder="sub1\sub3" ... >

    The Mapping node attribute destinationFolder:

    • specifies a folder within SharePoint relative to the SharePointWebUrl as specified in the machine configuration file
    • must be specified
    • may not be empty
    • to specify the root folder in 'SharePointWebUrl' specify '/'

    If the destination folder does not exist yet it will be created as an SPFolder. Any child folders below the projectFolder will result in corresponding child urls (SPFolders) in the destination folder.

    Working with the command-line tools

    The following command-line tools are available for performing the simple tasks involved in working with SharePoint.DesignFactory.ContentFiles:

    • _Tools\deploy [machineconfigurationname] - deploy changed files in the project using configuration MACHINE.ps1, Default.ps1 or specified configuration
    • _Tools\redeploy [machineconfigurationname] - deploy all files in the project using configuration MACHINE.ps1, Default.ps1 or specified configuration
    • _Tools\package - package all files in the project
    • _Tools\clean - mark all files in the project for redeployment

    For more advanced actions like deploying or marking for deployment a single file or folder the underlying PowerShell script _Tools\SharePoint.DesignFactory.ContentFiles.ps1 can be used. To see the available parameters open a PowerShell command prompt in the project foder and execute the following command:

    get-help _Tools\SharePoint.DesignFactory.ContentFiles.ps1

    Open this script file for more details on the available arguments.

    Visual Studio 2010 integration

    There is extensive integration with the Visual Studio 2010 IDE if SharePoint.DesignFactory.ContentFiles is installed as a NuGet package:

    • Create a new ASP.NET 3.5 Web Application project - File -> New -> Project..; Select .NET Framework 3.5; Select template Visual C# -> Web -> ASP.NET Web Application
    • Ensure that the Macaw NuGet repository is accessible:
      • Open Tools -> Library Package Manager -> Package Manager Settings
      • Go to Package Manager -> Package Source
      • Add source: Name = Macaw NuGet, Source =
    • Add the SharePoint.DesignFactory.ContentFiles NuGet package to the project and solution:
      • Open Tools -> Library Package Manager -> Manage NuGet Packages for Solution...
      • Select Online and the source Macaw NuGet
      • Now select the SharePoint.DesignFactory.ContentFiles package and hit Install. Add the package at both the project and solution level.

    Right click menus

    The SharePoint.DesignFactory.ContentFiles NuGet package adds right click menu entries if the Managed Menu Extension (MME) is installed. These extension can be installed through the Visual Studio 2010 UI:

    1. Open Tools -> Extension Manager..
    2. Select Online
    3. Search for managed Menu Extension (MME)
    4. Select managed Menu Extension (MME) and hit Install

    Close and reopen the Visual Studio 2010 instance containing your project to get the right click menu's loaded.

    The following right click actions are now added:

    On SharePoint.DesignFactory.ContentFiles project:

    • DesignFactory -> Deploy changed files
    • DesignFactory -> Deploy all files
    • DesignFactory -> Mark all files for deploy
    • DesignFactory -> Package
    • DesignFactory -> Documentation ContentFiles

    On mapped folder (folder in project mapped to SharePoint folder with Mappings.xml):

    • DesignFactory -> Deploy changed files in folder
    • DesignFactory -> Deploy all files in folder
    • DesignFactory -> Mark folder for deploy
    • DesignFactory -> Documentation ContentFiles

    On mapped file (file in folder in project that is mapped to SharePoint folder with Mappings.xml): - DesignFactory -> Deploy file - DesignFactory -> Deploy all files in folder - DesignFactory -> Mark file for deploy - DesignFactory -> Documentation ContentFiles


    The SharePoint.DesignFactory.ContentFiles NuGet package adds the following configurations to the project and to the solution, besides the Debug and Release configurations:

    • Deploy: build project in Debug mode, and deploy changed content files
    • Redeploy: build project in Debug mode, and deploy all content files
    • Package: build project in Release mode, and build package

    The following action is also supported when you right-click on a project:

    • Clean: marks all files in the project for redeployment, default project clean action is executed

    Select a configuration and build the project/solution. The configurations correspond with the command-line commands.

    It is also possible to add additional configurations using the Visual Studio Configuration dropdown, with at the end Configuration Manager.... In this way the following additional deployment commands can be added:

    • Deploy machineconfigurationname, i.e. Deploy Office365
    • Redeploy machineconfigurationname, i.e. Redeploy Office365

    Note that a solution configuration builds projects with a specific configuration. This works fine after installation of the NuGet package. If the SharePoint.DesignFactory.ContentFiles package is uninstalled and installed again, the solution configurations are not aligned anymore to the project configurations. To align again open the Configuration dropdown, and select at the end Configuration Manager.... Now align solution configurations with project configurations.

    Machine configuration files

    A machine configuration file is used to describe how to deploy the current project to SharePoint. The machine configuration file describes a deployment to a local machine (SP2007/SP2010) or a remote machine (SP2010). Deployment to the local machine can be done using the ObjectModel or the ClientObjectModel. Deployment to a remote machine is done with the ClientObjectModel. A machine configuration file is:

    • Located in the folder MachineConfiguration in the project folder
    • Named after the machine name, i.e. MYMACHINE.ps1 for the default deployment (Deploy.cmd, Redeploy.cmd) OR
    • Named as wanted. Requires explicit deployment, i.e. Deploy NAME, Redeploy NAME.
    • The machine configuration file Default.ps1 will be used for deployment if no machine specific configuration file exists
    • TODO: The machine configuration file SPDesign.ps1 will be used for importing SharePoint artifacts if no explicit configuration file is specified

    This machine configuration file is executed as a PowerShell script and returns a Hashtable with the following keys:

    • SharePointDeployment - MANDATORY
      • ObjectModel (on server itself, SP2007/SP2010)
      • ClientObjectModel (remote, SP2010)

    If ObjectModel is used for deployment, sharepoint is accessed with the credentials of the current user (integrated security).

    • SharePointWebUrl - MANDATORY
      • Example: 'http://myserver/sites/mysitecollection'

    Url to the SharePoint web site where the content files must be deployed to. In most cases this is the root site of a site collection, but it can be any SharePoint site. The content files in the package can only be deployed to locations within the specified site.

    • UserName - OPTIONAL
      • 'DOMAIN\UserName'

    User name to authenticate with. Must be in the format DOMAIN\UserName. If not specified check if the credentials to authenticate for the SharePointWebUrl are specified in the Windows Credential Manager.

    • Password - OPTIONAL
      • 'MyPassword'

    Password to authenticate with.

    • UseClaims - OPTIONAL
      • $true or $false

    Boolean that specifies if authentication should be done using claims authentication. This is for example the case for Office365. Note that claims-based authentication for now only works with SharePointDeployment set to ClientObjectModel.

    Authentication is done as follows:

    1. If SharePointDeployment is set to ObjectModel
      • Always use integrated security (credentials of currently logged in user)
    2. If SharePointDeployment is set to ClientObjectModel
      • If UserName,Password is specified and not empty, use these
      • Otherwise use the credentials specified in the Windows Credential Manager for Url SharePointWebUrl
    3. If no credentials found --> error.

    Using these key,value pairs multiple authentication approaches can be taken:

    Integrated security:

        SharePointDeployment = 'ObjectModel';
        SharePointWebUrl = 'http://myserver/sites/mysitecollection';
        UserName = '';
        Password = '';
        UseClaims = $false;

    Integrated security (as short as possible):

        SharePointDeployment = 'ObjectModel';
        SharePointWebUrl = 'http://myserver/sites/mysitecollection';

    Explicit authentication (ClientObjectModel deployment only):

        SharePointDeployment = 'ClientObjectModel';
        SharePointWebUrl = 'http://myserver/sites/mysitecollection';
        UserName = 'DOMAIN\UserName';
        Password = 'Password';
        UseClaims = $false;

    Explicit authentication (ClientObjectModel deployment only), but user name and password configured in Windows Credential Manager:

        SharePointDeployment = 'ClientObjectModel';
        SharePointWebUrl = 'http://myserver/sites/mysitecollection';
        UseClaims = $false;

    Explicit claims-based authentication (ClientObjectModel deployment only):

        SharePointDeployment = 'ClientObjectModel';
        SharePointWebUrl = 'http://myserver/sites/mysitecollection';
        UserName = 'DOMAIN\UserName';
        Password = 'Password';
        UseClaims = $true;

    Explicit claims-based authentication (ClientObjectModel deployment only), but user name and password configured in Windows Credential Manager:

        SharePointDeployment = 'ObjectModel';
        SharePointWebUrl = 'http://myserver/sites/mysitecollection';
        UseClaims = $true;

    How files are marked for deployment

    The Archive atribute is used to mark files for deployment. if the Archive attribute is set, the file must be deployed. After a file is successfully deployed the Archive attribute is cleared. The Archive attribute can also be set on read-only files.

    There is a case where the Archive attribute is fooled. If a file that is under TFS source control is reverted to an older version, the file should be deployed again. On Revert the Archive attribute is not set, so the file will not be deployed, although it has been updated (to an older version).

    In case of reverting from TFS source control, mark the specific file or folder for deployment.

    NuGet package installation

    When the NuGet package is installed in Visual studio the following actions are performed:

    • Add the configurations Deploy, Redeploy and Package to the project and to the solution
    • Add import of targets file SharePoint.DesignFactory.ContentFiles.targets in the project file to provide handling of building the configurations Deploy, Redeploy and Package, and a target Package for automating packaging
    • Remove the folders App_Data, Scripts and Default.aspx from the project if it is a web project
    • Copy assembly VSMenuManager.SharePoint.DesignFactory.ContentFiles.dll to the solution folder for right click menu extensions (requires restart of Visual Studio to be picked up)

    This tool is copyright 2012, Macaw.

  • SharePoint 15: What is coming?

    Something everyone busy with SharePoint would like to know: what will be the new features of SharePoint? What has been changed in the existing functionality? A lot of information that will point us in the right direction is available now from the source…

  • DualLayout for SharePoint 2010 WCM Quick Start

    DualLayout for SharePoint 2010 WCM is a solution to provide you with complete HTML freedom in your SharePoint Server 2010 publishing pages. In this post I provide a quick start guide to get you up and running quickly so you can try it out for yourself. This quick start creates a simple HTML5 site with a page to show-case the basics and the power of DualLayout. We will create the site in its own web application. Normally there are many things you have to do to create a clean start point for your SharePoint 2010 WCM site. All those steps will be provided in later posts. For now we want to give you the minimal set of steps to take to get DualLayout working on your machine.

  • no longer usable as a blogging platform?

    I get swamped by spam on my weblog. Both comments spam and spam through the contact form. It is getting so bad that I think the platform is becoming useless for me. Why o why are we bloggers from the first hour still in stone age without any protection against spam. Implementing Captcha shouldn’t be that hard… As far as I know this is the same blogging platform used by Aren’t all Microsoft bloggers getting sick from spam? In the past I tried to contact the maintainers of, but never got a response. Who maintains the platform? Why are we still running on a Community Server Edition of 2007? Please help me out, or I’m out of here.

  • Fun: Quoted on SharePoint 2010 Development with Visual Studio in InfoWorld Article

    When I was at the SharePoint Conference 2009 in Vegas I was sitting in the hallway working on my little white Mac Book writing a blog post on SharePoint 2010 when a guy passed by. “Can I ask you some questions?” “Sure”, I said. “If I did anything with SharePoint?” he asked me… Ok, sitting with a Mac on a Microsoft conference can be strange, but hey: VMware Fusion did let me run the Technical Preview of SharePoint 2010 on my little Mac Book with 4GB, which couldn’t be said of my Dell running Windows XP at the time, not supporting 64 bits virtualization with Microsoft tools. We talked for a few minutes, he made some audio recordings, and off he was.

  • SharePoint 2010: #SPC09 - SSP is dead, long live Service Applications!

    Notes from the SharePoint Conference 2009 session "Introduction to Service Applications and Topology". This is my personal interpretation of what has been said during the presentation. Don't shoot me if I interpreted something wrong:-)

    In SharePoint 2010 Shared Service Providers (SSP's) are replaced by Service Applications. Services are no longer combined into a SSP. Services are running independent as a service application.

    So in MOSS 2007:
    SSP: combines services like Search, Excel Services, User Profiles, ... into a shared service provider.

    In SharePoint 2010:
    Service Applications: services like Search, Managed Meta Data, .., your service (20 services in SharePoint Server) are running "unboxed" and independent.

    So SharePoint 2010 provides a la carte unboxed services. You can configure which services are running on an application server. Per web application you can configure which services are consumed.

    When migrating MOSS 2007 to SharePoint 2010 SSPs will upgrade into Service Applications.

    SharePoint Foundation 2010 (WSS 4.0) provides the SharePoint Service Application Framework.
    New products like Office Web Apps, Project Server, Gemini (PowerPivot) use this application framework, and this platform can also be used by third parties or you to create custom services.
    You can plug your management UI for your service into the Service Management page.

    A web application does not communicate directly to a service application, but does this through a proxy:
    Web Application <-> Service Application Proxy <-> Service Application

    So a general workflow can be:
    Browser -> Web Front End ->(Request) Application Server ->(Result) Web Front End -> Browser

    SharePoint 2010 does contain a fault tolerant round-robin software load balancer with support for hardware load balancing, so it is possible to have multiple application servers.

    The Service Application infrastructure provides application isolation: each service application can use separate databases if needed and optionally run in separate app pool. There is support for multiple service apps for a service with different accounts and databases ==> Great for multi-tenancy (hosting for multiple customers on same platform)

    Services are flexible, secure and provide cross-farm federation:

    • Trust based security between farms, claims based authorization within the farm
    • Share to anyone, consume from anywhere
    • WCF based web services for communication
    • No direct DB Access
    For example: Taxonomy, has cross farm federation. Probably same for content types?


    You can manage which services are running on a server.
    In Central Administration UI: list of services, indented under a service you see the proxy.

    Through the wizards you get database names with guids at the end. Better to create manually form Central Administration, or create services through PowerShell.

    Per web application you can configure which services apps you want to be available. By default all web applications use all service applications available. You can change this into a custom configuration. Use the Manage Service Associations page for this.

    Service applications can be published to make them available outside the current farm. It allows you to select the connection type, for example https or net.tcp. Note that there must be a trust relationship with the farm that wants to consume your service. The service is published on a url. Through this url an other farm can find the published services. Url is in the following format: https://myfarm/Topology/topology.svc

    The other farm can connect to your farm through a remote service connection.

    Although manual adminstration and configuration of SharePoint 2010 can be done through Central Admin, the future of SharePoint administration is PowerShell.

    With respect to Services:

    returns the set of service applications.
    Do Get-SPServiceApplication-name yourservice to get the service object. Do Get-SPServiceApplication -name yourservice | fl to see all properties of the service object.

    There are almost a hundred Cmdlets to manage your services.

    Side note: It now really becomes time that all administrators learn PowerShell. In my company (Macaw) we use PowerShell extensively for our Macaw Solutions Factory. Everything from configuration, build and deploy through DTAP is done with PowerShell.

    It is possible to delegate management of a particular service to someone, that person then has only access to that the management UI in Central Administration for that particular service.

    Access security: specified claims principals have access to a service application. By default the "farm claim" has access, but this can be removed ad more detailed claims can be configured for more granular access rights, or example read versus read-write.

    Service applications can spawn their own timer jobs.

    Generally ISV's will build service applications on the SharePoint Service Application Framework, but for large organizations it could be interesting for SI's to create services to specialized functionality and farm-to-farm fedaration .

    For repeatable configuration over your DTAP configuration, use PowerShell to create and manage the services.

    You can create complex farm configurations where farms can share service applications. For example: two farms can share the user profile service.