Use NPM and gulp build tasks to support Continuous Integration with VSTS and Azure for an AngularJS app

Interesting stuff from Matt, will have to incorporate this into the Invoice Form Application.



This is the first in a series of posts will take you through the steps required to take a static website, in my case an Angular SPA and deploy this to an Azure App Service (Web App) via Visual Studio Team Services (VSTS). The Angular SPA is secured by ADALJS and the last part of this series will help us use gulp tasks within VSTS to configure the Angular app for different environments.

The application is built using Visual Studio Code all in HTML and JavaScript, so no Visual Studio and no VS builds. The aim is that when we check code into VSTS source control a build task will run and deploy this into Azure for us. Although my app is written in Angular, only the last post makes actual reference to this and shows anything Angular specific. Your app could be written with any framework you like…

View original post 489 more words

Dev Diary Entry 1: Azure Web App with MVC WebAPI, Angular and Azure DocumentDb


This is the first time that I have tried writing a developer diary. So I would really appreciate it if you could let me know if you find it useful.

I find when I start building an Azure based application that I forget what I had to do the last time.

At the moment, my career has been working a lot with SharePoint and I want to move over to doing more Azure stuff. However, until I actually start doing more Azure applications then the process of building applications in Azure is not going to flow.

So this diary is for me to remind myself of what I did, plus I want to be completely transparent. When I find a problem or hit a blocker (no matter how stupid it is) I am going to try explain what it was, what I tried to do to fix it and hopefully the final fix.

It should be interesting to see where the application goes.


So what are we going to build?

Well currently I use a product called Microsoft InfoPath to manage my invoices to customers. InfoPath is no longer being worked on and Microsoft have said that it will not be supported after 2023 I thought why don’t I build something that a find useful and use that as an experience to learn. So here we are.

So we are going to build an Invoice management system, which allows someone to create, edit, view and publish an Invoice as a PDF into a SharePoint Online document library.

There are a load of other things that I am thinking about that would be useful, like reminders to send out invoices and being able to integrate with time management applications like Toogle and create invoices from those data endpoints.




The application is going to be built in two parts:-

  • Client side Angular SPA application served by Azure Web Apps.
  • Azure hosted WebAPI MVC application using Azure Document Db to host the content

Invoice Form App Architecture

The application will use Azure AD as the authentication and authorisation engine. For monitoring, errors, statistics we will use Application Insights and both the Angular and MVC components will use the same Application Insight key so that we keep all the monitoring together.



Before I started the application I wanted to do some reading on Angular, Azure Document Db as I have never built anything with these technologies before.

I am using Angular 1.0 at Angular 2.0 is still in development. I have made the choice to build the client side using JavaScript rather than TypeScript. Though I am likely to convert over to TypeScript but thought that process would be interesting to capture.

So this is my reading list before I start:-


Development Environment

I am building this application with Visual Studio Code for the client side and Visual Studio 2015 for the MVC Web API component.

I wanted to build something with Visual Studio Code so that I learnt more about Node, Node Package Manager, Bower, Gulp etc.

I don’t really know what all those things are but we will find out!


Next Steps

So the next steps are to create the solutions for the Angular application and the MVC Web API.

That will explained in the next entry.


Thanks for reading.


Updated with SharePoint 2010 Version of Script

SD Blogs

Update: 10th June 2012

A few people have posted comments about the script not working for SharePoint 2010. This code was built for SharePoint 2007. However I have been through the code and an updated version can be found below.

Apologies that it has taken a while to respond.

The SharePoint 2010 Code version works slightly differently and uses the jQuery Live method and JavaScript OnMouseOver event to update the PDF’s a tags.


One of our clients wanted a way to ensure that Adobe PDF’s did not open in the current browser window.

By default a PDF opened into Adobe Acrobat will open in the current browser window.

This presents a usability problem as user’s lose the reference to the site they were in also other applications, such as Word and Excel, do not behave in this way.

How Acrobat opens a document…

View original post 704 more words

Visual Studio Tip: Using SharePoint Site Url in Pre-Deployment and Post-Deployment scripts.

Within Visual Studio 2010 SharePoint projects you might want to use the SharePoint Site Url that you have specified for your SharePoint project in Pre or Post Deployment scripts.

The SharePoint Site Url value can be retrieved using the $(SharePointSiteUrl) variable.


For example, this variable could be used in a pre-deployment script to deactivate certain features for the debug configuration.

To add the Pre Deployment script do the following:-

  • From Visual Studio 2010
  • Open your SharePoint Solution/Project
  • Click Project Properties
  • Click the SharePoint Tab
  • Add the following script to the Pre Deployment Script text box.
