Skip to content
A package containing the Particular Service Platform for use in samples and tutorials
C# JavaScript
Branch: master
Clone or download
danielmarbach Merge pull request #15 from Particular/update-for-edit
Bump versions to include edit & Retry
Latest commit 079089e Aug 19, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
src Bump versions Aug 19, 2019
.gitattributes gitattributes, gitignore, gitversion, license Nov 26, 2018
.gitignore Launch audit as well Jul 30, 2019
GitVersion.yml Converting to release flow Jun 13, 2019 gitattributes, gitignore, gitversion, license Nov 26, 2018 PlatformSample deployment (#13) Jun 17, 2019
output.png README Dec 5, 2018


A package containing the Particular Service Platform for use in samples and tutorials. The package can be used within a sample or tutorial to demonstrate platform capabilities without requiring the user to install the platform or any other dependencies.

Includes binary versions of ServiceControl, ServiceControl.Monitoring, and a self-hosted version of the web assets for ServicePulse. All tools are configured to use the Learning Transport for the project in which the package is included.


Add the following to a console application project:

static void Main(string[] args)

The package will:

  1. Copy platform binaries into the project output directory.
  2. Find available ports for all the platform tools.
  3. Find .learningtransport directory and folders for logging.
  4. Launch ServiceControl with modified config file.
  5. Launch ServiceControl.Monitoring with modified config file.
  6. Serve the ServiceControl web assets using the Kestrel HTTP server.
  7. Wait for the ServiceControl API to be responsive.
  8. Open a browser window pointing to the ServicePulse UI.

This can be seen directly in this repository by launching the SmokeTest.exe:

SmokeTest Output


The PlatformLauncher.Launch() API has very limited options available as optional parameters, which can be mixed as needed.

Showing console output

By default the console outputs of ServiceControl and ServiceControl.Monitoring are suppressed. To view them for purposes of debugging or curiosity, use the showPlatformToolConsoleOutput parameter:

Particular.PlatformLauncher.Launch(showPlatformToolConsoleOutput: true);

ServicePulse default route

Some samples benefit from opening ServicePulse to a specific view, rather than the Dashboard.

For example, to open ServicePulse to the Monitoring view:

Particular.PlatformLauncher.Launch(servicePulseDefaultRoute: "/monitoring");


ServiceControl, ServiceControl.Monitoring, and ServicePulse are all NuGet package dependencies of this project. Each of these publishes a PlatformSample specific NuGet with each release:

Particular.PlatformSample.ServiceControl Particular.PlatformSample.ServiceControl.Monitoring Particular.PlatformSample.ServicePulse

To update each just update the Version attribute in the appropriate PackageReference located in the Particular.PlatformSample.csproj file.

Configuration Files

The config files in src/Particular.PlatformSample/configs are embedded resources that use simple string replacement to replace values such as {ServiceControlPort} with the correct values.

In the event that one of the platform applications makes a structural change to the configuration files, the embedded parameterized version will need to be manually updated as well. Each of the application tools now includes an Approval test that will alert updaters in the event they have changed one of these files to prompt them to update this project.

To update the files compare the embedded resource file with to the newly updated sources ensuring the structure is the same. For ServiceControl.exe.config and ServiceControl.Monitoring.exe.config ensure the TransportType remains configured for the Learning Transport.

When finished, commit the changes to a branch and raise a pull request against master.


As we don't care about patching older releases, the Platform Sample uses a simplified version of Release Flow that, in most cases, does not require release-X.Y branches.

  • Builds on the master branch will, by default, create an alpha version of the next minor.
  • To create a production release, label the master branch with the full version number, and trigger a build.
  • All normal releases (most often updating the platform tools versions) should increment the minor.
    • A major version need only be released in the event of a breaking change in the API.
    • Patch releases generally should be avoided. If one is necessary, the release branch would need to be created from the point of the labeled minor, and the patch released from there.
  • Once a release is built on master, promote to Deploy, which sends it to Octopus and MyGet.
  • Deploy to NuGet by promoting in Octopus.
You can’t perform that action at this time.