BM-Bloggers

The blogs of Black Marble staff

DDD is Back for the 12th Time

 

After last year’s successful reboot, DDD is back in Reading for its twelfth outing, on Saturday, 10th of June.

 

Again DDD is free for all to attend, thanks to some great sponsors – and if you would like to be considered, please email ddd@blackmarble.com.

Our aim is to make DDD accessible to all, making it free is key to this but also leaves us limited budget for the nice to haves but we will always try.

I would love to see new speakers and new topics in the DDD line up, so please submit a session.  I’m afraid we can’t cover your costs, but so many great speakers have come out of DDD, many of them prized on the International Developer conference circuit.

 

Session submission has finished and so please vote on which sessions you would like to see @ http://developerdeveloperdeveloper.com/

 DDD12

I look forward to seeing you all in June and we will be announcing more DDD dates at the event

 

b.

Policing and HoloLens

 

Recently we had a great day demonstrating the great innovations we have made with HoloLens for the Police to a room full of jaded but ultimately enthusiastic, technology journalists.

It was great to see their responses to the solutions we have put together, and heartening to read some of the things they had to say.

Police

Alice Bonasio (Tech Trends) produced this great piece on how MR CSI isn’t SciFi anymore! It was great to see how she could see the potential in what we had produced, “With tuServ you can effectively have a fully functional portable Command and Control Centre.”

 

With HoloLens and tuServ, we have envisaged a real-world solution, that can make a difference in how police officers can do their job.

Back Again and HoloLens

 

I have been a bit quiet on the blogging front for a while as I have been deep in planning for community events and steeped in the joys of HoloLens.

 

The results, two more DDD community events on the way (Reading and the North), and Black Marble has been made one of Microsoft’s HoloLens Agency Readiness Partners.  So few companies have achieved this, it’s great recognition for all the hard work we have put in, and I’m looking forward to what we can achieve.

 

What have we been doing with HoloLens?

 

Under the banner of tuServ we have build a mobile command and control solution for the Police…

 

Black-Marble-HoloLens-848x400

 

The reactions and feedback have been amazing and I am so proud of our both our tuServ and HoloLens teams for producing a great product.

But we did not stop there we also have build a prototype Scene of Crime tool for HoloLens as well; more on that to come.

 

Good to be Back

 

b

 

Debugging Typescript in Visual Studio Code

This is one of those posts I do as a reminder to myself. I have struggled to get debugging working in VSCode for Typescript files. If I set breakpoints in the underlying generated JavaScript they worked, but did not work if they were set in the Typescript source file. There are loads of walkthroughs and answers on Stackoverflow, but all with that vital little bit (for me) missing. So this is what I needed to do for my usage scenario…

Whilst developing a Node based VSTS extension I have the following structure

Git repo root (folder)

--- .vscode (folder)

------ launch.json

--- mystuff.src   (the source .TS files)

------ script.ts

------ tsconfig.json

--- mystuff    (the target folder for the .JS files)

I develop my Typescript in the .src folder and use the TSC compiler to generate the .JS file into the target folder, running the ‘tsc –p .’ command whilst sitting in the .src folder.

Note: I actually run this Tsc command using Gulp, but this post does not need to go into detail of that.

The key thing is to make sure the two .json files have the correct options

The tsconfig.json is

{

"compilerOptions": {

"target": "ES6",

"module": "commonjs",

"watch": false,

"outDir": "../mystuff/",

"sourceMap": true

},

"exclude": [

"node_modules"

]

}

The important lines are highlighted

  • The path to generate to .JS to – for me it was important to generate to a different folder as this made it easier to create the VSTS extension packages without shipping the .TS files by accident.This was part of my debugging problem as if the .ts and .js files are in the folder the should be no issues
  • Creating the source map which enables debugging, the .JS.MAP files

The launch.json is

{

"version": "0.2.0",

"configurations":

[

{

"type": "node",

"request": "launch",

"name": "Node – my stuff",

"program": "${workspaceRoot}/mystuff.src/script.ts",

"outFiles": ["${workspaceRoot}/mystuff/*.js"]

}

]

}

The critical lines, and the ones I messed up are

  • Program must point at the .TS file
  • Outfiles must point to the location of the .JS and .JS.Map files in the target folder and those square brackets [] are vital

Once I had all this in place I could set breakpoints the .TS file and they worked

Two new tasks in my Manifest Version VSTS Extension

I have just released a new version of my VSTS Manifest Version Extension (1.5.22). This adds two new tasks to the set of versioning tasks in the extension. The complete set now is

 

  • VersionAssemblies - sets the version in the assemblyinfo.cs or .vb (used pre build)
  • VersionDotNetCoreAssemblies - sets the version in the *.csproj (used pre build)  - cross platform
  • VersionAPPX - sets the version in the Package.appxmanifest (used pre build)
  • VersionVSIX - sets the version in the source.extension.vsixmanifest (used pre build)
  • VersionDacpac - sets the version in a SQL DACPAC (used post build)
  • VersionNuspec - sets the version in a Nuget Nuspec file (used pre packing)
  • VersionSharePoint - sets the version in a SharePoint 2013/2016/O365 Add-In
  • VersionWix - sets the version in a Wix Project

 