echo SiteUrl: $(SharePointSiteUrl)
if "$(ConfigurationName)" == "Debug" (
stsadm -o deactivatefeature -name "Feature1" -url $(SharePointSiteUrl) -force
stsadm -o deactivatefeature -name "Feature2" -url $(SharePointSiteUrl) -force
stsadm -o deactivatefeature -name "Feature3" -url $(SharePointSiteUrl) -force
stsadm -o deactivatefeature -name "Feature4" -url $(SharePointSiteUrl) -force
stsadm -o deactivatefeature -name "Feature5" -url $(SharePointSiteUrl) -force

Hope that helps.

For more information on Pre and Post-Deployment steps see this MSDN Link:

How to: Set SharePoint Deployment Commands (



Visual Studio SharePoint Packaging Issue: Both "SharePointItem" and "SharePointItem" contains a file that deploys to the same Package location.

I have had this problem a few times when moving and copying SharePoint SPI objects within Visual Studio 2010.

When you attempt to package and deploy your SharePoint solution the following error occurs:-

  • C:\TFSBulid\4\Project\BuildLocation\Sources\ProjectName\Package\Package.package: Both “[ExampleSiteDefinition]” and “[ExampleSiteDefinition]” contain a file that deploys to the same Package location: [Location]

The problem occurs because two of the SharePoint Project Item (SPI) have references to the same location. This seems to occur when you copy SharePoint Project Items.

If you take a look at the SharePointProjectItem.spdata file for the SharePoint Project Item that you copied from the SharePoint Point Item specified in the [Location] portion of the error message you will see that the SharePointProjectItem.spdata file will show details of the old SharePoint Project Item rather then the new SharePoint Item.

The content of the SharePointProjectItem.spdata looks like this:-

 1: <?xmlversion="1.0"encoding="utf-8"?>
 2: <ProjectItemType="Microsoft.VisualStudio.SharePoint.SiteDefinition" DefaultFile="onet.xml" SupportedTrustLevels="FullTrust" SupportedDeploymentScopes="Package"
 3: xmlns=>
 4: <Files>
 5: <ProjectItemFileSource="default.aspx" Target="SiteTemplates\ExampleSiteDefinition\"
Type="TemplateFile" />
 6: <ProjectItemFileSource="onet.xml" Target="SiteTemplates\ExampleSiteDefinition\Xml\"
Type="TemplateFile" />
 7: <ProjectItemFileSource="webtemp_ExampleSiteDefinition.xml" Target="1033\XML\"
 8: </Files>
 9: </ProjectItem>

To fix this update the ProjectItemFileSource element’s Target attribute to point to the correct location.

Corrupted List Url Fix: Link to SharePoint List points to /_layouts/listedit.aspx?List=[ListGuid]


Had an issue at a client where a SharePoint task list got corrupted.

The issue had come about due to the list being copied using Metalogix SharePoint Migration Manager within the same site. The copy of the list had been corrupted so that if you clicked on “View All Site Content”, then clicked on the list name you were taken to the Edit List Settings page (/_layouts/listaspx.aspx?List=[GuidOfList]). Once in the list settings page, clicking on the breadcrumb to take you back to the list would take you to the web application homepage.


The fix was actually quite straightforward, if you typed in the url of the list correctly, http://sharepointsiteurl/sites/site/lists/My%20List%20Name, you could access the default list view with no problem. So I used a similar method to fix that I have used in this blog post, Manage Content and Structure error.

To fix:-

  • Delete the list using List Settings->Delete this list.
  • Restore the list from the recycle bin

Voila! The link within “View All Site content” is now working as expected.

Experiences applying SharePoint Themes to a SharePoint Farm

So I have already written this blog post once, but Windows Update decided to reboot as I was finishing the blog post. Unfortunately I hit Ctrl + V as it asked if I wanted to save the post – then it rebooted.

Windows Live Writer has an auto save post function, I have now enabled this to save further frustrations. Shame it’s not on by default!

Anyway so what did I write..?

I have been recently updating some themes that have already been deployed to a SharePoint farm. I thought the process would be pretty straight-forward as the files were already packaged up as a WSP. I thought the process would be something like this:-

  • update theme.css within the theme folder
  • package up the changes into a WSP file
  • update the solution with stsadm –o updatesolution

Unfortunately this wasn’t the case.

So what happened? Well I updated the solution and loaded up the SharePoint site and nothing had changed. “Ah ha” I thought it’s probably because IE is caching the CSS file. So pressed CTRL+F5 to expire the cache the page loaded again with no change.

Using the IE developer toolbar I selected the element and used trace style to find out why the CSS class hadn’t changed. The toolbar opened up a strangely named CSS file called ITSP1001-65001.css. Looking at the CSS styles I could see that yep, the style hadn’t changed.

So what the heck was this file? I certainly hadn’t created it and its not in my THEME folder inside c:\program files\common files\microsoft\web server extensions\12\template\themes\THEME.

After some investigation and reading a couple of blog posts such as this one from Shane Perran’s blog site. (

I discovered that the file is automatically created when a theme is applied.

So what happens? Well SharePoint merges the following css files:-

  • core.css
  • [alternative css file for your site definition]
  • theme.css

This creates a file using the first 4 letters of the THEME name with 1001-65001.css  appended to the end. This file along with the rest of the files from the Theme folder is uploaded into a folder _theme/THEMENAME found at the root of the site. You can see this folder in SharePoint Designer.

So because this file is only created when you apply a theme that is why it was not updated when the solution updated. So I applied the theme again and still no luck!

It turns out that you need to apply another theme first such as CLASSIC and then reapply your custom theme.

Tada the theme is now updated!

Unfortunately the process of reapplying the theme is tedious but fortunately Gary LaPointe’s stsadm extensions came to the rescue in the form of stsadm –o gl-applytheme (

The following stsadm commands were used:-

  • stsadm –o gl-applytheme –theme CLASSIC –url [http://sharepoint]
  • stsadm –o gl-applytheme – theme THEMENAME –url [http://sharepoint]

Once all the changes had been made then all the sites needed to be updated, not a fun task! Once again the stsadm –o gl-applytheme came to the rescue in the form of a recursive option.

Using the stsadm command with the recursive option all the SharePoint site collection were updated in no time.

I hope that this post helped, if you have any questions or there is something that you need more info on then just leave a comment.

Thanks for reading