Preparing Stand-alone SharePoint Farm for Apps Development

Microsoft has made it very easy to setup an development environment on Azure and if you are a MSDN subscription owner it is practically free. To get started with SharePoint development on Azure just follow the instructions published by the SharePoint team last year. Once you have the farm running you still need to complete additional steps to be able to develop and run Apps for SharePoint. Before you can start following the instructions provided by Microsoft some DNS configuration is required.

Assuming you are running with a single server NTML based setup, here is what you need to do:

  1. Use ipconfig /all through the command line to make notes of the machine IP and outside DNS server address
  2. Create a zone for the machine, name it e.g. sharepoint.local . Then make sure there is a host under the sharepoint-local pointing to the machines own IP.
  3. Edit the properties of the (DNS) server itself and add to the list of forwarders one pointing to the outside DNS server
  4. Create a zone for your apps, name it e.g. (primary zone)
  5. Add a cname under the with the fqdn * and “full target name for target host” being e.g. <machine name>.sharepoint.local
  6. Finally check everything is working by running ipconfig /flushdns followed by trying to access your local SharePoint and the internet. Try also pinging e.g.

DNS settings


Embedding YouTube videos into PowerPoint

Today I needed to grab a video from YouTube to include in a PowerPoint presentation. PowerPoint is quite picky about the formats it supports and you don’t want to embed too large files either.

Here is how I solved this:

  1. Download the latest version of the WinX YouTube Downloader. It is free and the only freeware tool I could find that did not seem to contain spyware or potential viruses. Beware of the online download services!
  2. Using the downloader produces a MPEG4 file that of course only the VLC player might be willing to show unless you have QuickTime installed. VLC  is not able to convert MPEG4 files to other formats without loss of quality, so don’t stop reading yet.
  3. Install QuickTime (only install the essentials if you don’t need the player) and the Microsoft Expression Encoder
  4. Microsoft Expression Encoder might have difficulties displaying the video, but you should managed to edit and then export a decent quality WMV video (file taking only 20% of the original file size) that PowerPoint will be more than happy to accept.


Native vs. Hybrid vs. HTML5: the enterprise perspective to mobile app deployment

Mobile apps are the hot topic of 2013. Lately I’ve participated in numerous seminars and taken the time to read articles and blog posts to gain a better understanding of the subject. There seems to be a war going on – companies in the business either toot for one truth (usually that native aps are best) or take a more liberal approach warning only about the risk of analysis paralysis (in other words, don’t over think).

Big companies like Google and Microsoft are investing millions to get developers to use their platform – Everyone is in for the  money. In the world of internal enterprise applications the emphasis is a bit different – it is all about the balance of cost and end user value.

So, when working on a internal solution you have two advantages on your side:

  • You can define what platform the users should use and even provide them the hardware. A decent smartphone costs around 200€ per unit. So e,g, for a sales team with 10 members, it most likely costs less to update their phones than to try to support 2-3 different operating systems – and who would say no to a brand new device?
  • For the external users we have no control over HTML is the only standard that will work on all imaginable devices now and in the future without extra effort. It is surprising how much device functionality is accessible through JavaScript.

In the table below, I’m comparing the 3 different options for app deployment from the enterprise perspective:

Feature Native Hybrid Mobile Notes
Deployment cost across multiple platforms Single OS support, depending on case multiple versions (e.g. Android 4.x) or a single (e.g. Windows Phone vs. Windows 8 Phone) is supported. Code sharing possible. Multiple OS and versions, depending on product support. Some OS dependent rework (e.g. UI) usually required. Works on all platforms, including desktop and mobile devices. Support for HTML5 features varies by browser.
Updating and control over distribution App stored based deployment requires strict compliance with OS vendor specifications resulting in delayed updates. Possible workarounds for internal apps (e.g. company HUB for Windows) requiring usually MDM system for deployment. Usually some sort of paid phone developer account required. App store distribution possible. Updating without resubmission. No explicit distribution required, always most recent version online. Own or leased infrastructure required (web server).
Development and building The vendor of the OS usually defines the tools and platform you have to invest in. Often a mixture of common and proprietary tools. Deployment to e.g. iOS requires often a Mac even if you can develop on a PC. Any text editor will do.
Monetary benefits   Not applicable for internal tools
High performance Best Adequate
User experience and native look and feel Pixel perfect  Not often so pixel perfect. Usually UI must be (re)design per supported platform. Responsive design adapting to screen dimensions. Frameworks available to give native look and feel.
Availability of developers and level of experience Available skills depend on popularity of platform. Chance of finding someone who knows multiple platforms well is small. Same tooling might apply as for rich client development. Experts usually more costly. Often requires some specialized product dependent skills. Easy to find skilled web developers. Wide open source communities.
Platform stability Changes often with every new OS release (1-2/year). Changes require recompilation. Availability of support for latest OS releases and features dependent on product. HTML standard is updated once in 5 years with backward compatibility. Support for features intorudced by standard increase by time.
Graphic support Full support Product dependent WebGL for 3D
Access to device services and functions Full support Product dependent, usually possible to map to OS specific libraries. Support for most functions (etc. Camera and Geolocation, phone state), isolated from the native ecosystem.
Support for touch screen devices Full support Some gestures supported
Protection of application and data security Source code closed in the same way as with desktop applications. Common methods of data protection and isolation available, therefore considered often more “secure”. Application code can be obfuscated. Data more difficult to explicitly protect, but a secure connection, browser and the OS provide already a decent level of protection In general local data should not be trusted
Support for offline use Yes Yes Yes (local storage, events, file system). Support is browser dependent.