As with all the other tasks, these new tasks aim to find files recursively to update with a version number extracted from the build number

Version .NET Core CSPROJ file

This is a cross platform task, written in Node.JS. It updates a version number in a .NET Core .CSPROJ file. There is a parameter so it can look for different XML node names

<Project Sdk="Microsoft.NET.Sdk.Web">

<PropertyGroup>

<TargetFramework>netcoreapp1.1</TargetFramework>

<Version>1.0.0.0</Version>

</PropertyGroup>

<ItemGroup>

<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />

<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />

<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.1" />

<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1" />

<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="1.1.0" />

</ItemGroup>

</Project>

Version a Wix project

As Wix is a Windows technology, my new Wix task is only supported on Windows (PowerShell) build agents.

Due to the flexibility (complexity?) of Wix it does have to make some assumptions. I have documented them in the VSTS extension’s project wiki.

The summary is you need to put all the version number variable definitions in an installerversion.wxi file that is included into your Wix project. The task looks for and updates this file(s)

<?xml version="1.0" encoding="utf-8"?>
<!-- Note that this file will be overridden by the build server. -->
<Include>
  <?define MajorVersion = "1" ?>
  <?define MinorVersion = "0" ?>
  <?define BuildNumber = "0" ?>
  <?define Revision = "0" ?>
  <?define FullVersion = "1.0.0.0" ?>
  <!--WiX Installer Versions are Major.Minor.Revision -->
</Include>

These variables can be used anywhere in the Wix project where needed e.g. to set the MSI version you could do the following

<?xml version="1.0" encoding="UTF-8"?>
<?include InstallerVersion.wxi ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="WixProject" Language="1033" Version="$(var.FullVersion)"  Manufacturer="Test"
           UpgradeCode="510ca227-7d91-43f4-881c-13319a07b299">

If you want a different number format just build it from the individual parts.

Hope you find them useful, as usual asked question on VSTS Manifest Version Extension Q&A or raise issues on Github

401.1 Permission error with on-premises TFS when accessing the API with a PAT

Background

If you are creating VSTS build extensions you will need to get the build or release’s PAT token if you wish to call the VSTS REST API.

This is done using a call like this (Node)

 

import tl = require('vsts-task-lib/task');

var auth = tl.getEndpointAuthorization('SYSTEMVSSCONNECTION', false);

