the nullfactory

Configuring Raspberry PI Zero + LCD Display + Tmux

17 Mar 2019 | Raspberry-Pi | Linux | Tmux

I needed a display for a new project that I am working on and saw that the 3.5 RPI Display Board was on sale and decided to pick one up. I've previously used mini OLED displays before, but they're pretty limited by its size and the colors that it can display. This is a 480x320 resolution device that is designed to affix right onto the Raspberry Pi (RPi) GPIO pins. The installation is simple as you'd imagine:

Connection

For the project I had in mind, I do not need a fancy GUI nor the use of the touch controller. The display will be used to show console statistics and accessing the device using SSH.

generator-nullfactory-xrm 1.7.0 Released!

I just released version 1.7.0 of generator-nullfactory-xrm. This release includes a lot of defect fixes, dependency version upgrades and refactored code.

Feature #37: Added ability to upgrade tooling PowerShell scripts via the generator.
- Run yo nullfactory-xrml:tooling
Feature #12: The generated *.csproj files now have unique identifiers. This should avoid any potential conflict between projects.
Feature #35: .gitignore file updated to be compatible with nested "standard project structure". (see https://gist.github.com/davidfowl/ed7564297c61fe9ab814).
Fixed #34: Pull-CrmSolution.ps1 now downloads the zip file to a temporary file location before extraction.
Fixed #36: solution sub-generator now creates mapping file as expected.
Updated plugin and workflow project dependencies:
- Microsoft.CrmSdk.CoreAssemblies - 9.0.0.7 ==> 9.0.2.3
- Microsoft.CrmSdk.Worklow - 9.0.0.7 ==> 9.0.2.3
Refactored the internal structure of the generator.
Refreshed package dependencies.
Fixed broken unit tests.

YAML Build Support for generator-nullfactory-xrm

If you've read my previous posts on the topic, you might have already guessed that I am a big fan of maintaining builds as code artefacts. I was super excited when the Visual Studio Team Services (VSTS) team announced YAML support and I knew right then that this had to be part of generator-nullfactory-xrm.

With version 1.6.0, I've added the ability to generate tailored YAML build definitions into your Dynamics 365 projects. What this means is that you get rich CI build support right out of the gate! No more excuses for not having a CI build in your project!

CI Builds for Everyone

The option to generate a CI build is defined as a sub-generator. This is intentional as I didn't want to automatically assume that everyone would be using VSTS as their source control.

Here's the quick rundown of the steps necessary to get things up and running. What we're aiming for is a layered approach:

First generate the default project structure.
Next, generate the YML file using a sub-generator.
Push changes to remote VSTS git repository.
Verify that VSTS provisioned the YML file as the CI build.
...
Profit!

generator-nullfactory-xrm 1.6.0 Released!

I just released version 1.6.0 of generator-nullfactory-xrm. This release includes the following changes:

generator-nullfactory-xrm

V9 Support!
Simplified post installation steps with the introduction of _RunFirst.ps1 script.
Generate VSTS compatible YML build file:
- Added nullfactory-xrm:cibuild sub-command.
Generate individual CRM project file post initial scaffolding:
- Added nullfactory-xrm:solution sub-command.
Default generator creates a tailored README.md file with a summary of changes.
Fixed issue with generated workflow template code.
CRM SDK assemblies updated:
- Microsoft.CrmSdk.CoreTools 8.2.0.4 => 9.0.0.7
- Microsoft.CrmSdk.CoreAssemblies 8.1.0.2 => 9.0.0.7
- Microsoft.CrmSdk.Workflow 8.1.0.2 => 9.0.0.7
Added (Beta) version of the Online Management API scripts.

YAML Builds and Branching in Visual Studio Team Services

18 Feb 2018 | Visual Studio Team Services | ALM | Git

In my previous post I explored the the concept of treating build as a first class code citizen and how to automatically setup up an YAML based continuous integration (CI) build in Visual Studio Team Services (VSTS).

At the end of that exercise I was curious as to how VSTS handles build definitions when you throw branching into the mix. I could not find much information on the topic, so I thought I might try it out myself.

Branches and CI Builds

Prepare the project structure place the you build definition .vsts-ci.yml in the root of the repository. Read my previous post for setting up an exported CI build.
Add an echo step so we can uniquely identify this build branch.

Read more...

Build Pipeline as Code - YAML based CI Build for Dynamics 365 Solutions

20 Jan 2018 | Visual Studio Team Services | Git | ALM | Dynamics CRM Online | generator-nullfactory-xrm

I first learned about YAML builds a while back when I was trying into integrate a project with AppVeyor. The concept of treating your build pipeline as first class code artefact was very appealing as it opens up so much possibilities. For me personally the highlights are:

History, versioning and branching of your build definitions
Improve quality of build definitions and consistency across projects.
Quickly reuse and repurpose builds onto different projects.
Make maximum use of the underlying build platform.

These posts here and here dive deeper into the advantages and the different use cases.

A couple of months ago the Visual Studio Team Service (VSTS) team announced support for the the same functionality in VSTS. Although the feature is still in preview, the VSTS team has continued to improve the feature and now provides the ability to export existing build definitions or individual tasks. In this post, I intend to take pre-existing build definition, converting it to a YAML build definition and make the necessary changes to get it to work as a CI build.

In this post, I intend to port an existing definition to a YAML build definition and use it as a template to setup a new CI build for a second project. The source definition that I will be using is a basic version I use for Dynamics 365 projects.

CRM Saturday Melbourne 2017 - Presentation Slide Deck

09 Oct 2017 | Dynamics CRM | generator-nullfactory-xrm | Miscellaneous

I know its a "little" late, but here's the slide deck from my CRM Saturday 2017 presentation - Zero to DevOps - Source Control and Release Strategy for Dynamics 365 Solutions.

Don't Forget to Install the Just-In-Time Debugger

08 Oct 2017 | Visual Studio | Miscellaneous

Today I learned that you can have an installation of Visual Studio 2017 without the JIT debugger - Yup, you really can. This meant that I could not use the technique of attaching a debugger at runtime using the System.Diagnostics.Debugger.Launch(); code snippet.

When the application executes the launch code, nothing happens - no error nor exception. The method even returns true indicating a a successful launch.

Tail using PowerShell

07 Oct 2017 | PowerShell

Consider a scenario where you are diagnosing an issue on a production server. You've enabled the logs and got everything setup to reproduce the issue. Queue the trigger to invoke the misbehaving operation and finally wait for the log file to update.

Staring at the log file size to change is no fun nor is refreshing the file periodically. I want to be notified the moment the log gets updated in real-time. This is exactly what a program like tail does - it monitors the file for changes and outputs the tail end of the file.

There are a few incarnations of tail out there that do the job perfectly fine, but given that this was a production environment I was not keep about installing new tools.

Luckily, the Get-Content PowerShell cmdlet has this functionality built-in. This is the combo that I finally settled on:

Mocking and Testing a WebService using SoapUI

06 Oct 2017 | REST | SOAP | WCF

I have recently been working on an implementation of a WCF client interacts with a remote SOAP web service. Unfortunately this service did not have a development version that I could interactively test my requests against.

Armed with just the WSDL and the schema for expected responses, I needed to find a way to mock the remote service in order to confirm the functionality of the client. This is where SOAP UI comes in - SOAP UI is tool that allows me to point it to service contract (WSDL or REST) and mock the responses that each of the actions would generate. And finally provides the functionality to host and serve these mocked responses so that they can be consumed by different clients.

I will be using the freely available http://www.webservicex.net/globalweather.asmx web service to demonstrate the process.