Hard to choose?

A good rule of thumb is to go native if you are building and mobile client for a rich client application and go HTML5 if your system is already web based.

How to integrate with SharePoint


There are numerous options to how to integrate your LOB systems with SharePoint. The answer tends to depend on who you ask, as SharePoint experts will tell yo to use BCS, Microsoft oriented consultants might recommend WCF /AppFabric and SAP consultants will tell you to go with Duet. The right approach depends of course on the actual business requirements. In this article I I will try to summarize the different approaches and highlight their pros and cons.

Continue reading

Linking SQL Server to an Access database

Even if importing an old Access database to SQL Server is pretty easy using available tools, this might not always be the optimal solution. Linking an old Access mdp file to your SQL Server enables you to gradually move old legacy databases and systems to leverage the power and stability of a server database as you can leave the old dependencies untouch while implementing new ones to use the server.

Setting up an Access database as a linked server on a SQL Server requires a number of steps. For those in a hurry and not wanting to read the whole article, this is what you need to do:

  1. Install the 64 bit database driver
  2. Configure the Access Database Engien provider settings
  3. Allow users full access to the temp directory of the SQL Server service account
  4. Setup the linked server

First thing to do is to get the Jet database drivers installed on the server. As Access first did not support 64 bit operating the drivers are not available out of the box. Don’t worry, you will not need to restart after installing this.

Then go to Server Objects — Linked Servers — Providers and you should see the newly installed “Microsoft.ACE.OLEDB.120.0” driver. Open it’s properties and check both “Dynamic parameters” and “Allow inprocess”.  Provider properties

Then complete this  first step by enabling the ‘Ad Hoc Distributed Queries’ setting with the the following command:

sp_configure ‘show advanced options’, 1;
sp_configure ‘Ad Hoc Distributed Queries’, 1;

 Now you will avoid getting errors when trying to browse or access items in the database.

SQL Server needs to use the temp directory of the SQL Server service account for handling the linked server. For things to work and you to avoid any “Unspecified errors” you need to make sure also the account accessing the linked server has access to that same temp directory (the security settings of the link seem to have no affect on this). The quick and dirty solution to this is to give the account(s) or all users access to the temp directory under the application data folder under the account profile. The proper solution is to:

  1. create a new temp folder for the service account (or use c:\temp)
  2. change the TMP and TEMP environment variables of the service account to point to the new folder — this will require restaring the server for the changes to take effect
  3.  setup a group with the accounts that need access to the database to give it full control over the folder.

As a final touch before setting up the actual linked server you might need to take the time to define a SPN for the service account in cases when the database file is not on the same server as the SQL Server.

Finally go to Server Objects — Linked Servers and add a new linked server. Give it any name you like to identify it and select Office Access Database Engine as the driver. The define the connection parameters as follows:n

  • Product name can be anything you like, usually the type of the database e.g. ACCESS
  • Data source defines the path to the database file
  • Provider string can be used to define additional connection string parameters

Linked server properties

Make sure to check that the settings on the Security page are has you want to have it. Then click on OK.

Now to make sure the linked server actually works, first open the context menu of the new linked server and select Test Connection. Then browse through the structure down to the tables to see if SQL Server is able to display you the objects in the database. If no errors are displayed the link is now ready and you can go and get your self your well deserved hot beverage.

The best JavaScript MVC framework

I’m a great believer in frameworks as they provide a SOLID and well tested infrastructure for you solutions. Modern web apps are base on a almost excessive amount of JavaScript on the client side and REST services on the server side. There are a lot of frameworks that support this and the challenge for developers is to figure out on which one to invest their time on. Even if  the teams behind the products encourage to mix these, the reality is that  doing so will only result in hacks – in other words the framework needs to be complete.