if (auth.scheme === 'OAuth') {

var token = auth.parameters['AccessToken'];

 

or (PowerShell)

 

$vssEndPoint = Get-ServiceEndPoint -Name "SystemVssConnection" -Context $distributedTaskContext

$personalAccessToken = $vssEndpoint.Authorization.Parameters.AccessToken

 

You pop the resultant PAT into the headers of your REST web request and you are away and running.

The Problem

I hit a problem using this logic on VSTS Extension when they are run on TFS. On VSTS all was fine, but on TFS I got an unexpected 401.1 permission error on the first REST call i.e. I could not access the VSTS REST API

I tried setting fiddling with rights of my build user account, it was not that. Also I tried setting the ‘Allow scripts to access OAuth token’ property for the build/release agent

 

image

But this does not help either. This option just makes the PAT available as an environment variable, so you don’t need to use the code shown above.

And anyway – it was all worked on VSTS so it could not have been that!

Solution

The answer was I had basic authentication enabled on my Test TFS VM, as soon as this is disabled (the default) everything leapt into life.

image

Presenting at an event in Leeds - Making it easy to migrate your ALM process to the Cloud

Do you find your TFS server gets forgotten?

  • It is not owned by the IT department and the Development team don’t have the time to support it fully, it never gets patched or upgrades?
  • Or maybe you are adopting a cloud first strategy for all you systems?

Well maybe it is time to consider moving your on-premises TFS instance to VSTS?

On the 9th of May at the Crowne Plaza Hotel in Leeds I will be presenting at a Black Marble /Microsoft event where we will be looking at Microsoft’s new high fidelity VSTS database import tools that can be used to move a TFS instance to VSTS.

I will also be considering the pros and cons of the other migration options available to you. Hopefully making this a very useful session if you are considering a move to VSTS from TFS or any other source control ALM solution.

Hope to see you there, to register click here

 

image

Enumerating BizTalk 2016 Features for a Command-Line Installation

As with previous versions of BizTalk Server, you can perform the installation using the GUI or a command-line. To use the command-line installation, you’ll need the list of features that can be installed to add to the /AddLocal command-line. The available documentation for a silent installation of BizTalk Server at https://msdn.microsoft.com/en-us/library/jj248690.aspx relate to BizTalk Server 2013 and 2013 R2 (see https://msdn.microsoft.com/en-us/library/mt743078.aspx for ‘BizTalk Server 2016: What’s new, and installation’, then follow the link Appendix A: Silent installation near the bottom of the navigation menu at the left to get to the above page); there’s nothing that I’ve found so far that provides the setup.exe command line switches, or a list of features for use in a silent installation specifically for BizTalk Server 2016. Note that blindly following the previous guidance and using certain specific /AddLocal features results in an installation failure!

Getting hold of the command-line parameters for setup.exe is, of course, simple. Just run setup.exe with the ‘/?’ switch from a command prompt to get the following:

Command Description
/help or /? or /h Help and quick reference option.
/s <Configuration XML file> Silent Installation of features found in Configuration file.
/passive Passive Installation. Only progress bar will be displayed.
/norestart Supress restart.
/forcerestart Always restart after installation.
/promptrestart Prompts before restarting. This option cannot be used with the /quiet option.
/x or /uninstall Uninstalls the product.
/L <Logfile> Writes logging information into a logfile at the specified path. Always uses verbose MSI logging and appends to existing file.
/IGNOREDEPENDENCIES Bypass checks for downloadable prerequisites.
/INSTALLDIR <Install path> Specify the full path to product install location.
/COMPANYNAME <companyname> Sets the company name.
/USERNAME <User name> Sets the user name.
/ADDLOCAL ALL Install all features.
/REMOVE ALL Remove all features.
/REPAIR ALL Repair installation.
/CABPATH <cabfile> Specify a local path to a redistributable CAB file.
/CEIP Opt in to BizTalk Server Customer Experience Improvement Program.

These commands correspond to those listed on the silent installation page for BizTalk 2013 mentioned above with the exception that the final two commands listed on the web page appear to be missing from the above list generated by BizTalk Server 2016.

The /AddLocal command-line parameter details the features that will be installed. On the silent installation web page, there is a link to follow to the list of features (at http://go.microsoft.com/fwlink/p/?LinkID=189319), however if you browse to that page, you’ll notice that it is marked as the features for BizTalk Server 2010. There are issues using some of the parameters for the installation of BizTalk Server 2016, so it seemed worthwhile attempting to enumerate the parameters that are available to a BizTalk Server 2016 installation.

The installation MSI for BizTalk Server 2016 can be opened using Orca (Orca.exe is a database table editor for creating and editing Windows Installer packages and merge modules – see https://msdn.microsoft.com/en-us/library/windows/desktop/aa370557(v=vs.85).aspx for acquisition and installation instructions) to get the list of features. The screen shot below shows a partial view of the ‘Feature’ table from the ‘Microsoft BizTalk Server64.msi’ file:

Orca Features Table for BizTalk Server 2016 MSI

The information in the ‘Feature’ table, along with information gleaned by running the installer, ticking specific single components and then examining the setup log file can be reorganised to give the following:

Feature AddLocal Command
Portal Components BizTalk, WMI, InfoWorkerApps
      Business Activity Monitoring BAMPortal
Developer Tools and SDK BizTalk, WMI, AdapterImportWizard, BizTalkExplorer, BizTalkExtensions, DeploymentWizard, Designer, Development, Migration, MsEDIMigration, MsEDISchemaExtension, MsEDISDK, OrchestrationDesigner, PipelineDesigner, SDK, TrackingProfileEditor, VSTools, WCFDevTools, XMLTools
Documentation Documentation
Server Runtime BizTalk, WMI, Engine, MOT, MSMQ, Runtime
      BizTalk EDI/AS2 Runtime MsEDIAS2, MsEDIAS2StatusReporting
      Windows Communication Foundation Adapter WCFAdapter
Administration Tools and Monitoring BizTalk, WMI, AdminAndMonitoring, AdminTools, BAMTools, BizTalkAdminSnapIn, HealthActivityClient, MonitoringAndTracking, PAM
      Windows Communication Foundation Administration Tools WcfAdapterAdminTools
Additional Software BizTalk, WMI, AdditionalApps
      Enterprise Single Sign-On Administration Module SSOAdmin
      Enterprise Single Sign-On Master Secret Server SSOServer
      Business Rules Components RulesEngine
      MQSeries Agent MQSeriesAgent
      BAM Alert Provider OLAPNS
      BAM CLient FBAMCLIENT
      BAM-Eventing BAMEVENTAPI
      Project Build Component ProjectBuildComponent

Notes:

  • The ‘BizTalk’ and ‘WMI’ feature are specified in numerous places in the table above. You only need to specify each of these items once.
  • The parameters are case sensitive. Specifying a parameter incorrectly, e.g. OlapNs rather than OLAPNS will result in a silent installation failure.
  • When adding the parameters to the command line, it is important that there is no space between the items. Including a space (e.g. ‘BizTalk, WMI, AdditionalApps’ rather than ‘BizTalk,WMI,AdditionalApps’) will result in a silent installation failure.
  • One of the features, ‘SDKScenarios’, is never mentioned in the setup log file. It is assumed that this feature is automatically installed if required by the parent feature (SDK), however including it within the AddLocal command line parameter list doesn’t seem to cause any issues.