Saturday, January 20, 2018

General workflow for publishing an Android app to the Google Play store when developing with VSTS

  1. Create a Git repository (not TFVC) in VSTS, possibly with a new Team Project, up to you.
  2. Create your app in Android Studio and add it to the Git repository.
  3. Create your Key Store (or import an existing one) with Android Studio.
    • In order to be able to sign your APK and deploy it (with any tool, but in this case VSTS), you'll need the following 3 pieces of information:
      • The Key Store password
      • The Key alias
      • The Key password
  4. Ensure that you've imported the "Manifest Versioning Build Tasks" extension to your VSTS account from the VSTS Marketplace.
  5. Configure and execute an automated build for your application using the default steps provided by VSTS when creating a new build by applying the Android build template.
    1. Add to the default build templae a "Manifest Versioning Build Tasks" step to automatically generate your application version from the build.
  6. In your Google account, do the following:
    1. Ensure that you've gone to the Google Play Console page and created a Developer Page.
      • Once you've created the Service Account below, you'll need to come back here to the Play Console and grant access with "RELEASE MANAGEMENT" permissions, ensuring that you also have the "Release manager" role selected.
    2. Ensure that you've gone to the Google API Console and created a Service Account for publishing your app to the Google Play store.
      • NOTE: You'll need to export your key in JSON format so that the email and key fields within the JSON object can be used to configure your Google Play endpoint in VSTS
  7. Ensure that you've imported the Microsoft "Google Play" extension into your VSTS account from the Marketplace.
  8. Configure your automated Release in VSTS. Execute the following steps:
    1. Add an "Android Signing" step to your release to sign one of the *unsigned* APKs from your build.
    2. Add a "Google Play - Release" step to your release. You'll need the keystore information mentioned above, as well as the keystore *.jks file to upload to VSTS in the "Google Play - Release" step.
  9. Now that your release is configured, you'll have to to a manual build on your developer (just once) to product a signed APK with the keystore, and then manually upload the signed APK file to the Google Play Console to an Alpha release in order to associate your applicationId (in the ApplicationManifest.xml app manifest file) to your product in the Play Store.

Friday, January 12, 2018

Bootstrapping a VSTS Linux build agent for Docker containers

1. Create an Ubuntu 17.04 VM in Azure
2. Install dotnetcore using the instructions here.
3. Install the Docker apt-get package using the instructions here.
4. Download and run the VSTS agent Docker image and run it as a Docker container itself using the instructions here, e.g. sudo docker run -e VSTS_ACCOUNT=myvstsaccountname -e VSTS_TOKEN=abcdtokenherefromportal -e VSTS_POOL="Docker Build Agents" -e VSTS_AGENT="myagentname" -it -v /var/run/docker.sock:/var/run/docker.sock microsoft/vsts-agent

Tuesday, January 09, 2018

Using Git with a corporate firewall that uses certificate interception

Like many open source tools (originally or completely) based on Linux, git has issues with self-signed certificates, especially if you work in a corporate environment where your company may have network message inspection hardware for security. To get git to work in such an environment, you'll need the public root Certificate Authority certificate for your company, exported to a base 64 .cer file. Once you have that, run the following command to install it into git's private certificate store:

git config --global http.sslCAInfo "<path/to/your/certfile.cer or .pem>"

Wednesday, January 03, 2018

Using NodeJS with a corporate firewall that uses certificate interception

See this post on Stack Overflow. The gist of it:

1. Export your company's corporate Root CA certificate to a Base64 encoded .cer file
2. Run this command to instruct npm to use the certificate file in its communications:

npm config set cafile = "<path to your certificate file>"

Tuesday, December 12, 2017

Installing Windows 10 IoT Core on a Raspberry Pi 3

You’ll need the following ingredients:

1. A desktop or laptop computer with Windows 10 installed
2. A Raspberry Pi 3.
3. A Micro-SD card for use as the primary storage on the RasPi3
4. A Micro-USB cable for connecting the RasPi3 to a power sources
5. A mouse and keyboard
6. A monitor with HDMI support, or an HDMI to [whatever] adapter for your monitor
7. A wired network connection for the RasPi3.

To get up and running with Windows 10 IoT Core on a Raspberry Pi 3, you’ll need to follow these high-level steps:

