VSoft Technologies Blogs


VSoft Technologies Blogs - posts about our products and software development.

This version adds several back-end performance enhancements including significant improvements to database query caching. We have also updated various third party packages and upgraded the bundled PostgreSQl database from version 9.3.4 to version 9.5.3. What’s more, this release builds upon all the improvements and fixes made to version 1.8.

New Actions

To keep up with the latest developments in Visual Studio, we have added several new actions for working with .Net Core projects. The DotNet Build, DotNet Pack, DotNet Publish, DotNet Restore, DotNet Run and DotNet Test actions all run the DotNet Cli command line.

DotNet Build Action

This release also includes a new action for importing XUnit tests from an XML report file. The sort of file you may choose to output from the DotNet Test action.

To polish this off we have added new NPM Pack and NPM Publish actions for sharing your completed packages.

New Build Event Handlers

A powerful new addition to the Continua CI build event handlers is the HTTP Request handler which allows you to send JSON or XML to HTTP endpoints via GET, POST. PUT, DELETE, PATCH methods and extract values from the results to set as Continua CI variables.

HTTP Request Build Event Handler

This enables interaction with a various existing web services and REST APIs. You could, for example, use this feature to send a message via Slack when a build starts, tag a commit on GitLab when a build finishes or even translate a variable value to Azerbaijani using Google Translate API. If you have any in-house web services which handle HTTP requests, it is likely that these can be accessed too.

We have also added a new GitHub Release build event handler for creating, updating and deleting GitHub releases. This also allows you to upload artifacts as GitHub release assets.

Other New Features

Build Event Handler conditions. You can now control the triggering of handlers based on the value of build variables or expression objects. These values may be specified when queuing a manual build or set in the stage workflow. You could, for example, only send a GitHub Release if the number of failed unit tests $Build.Metrics.UnitTests.Failed$ is zero.

Build Event Handler conditions

Continue on failure. Builds can now be set to progress to the next stage after one stage has failed. Stage gates now include an $Stage.IsSuccessful$ condition by default. This can be removed to allow the build to continue to the next stage when a stage fails. So you can see what failed, the stages are now coloured green or red in Tile and Details dashboard views to indicate an success or failure status.

Continue on failure

New cleanup options. We have also made some changes to the server cleanup policy, giving you the options to clean up build statistics. The database category has also been split up so that build unit tests can be cleaned up without cleaning up the full build. This is important to prevent database tables growing too large when you have a large number of unit tests.

Cleanup options

Continua CI and FinalBuilder (both released today) provide somewhat better integration between the two products.  

Continua CI 1.8

The FinalBuilder Action in Continua CI now produces an xml file that is consumed by FinalBuilder when run under Continua CI. This xml file contains all the useful information about a build, such as version numbers, changesets, variables etc. 

There is also a new option on the action that will automatically apply Continua CI variable values to matching FinalBuilder variables. What this means is, if you have a variable declared in both FinalBuilder and Continua CI with the same name, FinalBuilder's variable will automatically get the value of the Continua CI variable at runtime. This option is only available for FinalBuilder 8, if you select FinalBuilder 7 the option will not be visible. If the version of FinalBuilder 8 you are running does not support this integration, a warning will appear in the Continua CI build log. 

FinalBuilder 8

FinalBuilder 8 has two new actions.

The "Is Running Under Continua" action is an If Then style action, i.e. the children of this action will only run if FinalBuilder is running under Continua CI.  

The other action is the Continua CI - Get Version Info action - this action will take the version info from Continua CI and apply it to a version info property set in your FinalBuilder project.;


The action is smart enough to use the correct version info scheme depending on whether the propertyset is a win32 or dotnet propertyset. This greatly simplifies getting the version info from Continua into FinalBuilder, no need to declare 4 variables on both sides and set them in the FinalBuilder Action in Continua CI.