So, on what horse did I decide to bet on? The answer is AngularJS.
Why? Let me telly you:

  • It tells a lot about a framework if the most basic examples reveal many features but are also easy to understand
  • Unlike the jQuery+Knockout+whatever combos it provides a complete framework which not only guides developers to setup the app in a certain way but also supports testing by design
  • It is a product of a big company (Google) but unlike Kendo it is 100% free making it easy to to take into use and to find developers already familiar with it. Not to mention that it is actually possible to find reviews without any commercial BS.
  • Unlike e.g. Ember it is a mature framework with a good online documentation and active community.
  • It provides templating by allowing to extend the standard set of HTML/DOM elements with your own components. Personally I find this approach most intuitive and clear.
  • The apps are based on controllers, directives, filters and services. There is a inbuilt support for dependency injection.
  • Unlike Knockout there is no need to use special observable object types in your model to get the data binding to work.
  • The Chrome and Angular teams have worked together to provide a browser add-on to help debugging.
  • It has no (inbuilt jQuery lite) dependencies on other frameworks unlike backbone, ember and most others.

Time will show if my investment pays off 🙂

Worth reading:

SharePoint Web Part Basics

All web parts are based on the same basic ingredients. When I started developing on my first web parts I did some extra work to find out the best practices. This post is meant to work as a simple reference and to answer some of the questions I had when I first started.

What web parts events should I use?

There are many different opinions on this. This is mine:

  • Never put code in the constructor as it might be called even if the object is later never used
  • In the OnInit initialize any controllers etc. you might have
  • In the CreateChildControls method create your controls, but don’t populate them. Note that it is a common practice to define all the controls and the wepart layout in a separate control class to keep the web part clean.
  • In the OnPreRender load the data into the controls and setup any async task you might need (they will be executed next)

How to register JavaScript?

There are many ways to include JavaScript on a page, the right one depends on your need. To include a script to to be executed directly after page load use the RegisterStartupScript combined with the ExecuteOrDelayUntilScriptLoaded (SOD) or _spBodyOnLoadFunctionNames.push functions:

public static class SharePointScriptHelper
public static string ExecuteOrDelayUntilScriptLoaded(Control control, string script, string after)
string script = string.Format("ExecuteOrDelayUntilScriptLoaded(function(){{{0}}}, '{1}');", script, after);
ScriptManager.RegisterStartupScript(control.Page, typeof(Page), "Script_" + control.ID, script, true);
SharePointScriptHelper.ExecuteOrDelayUntilScriptLoaded(this, "alert('Hello world!');", "SP.js");

The first mentioned takes care of the correct load order of scripts.

To include e.g. a library that is not meant to be directly executed use e.g. the RegisterClientScriptInclude method:

ScriptManager.RegisterClientScriptInclude(this.Page, typeof(Page), "MyScriptNamespace", ScriptFileUrl);

The point in using the ScriptManager is to avoid having the same script included multiple times, hence the key parameter in e.g. RegisterclientScriptInclude. The class offers a lot of functions that are worth taking a closer look at.

Note that is is a good practice to wrap you scripts in a “class”/namespace to avoid e.g. function name collisions with other scripts.

To easily include the web part id in your inline scripts you can use the ReplaceTokens function of the web part class to do this. It will simply replace tokens like e.g. _WPID_ with the correct property values.

How to include CSS on a page?

CssRegistration css = new CssRegistration();
css.After = "corev4.css";
css.Name = Settings.StyleSheetFileUrl;

I have not yet had a chance to test SharePoint 2013 to see if it works to refer to the corev4.css also in that version.

Where to define configuration parameters?

The web part definition file (yourwebpart.webpart) is definitely the only correct place. This way they the properties are fully customizable by the site owners when necessary.

Never store passwords in any file as they belong in the secure store service. You can prevent property values from being exportable for a simple way of hiding them.

How should I define my layout?

The most flexible and powerful way is to use XSLT for the rendering. You can implement it your self or inherit the DataFormWebPart class.

Where should I put the CSS, image and other files?

Put them in the appropriate SharePoint mapped folders. Always create a sub folder for you web part and give it a unique name e.g. based on the namespace of the main class.

How to do logging and debug?

Use the inbuilt framework. The most elegant solution would be to write your own service class deriving from the SPDiagnosticsServiceBase but note that it will need to be registered at deployment time.

public static class SPDiagnosticsServiceExtension
public static void WriteTrace(this SPDiagnosticsService service, string message, string categoryName, TraceSeverity severity)
SPDiagnosticsCategory category = new SPDiagnosticsCategory(categoryName, TraceSeverity.Unexpected, EventSeverity.Information);
service.WriteTrace(0, category, severity, message);


SPDiagnosticsService.Local.WriteTrace(ex.ToString(), "Web Parts", TraceSeverity.Unexpected);

I strongly recommend enabling the Developer dashboard and using the SPMonitoredScope to help optimize the performance of your web part.

That’s all for now, more to to come later.