Skip to content
This repository has been archived by the owner on Mar 11, 2020. It is now read-only.

Home

Jump to bottom
taoneill edited this page Oct 28, 2016 · 90 revisions

Welcome to the Dynamite wiki!

Make sure you start with readung the Dynamite project README and its Quick Start Guide.

In this wiki you will find:

Building maintanable and modular SharePoint farm solutions with Dynamite

Why Dynamite? Why farm solutions?

SharePoint 2013 introduces the new App-model for SharePoint custom solution development. Microsoft's guidelines are clear: in 2013, whenever possible, build things the App-way. While Apps have the benefit of de-coupling your custom functionality from your mission-critical on-premise SharePoint infrastructure, the SharePoint client-side APIs do come with some limitations.

Full-trust SharePoint solution development is still the most powerful option for customizing your SharePoint 2013 farm. If you are still developing in a SharePoint 2010 context, farm solutions are your only option (if we ignore the unpopular and soon-to-be-deprecated sandbox solution model).

The Dynamite project for SharePoint 2013 (built by GSoft's SharePoint development experts - Team Dynamite) is a C# toolkit of reusable components that guide you into the "right" path for full-trust solution development. A version of Dynamite for SharePoint 2010 is also available, for all of you who are still supporting legacy environments.

Some essential values put forward by Dynamite are the following:

  • A truly modular architecture through Dependency Injection
    • to promote code reuse across projects
    • to make your components easy to test
    • to provide extension points for alternative usages of your features (i.e. configurability)
    • to avoid massive multi-project deployments when possible (i.e. modular rather than monolithic deployments)
  • Entirely automated deployments through templated PowerShell scripts
    • to avoid error-prone manual operations at all costs
    • to provide a reproducible installation process in any SharePoint farm environment
  • Intelligent, code-driven, self-correcting features
    • to reduce risk when upgrading your SharePoint solutions
    • to eliminate your dependency on SharePoint's often hard-to-upgrade XML-based definitions
    • to easily maintain your solutions in the long term within the enterprise

Many of these ideas take their origin in Microsoft's patterns and practices team's famous SharePoint 2010 development guide. The Dynamite toolkit and the guide that follows are the end results of applying many of these ideas in the wild in real-life enterprise scenarios since 2010.

1. A modular approach to building SharePoint farm solutions with Dynamite and Autofac

2. Automate your deployments and upgrades end-to-end with the Dynamite PowerShell Toolkit

  • On the evils of Visual Studio-based deployments
  • Installing Dynamite's very own PowerShell module
  • Templating your PowerShell scripts thanks to the Update-DSPTokens command
  • Best practices when deploying and updating your WSP farm solutions
    • Always strong-name you assemblies, since that's a requirement for all full-trust code being run within SharePoint
    • Always open a new PowerShell window after a deployment which updates DLLs in the GAC
    • Restart OWSTimer.exe so that timer jobs can see the new DLLs as well
    • In complex BCS scenarios, restarting the search service can also be required
    • When in Visual Studio, to ensure correct packaging of your WSP solutions, you should always retract everything from the GAC - i.e. retract all you WSPs responsible for provisioning DLLs. This ensure that Visual Studio builds your projects with your project-folder-local dependencies instead of unexpectedly loading
    • Don't trust the "Specific Version" parameter when you add a project reference:
      • Its only meaning is: "use this specific AssemblyVersion of my dependency" when building my own projet
      • At runtime (i.e. once deployed to GAC), your own assemblies will always require the same AssemblyVersion'd dependencies be present in the GAC as well
      • So you should always use "SpecificVersion=TRUE" to ensure you don't compile using a rogue-version assembly (otherwise, once you deploy, at runtime you may have "Missing assembly" problems

3. Making the best of Dynamite: discover its powerful and time-saving utilities

  • Easy logging to the ULS (SharePoint's Unified Logging System) thanks to Dynamite's ILogger
  • Error-free resource management through the IResourceLocator interface
  • The case for intelligent, code-driven, self-correcting features
    • E.g. provision your content types and lists programmatically instead of through XML for maximum flexibility during upgrades
    • SharePoint's great upgrade conundrum: what to do with "click-programming" customizations that took place since your last deployment?
  • Promote the isolation and testability of business logic through easily serializable Entities and Dynamite's entity mapping utilities.
  • Centralize your Javascript dependencies to avoid script conflict in your web pages

Git beginner's guide

All of Team Dynamite's projects are hosted on Github. We recommend using Atlassian's SourceTree git client for source control management. This guide should help you get started on the path to contributing to the Dynamite project.

< Go back to Dynamite wiki home

Clone this wiki locally