That xml file I mentioned above is loaded into a Continua object model that is available in action script events. If you do make use of it, you should be sure to check the Continua.IsRunningUnderContinua property before using the rest of the object model (the script editor provides intellisense for the model.

We have been working on moving Continua CI to .net 4.6.1 for a future release, and during this conversion (so far, mostly just updating nuget packages),  we discovered an issue that turned out to be caused by a change to .net certificate validation.

If you use self signed X509 certificates and target the .net framework 4.6.1 then you are in some fun, especially if you used makecert to generate the certificate. There is a change in behaviour in the way certificates are validated, which will leave you pulling you hair out for hours. The error you may encounter will look something like this : 

"The Identity check failed for the outgoing message. The remote endpoint did not provide a domain name system (DNS) claim and therefore did not satisfied DNS identity 'localhost'. This may be caused by lack of DNS or CN name in the remote endpoint X.509 certificate's distinguished name."

If you google the error message, you will find plenty of references to using  a DnsEndpointIdentity, only in our case, we were already doing exactly as the answers on stackoverflow were suggesting! Since we were migrating from .net 4.0 to .net 4.6.1, I started looking for info on the changes in each version of the .net framework. Eventually, I came across this page :


This was the only mention of X509 certificates I could find in the change history, but it seems like it could be related, so I tried what it suggested, and low and behold, problem solved! With some further investigation of this work around, I found some issueson the wcf github repo with several references to the behaviour of certificate validation.



So it turns out, in .NET 4.6.1 they broke the certificate validation, by only looking at the Subject Alternate Name (SAN) extension, and not falling back to the Subject Name CN field as it should. The pull request I linked to above, is for the WCF for .NET core, not 4.6.1 - so I have no way of knowing if this will be fixed for 4.6.x.  

Whilst an app.config change can work around the issue, the real fix is to generate certificates that include SAN extension.

Generating a certificate without MakeCert

Makecert.exe, which is commonly used (on windows at least) does not support the SAN extension, Makecert is deprecated, so it's unlikely there will be an update to make it able to generate certificates with the SAN certificate extension.  Windows 8/Server 2012R2 & later versions of Windows include a new powershell cmdlet to generate certificates. For Windows 7 the best option is this :


This appears to what the Windows 8 & later cmdlet is based on, it's relatively simple to use and generates certificates that validate properly with WCF on .NET 4.6.1

New-SelfSignedCertificateEx -Subject "CN=MyServer" -KeySpec Exchange 
-KeyUsage "DataEncipherment, KeyEncipherment, DigitalSignature" 
-Path c:\certs\example.pfx -Exportable -SAN "MyServer" -SignatureAlgorithm sha256 
-AllowSMIME -Password (ConvertTo-SecureString "abc123dontuseme" -AsPlainText -Force) 
-NotAfter (get-date).AddYears(20)

Note the above command is on multiple lines to make it easier to read, it can be on one line.

Continua CI 1.8 Released

We are pleased to announce that Continua CI 1.8 has been released. It was actually released a couple of days ago, but for anyone who missed it, here is a heads up with and overview of the new features. We'd also like to thank all those who downloaded the beta - the time and effort spent reporting issues helped us to fix some important bugs and is most appreciated.

Version 1.8 adds the following features which build upon all the improvements and fixes made to version 1.7.1.

Dashboard Filtering

We've added a new filter box to the dashboard so you can quickly find the configuration (or project) that you are looking for as you type. Use the shortcut key F on the dashboard pages to focus on the filter box and start typing.

Dashboard filtering

Shared Resources

Many of you have requested more control over the number of builds which can run concurrently for some configurations. This may be to restrict the number of times a particular tool is run due to a license, memory or processor limit, or to prevent concurrency issues with multiple build stages simultaneously writing to the same file, folder or network resource.
You can now allocate quotas to named Shared Resources and specify that builds and stages must acquire a lock on the Shared Resource before running. If all locks are allocated, then the build or stage will wait on the queue until a lock is released.

Shared resources can be associated with the server or a particular agent in the Administration pages.

Agent shared resources

Agent shared resources are acquired when selecting an agent to run a stage. Continua will select the agent with the largest available quota of each shared resource.

Stage shared resource locks

Server shared resources can also be acquired when selecting an agent, or while on the build queue after evaluating configuration conditions.

Shared resource lock configuration condition

We hope you find that shared resources can provide many different ways to control the build process.

Requeue Build

Sometimes a build may fail due to an offline network resource, or some logical error in the stage workflow. Up until now, your only option was to re-run a build for the same branch heads. If any new changesets had been committed to the branch since that build, then you are out of luck.

The new Requeue Build button on the Build View page allows you to requeue an existing build using the same changesets, variables and queue options. Any changes to the configuration such as stage actions or repositories are taken into account and used for the new build.

Requeue build button

You can also change the priority, comment and variables before requeuing the build.

Requeue build options menu item

Clicking on the “Build requeue options” menu item will open the Queue Options dialog.

Requeue options dialog

Persist Build Variables

Another common request has been to persist variable values from one build to another build. This may be to keep a count of builds on a particular branch or to flag that some actions have been completed in one build and do not need to be repeated.

Continua CI takes a copy of configuration and project variables at the start of each build. These copies are referred to as build variables. Any changes to build variables are normally discarded when the build finishes and cannot be used by other builds.

First tab of Persist Build Variable build event handler dialog

The new Persist Build Variable build event handler allows you to save the value of the build variables when specific events happen in the build timeline. This is stored as the value of the configuration variable. Subsequent builds will then pick up this revised value and use it as the initial value of the build variable.

Second tab of Persist Build Variable build event handler dialog

As Continua CI allows multiple builds to run concurrently, it is important to control when the variables are overwritten. A later build may run faster and finish before a build which started earlier, causing unexpected results.  You can optionally state that a variable should not be persisted if the configuration variable has been modified (e.g. by another build) since a specified build event, such the build start.

Options tab of Persist Build Variable build event handler dialog

You can also prevent concurrency issues by using this feature in conjunction with shared resource locks.

Other New Features

  • You can now set the Variables display order of variable prompts on the Queue Options dialog.
  • We have provided buttons for cloning Triggers, Repositories and Build Event Handlers.
  • Configuration Conditions can now be disabled.
  • All actions which run external processes now have a Timeout (in seconds) setting.
  • We have also added a new Cake build runner action and a new VSTest unit testing action.

Automise 5 Released!

Today we are delighted to release the Automise 5, which now includes a gift. Automise Run-time is now free.

As explained in the Beta announcement, our continuous delivery cycle has worked well for Automise 4. Producing constant stream of updates and fixes. Now, with significant updates to the internal workings for Automise today we are releasing Automise 5.

What's new in Automise 5

Stepping Engine

We have undertaken a major rewrite of the internal stepping engine for Automise 5. This has reduced the moving parts, while also enabling extra features to be implemented. In the end this will mean your projects will run faster, consume less resources, and also providing some extra tools for debugging projects.

Action List Dependencies

Action Lists can now list other action lists that they depend on. For example this allows specifying a UploadAndClean Action List that depends on the Clean and Upload Action Lists. When UploadAndClean is run, if the Clean and Upload Action Lists have not been run they will be.

Action List Dependencies

Step into included projects

Previously, debugging include project actions meant running the entire included project when stepping over the action. In Automise 5, debugging allows for stepping into the included project. This will open the included project, if is not already open, and start to debug that project.

Breakpoint Conditions

We have also added to the debugging experience with breakpoint conditions. These work like break point conditions in Visual Studio. They present options for stopping the executing of a script when variables have certain values, or a condition specified becomes true. Conditions can also be the number of passes over the breakpoint.

Action List Dependencies

IDE Themes (Light and Dark)

After five years we thought it was time Automise got a new coat of paint. We have implemented two new themes, a light and dark theme (defaulting to the dark on first run up). Choose your side wisely…

Action List Dependencies Action List Dependencies

Action List Out Parameters

Action Lists parameters can now be defined as an out parameter. These parameters can have their value set inside the action list. On exiting the action list the calling Run Action List action will set the variable assigned as the out variable with that value. This effectively adds the ability to have action lists work as functions and return values calculated in the action list.

Project Formats

Let’s face it, xml files are difficult to diff. To make diffs easier Automise 5 has introduce two major updates to the Automise project file structure.

   1. A new DSL project file format (the new default format) (atp5)

   2. A new XML project file format (atx5)

New Actions

We have done some major work to bring new Azure and Amazon S3 actions to you. Some of these being:

  • Amazon S3 - Added bucket delete object, bucket list objects, bucket list, upload directory, and download folder actions.
  • Azure Actions - Added Login, Logout, Config Mode actions.
  • Azure Group Actions - Added Group Create, Group Delete, Group List, Group Log Show, Group Set, Group Show actions.
  • Azure VM - Added VM Capture, VM Create, VM Deallocate, VM Delete, VM List, VM List, VM Quick Create, VM Restart, VM Start, VM Stop actions.
  • Azure Storage - Added Storage File Copy Show, Storage File Copy Start, Storage File Copy Stop, Storage File Delete, Storage File Download, Storage File List, Storage File Upload actions.

New License Manager

Automise 5 introduces a new license manager that allows you to download licenses directly from the store. It will be presented to you on first load, or when no valid license has been found. You can also get to it from the Help menu.

All that you will require to download a license from the store is your store credentials. It will then log in for you, and download a list of licenses that will work for the current version of Automise. If you had a current Automise 4 subscription as of 28 March 2016, you will already have an Automise 5 license waiting for you in your store account.

In addition there is a simpler way to get Trial license, all that you require is a valid email address to receive a verification code on.