1. Ensure you’ve got Windows 10 on your developer machine. If you don’t, go get a machine with Windows 10 and don’t come back here until you do.
2. Download the Windows 10 Iot Core Dashboard . You’ll need it to configure your Micro SD card for the RasPi 3.
3. Insert the Micro-SD card into your computer and use the IoT Core Dashboard to configure the MicroSD card with Windows 10 IoT Core.
4. Once successful, insert the MicroSD card into the unpowered RasPi3 and plug it in to power it up. 5. You should also have your monitor, mouse and keyboard hooked up by this point.
6. Configure the RasPi3 to connect to your network, and ensure that your Desktop computer with the dashboard and the RasPi3 are on the same network so that the Dashboard can detect your RasPi3.
7. Use the Windows 10 IoT Core Dashboard on your desktop PC to connect the RasPi3 to an IoT Hub in Azure.

Sunday, November 12, 2017

The quick and dirty for using System.Windows.Interactivity and the MVVM pattern for custom dialogs in your WPF application

So I recently decided to finally try my hand at using proper MVVM patterns with my custom dialogs in the application on which I'm currently working (started back in 2010 before a lot of MVVM frameworks existed). I followed Microsoft's Interactivity Getting-started guide here. The quick summary of steps to take (as a reminder) are below. That said, read the article tip-to-tail so that you understand these steps, and then use this page as a reminder.

  1. For your dialog (e.g. MyDialog), you'll need to create the following items:
    • MyDialogViewModel, which implements Prism.Interactivity.InteractionRequest.IInteractionRequestAware
    • MyDialogConfirmation, which extends from Prism.Interactivity.InteractionRequest.Confirmation
  2. In your dialog, ensure that it extends from System.Windows.Control.UserControl, NOT System.Windows.Window (because your interactivity request handler in XAML needs a control for its Content, not a Window)
  3. In the constructor of your Dialog user control, set your data context to a new instance of your MyDialogViewModel (to ensure that it's present in the DataContext when the Interactivity framework invokes your dialog's window and can inject it with your MyDialogConfirmation instance when you raise the notification for your InteractivityRequest to which you're binding
  4. Ensure you've created your interactivity handler in the XAML of the view that's calling your dialog, e.g.:
  <prism:InteractionRequestTrigger SourceObject="{Binding Path=MyDialogInteractivityRequestProperty, Mode=OneWay}">
   <prism:PopupWindowAction IsModal="True" CenterOverAssociatedObject="True">
     <Dialogs:MyDialog />

Wednesday, October 18, 2017

A quirk when using Ninject with Self-Hosted WCF services

I recently discovered a problem when using WCF in a self-hosted setup that I had never encountered before:

I was using the following binding syntax in my module:

this.Bind<IMyService, MyServiceImpl>();

As it turned out, this was causing a strange "Object reference not set to instance of an object". Changing the syntax to :


... solved the problem.

Using Ninject in a Self-Hosted environment, e.g. a Windows Service

Windows Services are a great way to host WCF, typically in scenarios where on-premise services are a requirement. As Dependency Injection becomes a standard practice in large scale systems, it can be hard to choose the right DI container. One of my personal favourites in Ninject because of its (typical) ease of configuration. Some benchmarks will show that Ninject isn't the fastest container out there in terms of constructing objects, but in practical use I've never once found that to be a problem.

The following example shows a function that can be used in a Windows Service for setting up Ninject to create ServiceHost instances in a self-hosting scenario:

private static NinjectServiceHost CreateServiceHost(IKernel standardKernel, Type serviceType)
 if (standardKernel == null)
  throw new ArgumentNullException("standardKernel");
 if (serviceType == null)
  throw new ArgumentNullException("serviceType");
 NinjectServiceHost ninjectServiceHost = new NinjectServiceHost(
  serviceBehavior: new NinjectServiceBehavior(
   instanceProviderFactory: type => new NinjectInstanceProvider(type, standardKernel),
   requestScopeCleanUp: new WcfRequestScopeCleanup(true)
  serviceType: serviceType
 return ninjectServiceHost;

This function will be good enough to boot strap your services in your Windows ServiceBase
implementation in the vast majority of cases. You need only pass in your pre-configured 
IKernel instance and the Type of the WCF Service implementation.