You are browsing the archive for marc.

Profile photo of marc

by marc

An update on Data Abstract and RemObjects SDK

September 24, 2015 in Data Abstract

Similar to my post about Elements last week, I also wanted to give you a brief update on where we are with Data Abstract and RemObjects SDK version 9.

First though, you’d might like to know that on popular request we shipped a small interim update to 8.3 on Monday, with official support for the new “Delphi 10 Seattle” (who names these things?). The update covers the Delphi versions of RemObjects SDK and Data Abstract, as well as Hydra, and is a very minor update that only focuses on the new Delphi version.

The beta for version 9.0 is progressing very nicely. We shipped our first major beta drop on Monday, build .1185, and it contains several significant new features.

To start with, you probably already heard or read about the new Code-First server support we introduced for .NET in the first beta, a few weeks back (if not, you should read up on it here). Essentially, Code-First allows you to design and update your services purely in code, without the need for a RODL file own your server, and without using Service Builder. With this week’s beta, I’m thrilled to announce that Code-First server support has also come to Delphi. My colleague Eugene has provided a detailed overview here, and it’s really cool.

This means that regardless of your choice of server platform, you now get the full benefit of Code-First.

We’ve also started making a lot of improvements to help you avoid a bunch of boilerplate code in your projects. It used to be, when you started a new RO/.NET server project, you would get a bunch of source files created that were largely uninteresting – a Windows service class, a service installer, a main form, an “Engine” class, and so on. No more! As of the last beta already, a full RO server can be up and running with literally a single line of code: new AppServer().Run().

Combine this with Code-First services, and creating a fresh server app has never been easier! Of course you can still configure the AppServer instance in more detail, if needed – via properties, or via the existing configuration file mechanism of the NetworkServer class.

New in this week’s beta, we have added brand new project templates for all five supported .NET languages (Visual C#, Visual Basic, Oxygene, RemObjects C# and Swift), both for Code-First and for traditional RODL-based servers, that take advantage of this new start code.

If you’re using Fire, then the current beta also includes the new Code-First project templates for you. With that, it’s now incredibly easy for Mac and iOS developers to create remote services in Swift, without even needing a Windows VM to run Service Builder in.

As with Code-First services, the new “boilerplate code” changes debut in the current beta for .NET, but they’ll expand over to Delphi in future betas, before RO9 will ship.

Moving over to the client side, we’ve also made lots of improvements to RO and DA for Cocoa. For one, we now ship frameworks (for Mac and iOS) that are ready to be more easily consumed by Apple’s Swift compiler in Xcode. We’ve started annotating all the header files for Swift compatibility – adding nullability and generic infos to many classes. This makes the RO and DA APIs more convenient not just from Swift, but also from Oxygene and C#.

We’re also now including a version of RO/DA for watchOS and, for the next beta, will have pre-built frameworks for tvOS as well.

All of this is of course rounded off by the usual number of smaller fixes, tweaks and enhancements that go into every new version. And we’re not done yet for v9, with more features we haven’t talked about yet coming in future beta drops.

How to get it

How do you get your hands on the goods?

As always, if you’re an existing customer with a active subscription, you have full access to beta drops at Go ahead and grab the latest beta now, and let us know what you think. It should be fairly stable, even for production work.

If your subscription has lapsed, now is a great time to renew, for immediate beta access and a fresh new year of updates.

When will it ship?

We don’t have a firm timeline for RTM, because we know the new features are already available (and production-ready-ish) to you via the beta. So we focus on getting everything good and solid in its own time, and will ship when it’s ready™. That said, we do anticipate to ship RO9 well before the end of the year, probably around November.

That’s all from me for now. I hope you enjoy the beta, and are looking forward to RO9 as much as we do.

Let us know what you think, on the forums or via reply to this post.

marc hoffman
Chief Architect,
RemObjects Software

Profile photo of marc

by marc

An update on Elements, Silver and Fire

September 17, 2015 in "Silver", Elements, Fire, iOS, Oxygene, RemObjects C#, tvOS, watchOS

I wanted to give you a brief update on how things are going in the Elements universe. It’s been almost two months since we shipped our last update to Elements 8.1, and a lot has been going on since then.

The team has been really hard at work on Elements 8.2, which will be another significant feature update. We don’t have an exact timeline for release — and we feel we’re not in a particular rush because the progress has been available to you via our weekly beta drops, and because latest betas have been pretty stable and suitable for production work. But we’re shooting for a final release somewhere towards the end of October or early November.

So what’s been happening for 8.2?

The most recent (and, to me, most exciting) change is tvOS. Apple introduced tvOS only last week as its fourth major development platform, allowing Cocoa developers to create apps for the new Apple TV. Yesterday, less than a week since it’s been announced, we dropped a new beta of Elements with full Apple TV support (in Fire). It’s been a busy week, and we’re really proud to have made that happen.

Using Elements build .1845 you have all the tools you need to build tvOS apps — from project templates for all three languages to support for running on the tvOS Simulator and (hopefully) on real hardware (we haven’t been able to test on real hardware since we haven’t receive our develop kit yet, but we’re pretty confident it’ll work — and of course we’ll test more and provide updates in subsequent weeks, once we can test).

We’ve also been putting the finishing touches on watchOS 2.0 support. A bit more to do there still, as we’re waiting for some changes to make it into the public LLVM repository, but there’s enough there to get you started, including project templates and the full build chain. Build .1845 also adds support for Bitcode (for all three platforms that support it, iOS, tvOS, and watchOS where is mandatory for App Store submissions).

Already since last week’s beta, Elements is also ready for the new iOS 9.1 beta SDK, and includes the final .fx files for iOS 9.0 and OS X 10.11 “El Capitan”.

The compiler team has been making great progress on Swift 2 support as well. We have most of the new features and syntax changes covered already, and expect to tackle the rest in the next couple of weeks, so that Elements 8.2 will ship with full Swift 2 compatibility. At the same time, we’ve updated our Objective-C importer to know and understand all the new metadata that Apple has been adding to its SDKs, so Elements (all three languages) now knows a lot more about the nullability of the Cocoa APIs. We’ve extended Oxygene and C# to inter-operate better with this as well, and the languages have gained full support for non-nullable types on all three platforms, including .NET and Java.

Speaking of .NET, Elements 8.2 will be adding support for Windows 10’s “Universal Application Platform” that lets you create apps for Windows and Windows Phone alike. On a more traditional level, we’re expanding WinForms support out to Silver and RemObjects C#, so that you can now use any of the three languages for that (until now, C# and Swift only supported WPF for Windows GUI development). We’re also updating the toolchain to the very latest ASP.NET MVC6.

Java and Android are more settled platforms and not much exciting new has happened on the outside, in the past half year (at least when compared to the Cocoa and .NET world). But we’re continuously improving the tool chain for all three languages on Java as well. We’ve improved a lot of things under the hood, and we’re also making sure Elements works well with the latest and greatest new Android SDKs, with “Android M” coming out soon.

And of course i have not even mentioned Fire yet. It’s about half a year now that the public Fire Preview is out there for all of you to enjoy, and feedback has been tremendous. I hear from many of you that you are really enjoying working in Fire, and that means a lot.

Fire has been improving on an almost daily basis, with our weekly beta updates including the very latest state. And most beta dos are pretty solid for production use.

A lot has changed and improved since the current public “8.1” preview, from major new features such as the new Debug Inspector pane or “reformat on paste”, to a relentless list of minor tweaks and improvements that keep making every aspect of Fire better, down to the teensiest detail (like how inline error messages now move with your code as you type near them).

I’m planning a separate post/email that covers Fire’s progress to be posted later, and we’ll also have a separate look at what’s going on on the Data Abstract/RemObjects SDK 9.0 front, next week (which Fire also offers deep integration for).

How to get the latest?

Remember, you have access to the latest weekly beta builds, including Fire, if your Elements or Suite Subscription is up to date and active. If you let your subscription lapse, now is a great time to renew, for immediate beta access and a fresh new year of updates to Oxygene and C#.

The Silver and Fire beta is also available to everyone who contributes to Silver, so that’s a good way to get in on the action – and show your support of Silver in general.

Elements 8.2 is shaping up to be a very exciting release (and we haven’t even begin talking about what we have planned beyond.

Thanx for reading,

marc hoffman
Chief Architect,
RemObjects Software

Profile photo of marc

by marc

“Code-First” Servers in RemObjects SDK 9 [BETA]

July 24, 2015 in .NET, Data Abstract, RemObjects SDK

We’ve just shipped the first betas of RemObjects SDK and Data Abstract 9.0, the next major new release of our remoting and multi-tier frameworks.

One of the big new features coming in RemObjects SDK 9, and the one I want to talk about today, is support for what we call “Code First” Servers.

What is “Code First”?

In the past, if you created a new RemObjects SDK server, you started with a RODL file, and would edit that in Service Builder to define all the services and the types that the services worked with. Behind the scenes, RO would then generate code and stub classes for your service implementation for you.

While this mode of creating servers will of course continue to be supported, “Code First” mode does away with RODL files completely — at least on the server — and lets you define everything purely in code.

You simply define your service classes and attach a couple of attributes to make them available remotely, and RemObjects SDK will take care of the rest and make sure they become callable. Similarly, any auxiliary types you define – enums, structs, etc. – you can simply define (and update) in code.

At runtime, RemObjects SDK will generate a RODL representation of your services based on the types it finds in your app and make that available to download for clients. So to the outside, a Code-First looks identical to a traditional RODL-driven server, and for the use on the client, you can still import the (now auto-generated) RODL from your IDE or the codegen tool to generate client Interface stubs.

In the current beta, Code-First servers are supported on .NET, but we plan to make the same functionality available in (newer versions of) Delphi, as well.

Let’s take a look at how this works in practice.

Converting an Existing Server

Since most of you will be starting out with existing RO servers already, let’s have a look at what is involved with converting one to the new model. Mind you, you don’t have to convert your servers to Code-First in order to use RO9. This is not a breaking change, just a new option. Still, I expect many of you will want to move to the new model, because it makes development so much easier going forward. I already converted two of my own projects.

There are really just four steps involved in making the switch, all of them simple, and two of them automated:

  1. Adjust your existing Service implementations
  2. Convert our auxiliary types, such as structs and enums
  3. Remove your RODL file and the auto-regenerating _Intf, _Invk and _Events files generated from it
  4. Add one statement of code to configure your server for Code-First

Adjusting Your Existing Services

While RO auto-generates service stubs for you from RODL, once you add code to those files, we consider them “yours”, and the RO toolchain won’t touch them. In the past, that was one of the annoyances when adding new methods to a service, as you had to edit both the RODL and the implementation.

For that same reason, we won’t auto-convert your service implementations for you, but making the switch is easy. For each of your services, you just do three things:

  • Remove the InvokerClass and ActivatorClass Parameters from the Service attribute. This is the main step, and it tells the RO infrastructure that this service is now using Code-First.
  • Remove the service interfac from the ancestor list.
  • To each of the methods you want to expose publicly, add the ServiceMethod attribute.

In essence, you’d go from something like

@RemObjects.SDK.Server.Service(Name = “LoginService”, InvokerClass = LoginService_Invoker.Type, ActivatorClass = LoginService_Activator.Type)
public class LoginService : ILoginService {

to just

@Service(Name = “LoginService”)
public class LoginService {

(That example is Silver/Swift, but the same idea applies to Oxygene, C# or even VB.)

Optionally you can also remove the StandardClassFactory attribute, as it is the default. (If you switched to a different class factory, you would want to leave the attribute there, and you can also safely leave StandardClassFactory there if you prefer.)

In future betas, the name parameter on the Service attribute will become optional too, requiring it only if you want to expose the service under a different name than the class itself.

Note that you don’t necessarily need to convert all services to be Code-First in one go. You can start by converting some of your services and deleting them manually from the RODL, and leaving others RODL-based. Of course in that case you will want to delay the next two steps until you’re ready to switch the last service over.

At runtime, RemObjects SDK will take care of merging what’s in your RODL and what’s defined “Code-First” and make sure it all works together.

Converting Auxiliary Types

Next, let’s look at all the additional types you may have defined in the RODL to help your services. Enums, Structs, Exceptions or Arrays (although Arrays defined in RODL don’t really reflect in generated code).

In code, these all lie in the _Intf file that you normally don’t touch, because it gets updated from the RODL when that changes. Since the RODL is going away, this auto-updating won’t happen anymore, so you are, in a way, “taking ownership” of these classes now.

You could just keep the _Intf file around, but there’s a ton of extra crud in there that you no longer need, and that would make it hard to maintain/update in the future. So really, it makes sense to clean that up, and we have automated that for you with a small IDE wizard that takes care of this *and* the next step. We’ll get to that in a second.

Remove the RODL and Auto-Generated Code

Once we’ve take care of the auxiliary types, the RODL file and the three source files generated from it (but not the services!) can simply be removed from the server project and deleted.

Bye bye RODL, it was nice to have known you.

The “Convert to Code-First” Wizard

To automate the above two steps, we’ve added a small helper wizard to the IDE. In the first beta, this Wizard is in Fire only, but for the next beta we’ll be adding it to Visual Studio (and eventually Delphi) as well.

In Fire, you can always right-click the RODL file in your server project to see additional tasks specific to RODL files.

If your RODL contains services that don’t have stubs generated yet, you will want to invoke the “Generate Service Implementation(s)” item first to have those generated. In fact, the conversion wizard is grayed out until you do, because otherwise you would lose those definitions.

Normally, that won’t be the case, and all your services will already be implemented. In that case, the last menu option called “Convert to Code-First” becomes active. Simply invoke that to get things going:

When you do, the IDE will do two things:

  • It will generate a new code file in your projects’s language, named after the RODL file, but with a “_RodlTypes” suffix. This file will contain all the types you need – in essence, it will be the same as the previous _Intf file, but without all there extra crud.
  • It will remove the RODL file, as well as _Intf, _Invk and _Events files from the project, and move them to the Trash (where you can still restore them from, if needed. Although needless to say you should have a backup of your project, or better yet have it in version control before doing the conversion).

Once done, you can rename the _RodlTypes file to anything you like, or even move the types in it around into different source files (for example into the same file as their related service) as you see fit for the structure of your projects.

These are now “your” types. If you need to make changes to them for new versions of our server, you simply change them in code.

Configure Code-First

As a last step, there’s two lines of code you want to add to your server. This step probably will go away in subsequent betas and before release and use sensible defaults, but for now it is necessary.

Add these lines among the startup code of your server:

if !RemObjects.SDK.Server.Configuration.IsLoaded {
RemObjects.SDK.Server.Configuration.Load(“MyProject” , “MyProject.Server” )

The first string passed is the “name” of your server, as exposed externally (in the RODL that clients will download); the second string is the namespace that RO’s Code-First engine will use for the helper types it generates under the hood at runtime.

Press “Run”

And with that, your server is converted and ready to run. When you launch and go to http://localhost:8099/bin, you will still see the familiar RODL representation of your server, only now it is driven by the code in your project, not the other way around.

Creating new Services

As you can imagine, creating new services (or a whole new server) will be super easy with the new model, as well. We don’t have Code-First-based templates in the first beta drop, but we’ll be adding them really soon.

To add a new service to your existing server, simply add a new class, attach the Service attribute, and mark the methods you want published with ServiceMethod. Done. If you need new structs or enums, simply define them in code.

To create a brand new server, just add one or more services to the project in the same way, and configure/start up an instance of your existing NetworkServer class (the API for which we’ll be making even simpler later in the RO9 beta). And of course we’ll have templates to help you do this, soon.


We’ve only scratched the surface of Code-First services in this article, but I hope it gave you a good introduction and will help you get started with the feature.

Let us know what you think, how it’s working out for you, and what you would like to see improved!

Profile photo of marc

by marc

About our Build System Infrastructure, CI2

July 21, 2015 in non-tech, RemObjects, Tools

Over the past couple of weeks, we have been working to migrate our build servers to a fully AWS-hosted solution. Our build system has become pretty sophisticated over the last few years, so I thought I would talk about it a little bit, on the off chance that some of you might find it interesting, or get ideas for your own build chain out of it.

Our build system is based on a home-grown infrastructure we call “CI2”. CI2 is a set of tools that we have written over the years that coordinate product builds and – in short – handle Continuous Integration for our products. Essentially, that means whenever someone commits a change to a project to Git, the system goes out and creates a new build of the software and eventually tests it to make sure the new change integrates ok and does not break anything.

CI2 is written in Oxygene (of course) and makes heavy use of RemObjects SDK and Data Abstract for communication.

Until a couple of weeks ago, the bulk of the system had been running on a custom Xserve server – a rack-mountable Mac server machine that Apple stopped making a few years back – that we owned, and co-hosted with a local hosting company here in Berlin. We’ve long been wanting to migrate this to a fully cloud-based hosting solution on Amazon Web Services (which we use for everything else), and when one of the disks in the sever started flaking out a couple of weeks ago, we decided that now was as good a time as any to tackle that.

With how CI2 is structured (I will talk more about that shortly), the migration was pretty smooth, in general. Most of the holdup was that we needed some more infrastructural changes. Because in the past all the builds happened on the same physical machine, we had quite a bit of logic in place that assumed the individual build VMs could access shared drives, and the like. Also, our local VMs had over the years gotten bloated, as we installed new tools, new versions of Delphi and Visual Studio required by the builds, and so on. We wanted to start with clean virtual machines in EC2, and that meant doing some well-deserved clean-up and simplifications to our build scripts – which actually makes the builds better, as well.

As of last Friday, we’re done, and have all our products build cleanly and successfully on the new infrastructure. As an added benefit, builds have gotten a lot faster, as well. It used to be that we waited a good 40 minutes for a full Elements build to finish – and that was without generating all the different set SKUs we build for releases we ship. On the new system, a complete build, with the large Shell-containing setup and everything, finishes in under 25 minutes.

Faster builds means a more productive team, as with complex products like ours, often one needs to wait for a new build from CI before a change can be fully tested.

How CI2 Works

But let’s take a quick look at how CI2 works.

As I mentioned before, CI2 is not a monolithic system, but a set off tools that work together, locally and across the network, to perform all the various tasks. It’s a very flexible and expandable system that has grown and gotten very sophisticated over the past 10 or so years (the first commit in our CI2 Git repository is from 2009. And mind you, the 2 stands for “version 2” ;)).


It all starts with CIStarter.exe. CIStarter is a very minimal tool that gets the whole CI system up and running.

CIStarter does only a couple of things:

  • Based on information read from either a local config file or (more likely, in production use) from EC2 instance data configured in AWS, it connects to an S3 bucket and downloads the actual CI2 system to the local server.
  • Optionally, it runs a tool called CIPrerequisiteInstaller to, well, install prerequisites needed for building our products. More on that below.
  • Finally, it passes things off to run one of the other CI tools or servers to do the actual work. These will usually be CIMainServer, CIBuildServer or CITestServer.

CIStarter has very little logic of its own, and the idea is that (a) only the exe (and optionally a config file) need to be deployed to a server, and more importantly that (b) the CIStarter itself will never really change, even as the core CI2 system gets upgraded.

This means CIStarter can be “burned” into a base image for a virtual machine (be it on EC2 like we use now, or any other virtualization system), and new instances can be booted up as needed. The core CI2 system – which does get regular updates and fixes, of course – can simply be updated on S3, and new instances will always use the latest system.

It’s worth noting that CI2 can run on Windows, Linux and Mac OS X – and we have it, in fact, in use on all three platforms, as you’ll see below.


The first thing CIStarted does after downloading the system from S3 is run CIPrerequisiteInstaller.exe, a small tool that installs and manages all the various packages of tools and files that might be needed to build our products. Like the system itself, these are obtained from S3, so publishing a new prereq is as simple as uploading it to the right bucket, and any new CI instances will pick it up on next run.

Of course CIPrerequisiteInstaller keeps track of which prereqs are installed, and only downloads and installs what’s missing. Prereqs are also incrementally versioned, so newer versions of a prereq can be uploaded, and get installed as needed.

Prereqs we have set up for our system include things such as Elements (we need Elements to build Elements ;), different Delphi versions, packs of third party libraries, and other tools.

One of the cool things is how we handle Delphi. As you might be aware, Delphi installers are slow and bloated, so installing Delphi is not really a good option. We need all versions of Delphi from 7 through the latest XE8 on our system, and if we were to run the installer for each, getting a new instance all prerequisited would, probably quite literally, take half a day (not to mention hundreds of gigabytes of disk space). Instead, our Delphi team figured out a way to package Delphi so that it can be xcopy-deployed with just the files we need to build with it. When a new version of Delphi (or an updated version of an existing version) comes out, we can get all the build machines updated to have it in a jiffy.

Prereq packages themselves can be made up from an .exe installer that runs quietly, or can be a .zip with a Train script that does installation or deployment. CIPrerequisiteInstaller manages unique install locations that individual prerequisites can use, assuming they don’t have a well-defined place they get installed to (for example, our Elements prereq simply runs the Elements installer, while our Delphi packages drop their files where CIPrerequisiteInstaller tells them to).

The idea is that CIPrerequisiteInstaller can both take a cleanly set up and freshly booted build machine instance and get it set up with all the prereqs we need, and it can incrementally update an existing live instance with just the new prereqs that we added.

In our case, we have both a clean AMI that we can boot up to start from scratch (which is little more than a fresh Windows install with CIStarter), but also one with the current set of prereqs already installed. Of course, instances booted up from the latter are quicker to start and ready to run a build.


Once everything is set up, CIStarter passes execution on to one of (currently) three different server tools. Which one is determined by the config file or the EC2 Instance Data.


CIMainServer is the brains of the whole operation. It’s a very lightweight server that does not need its dedicated machine (ours runs on a small Linux EC2 instance that also hosts our email, some of our websites, and other infrastructure, for example).

What CIMainServer does is keep in touch with all the actual build servers via RemObjects SDK super channel connection, and monitor the known Git repositories (some of which we host ourselves, and others we have on GitHub) for changes. As new commits are detected, it will fire off build requests to a suitable build server (i.e. one that’s idle and has the right platform and setup to build the project in question).

Currently, we only distinguish between Windows and Mac build servers, and any server can take a build request for any product on its platform. In theory, one could set up dedicated build servers per product (for example, we could have a server running that builds only Elements and not Data Abstract, if we wanted).

In the long run, CIMainServer will also be able to boot up and shut down EC2 instances as needed, depending on demand. For example, we could have a skeleton crew of one server running over the weekend (if that), but come Monday morning when things get busy and people commit changes and want their builds quickly, it could boot up a few more instances. Currently, we don’t do that, and just run two “t2.large” instances for Windows and one Mac build machine.

CIMainServer uses a small database to keep track of known repositories, active and past builds, as well as their success and testing results. That database could be hosted in RDS, but we find the extra cost isn’t justified since we don’t need that level of fail-over and recovery support, so we just run a local Postgresql DB on the same Linux machine that hosts CIMainServer itself.

CIMainServer is also CI2’s connection to the outside world.

Of course it starts builds automatically as its sees changes in Git, but it also lets us start builds manually (for example if we want a build with a non-default set of options passed to the build scripts, or when the system is locked from doing automatic builds so we can start builds in a controlled order, which we usually do for RTM and public beta builds).

For that, CIMainServer interacts with Slack to listen to commands in the chat channels where our teams hang out, and to also report back statuses. For example, I can simple say “start build elements lockdown” to shoot off a new build of “Elements” from its “lockdown” branch. When a build finishes, a message gets posted to the right channel, along with the URL where the final binaries can be downloaded, or where the log file can be found, if there was a problem.

CIMainServer also has an RO/DA based API, and we have small apps for Mac and iOS that can be used to control builds, get a more detailed status overview, and receive push notifications for critical failures.


If CIMainServer is the heart of the operation, then CIBuildServer is the muscle.

On start, CIBuildServer just connects to the main server, and then waits for instructions. When it receives a build request, it goes out to Git to clone the repository and check out the right branch, and then fires off to the build script found in the repo to build the product.

Of course, it also does a lot of maintenance around that as well, including cleaning up after a build, managing the different folders where different branches are checked out for each repository (we keep the checkout around, because a simple pull is a lot faster for subsequent builds than cloning fresh every time would be), and so on.

CIBuildServer also takes care of publishing the finished binaries and the build logs (to S3, of course), as well as keeping CIMainServer up to date with the build status.

The actual build scripts we use are all based on Train, our JavaScript-based build script engine that is already open source, but in theory CIBuildServer can also pass off to other systems (in the past we used FinalBuilder, which CI2 still supports even though we no longer use it), and the infrastructure is pluggable so that other runners can be integrated as well.

We currently run CIBuildServer for Windows in EC2 virtual machines (these are new since we switched from VMware machines that ran on our Xserve). Since Amazon doesn’t offer OS X-based virtual machines (unfortunately), we also currently run CIBuildServer on a local Mac mini. In the long run, we might switch to something like MacMiniColo. Only the “DA/Cocoa” build needs the Mac, everything else builds on the Windows machines.

The nice thing with how the whole build system is distributed now is that the location of the build servers is immaterial; the only difference we see from the Mac builds running locally is that the upload and download to and from S3 is a bit slower that it is from the EC2 instances (where S3 access is so blazingly fast we were blown away. In fact, a lot of the caching of S3 content that we built into Train and CIStarter feels unnecessary when running on EC2).

The Shared Bucket

One thing that required the most rethinking before we could move to EC2 was what we refer to as “shared” files.

While our products build independently, we do have a lot of inter-dependence between them. For example, Everwood builds as its own repository, but both Elements and RO/DA need it to build. The DA/Cocoa build needs binaries from the DA/Windows build (such as Relativity Server), and vice versa.

In the past this was handled with a shared folder that all build VMs (and the Mac) had access to, but for the move to EC2, this infrastructure had to be switched over to leverage S3.

The way we handle this is that every build that runs gets passed a dedicated S3 location where it can publish generated binaries that other projects might need access to. This location is unique for the project (the ”repository”, really), and the particular branch that builds.

For example, the Everwood build zips up the binaries needed by the other projects, and publishes them to the Shared bucket. When an Elements build runs next, it can use a predetermined logic to find the version of Everwood in S3 that most closely matches the right branch, and grab the bits from there. I say most closely matches, because there will not always be a 1:1 match, of course. We might have a “develop-feature-X” branch in our Elements repo, but no such branch in Everwood – so it will fall back to “Everwood/develop” instead.


The third and last server (currently) is CITestServer. Like CIBuildServer, it runs on its own instance (or instances, although we only run a single one currently). What CITestServer does is wait for builds to finish, and then grab the “dedicated” installer off S3, run it, and apply our suite of tests to it. As with the builds itself, statuses are reported back to CIMainServer, which can post to Slack, send push notifications, and keep track of test results and their evolution over time in the database.

By default, we run tests for the latest new build of every single-word branch (i.e. we’ll test “develop”, but not “develop-feature-x”) that’s new when the test server becomes idle. Tests can take a long time, in many cases longer than the actual product builds, so it’s not uncommon for – say – three consecutive builds to run, but only the first and the last to get tested. Testing times are also what lead us to compromise and test sub-branches such as “develop-feature-x” on demand only.

Our tests once again leverage Train, and a testing infrastructure called “Afterhours” that lets us run test suits created using various different testing frameworks (such as NUnit/XUnit on .NET, DUnit on Delphi, JUnit on Java, as well as of course our own EUNit), as well as some domain-specific test runners we have for Elements, and collect all their results in a standardized manner.


Final binaries, as well as log files from builds, tests and even prerequisite installs are all published to S3. The beauty of S3 is that it’s fairly fail-over resistant, and very accessible.

For giving our staff access to the builds as they get done, we have a few pages on the Staff portal on our website that monitor the respective S3 buckets and offer the files in them for download. This works based on the same infrastructure we use for the public and licensed downloads that are available from our website for you, the only difference being that we skip CloudFront, and just chose a S3 bucket location that’s closest to the bulk of our team, to give the fastest possible download speeds.

Publishing files for our customers (for releases, beta builds, and sometimes one-on-one to your Personal Downloads folder) is as easy as moving the files from one bucket to another (which we currently do manually as needed, but could automate in the future, if we wanted to). We can also give select customers “Fire Hose” access to all the builds that CI2 emits.

S3 offers automatic cleanup/maintenance functionality that we use to move older builds off to Glacier, and eventually delete them (except for the release builds we of course archive, we don’t really need each of the 57 Elements builds that ran yesterday for more than a couple of weeks).


So that’s our CI2 system, as it’s currently in use. We’re fairly proud of it, and very happy with how it works and what it provides for us, so it is a bit of a shame that right now it is purely internal and not many people outside of RemObjects get to see (or use) it – even if you do get to see and use the products it generates.

Who knows, maybe we will change that one day and make CI2 available for general use, be it as open source or as product. The main thing stopping that is that while the system is very flexible and configurable, it does still have a lot of “RemObjects-isms” – little bits and pieces that are made to work exactly how we need it, but aren’t precisely how everyone else would want it. And of course, it being used internally only, it can be pretty rough to set up and configure in places (for example, we add new products/repositories so seldomly that we have no tool for it, but simply add a new row to the database manually ;)).

But whether CI2 will ever see the light outside of our virtual halls or not, I hope you found this an interesting read, a good look behind the scenes of how we work here at RemObjects. And maybe it gave you a couple of ideas for your own build infrastructure.

At the very least, make sure to check out Train, our awesome build script engine. It’s open source and completely free – as is the .NET JavaScript engine that drives it.

Let me known what you think!


Profile photo of marc

by marc

Announcing Elements 8.1.85

July 16, 2015 in Elements

I’m happy to inform you that we have just released a new update to Elements, version 8.1.85.

As the version number implies, this release is a minor update over the previous Elements 8.1 from this Spring (the second one), but it is our most significant yet, with literally over 500 commits and fixes and improvements all across the tool chain.

We’ve been working on this release in parallel to the next big version (more on that below) and really focused on stability and bug fixes. We hope you will find 8.1.85 incredibly solid.

The release is available now, as trial and for registered users, and of course covers all three languages – Oxygene, C# and Swift – and includes Visual Studio, as well as significant improvements to Fire.

What’s Next?

We’re not slowing down, of course. The team has been hard at work on new features and improvements for the next major version, and at the end of this week, we’re planning on making the first beta of Elements 8.2 available. Like 8.1, Elements 8.2 will be a major new release, with significant new features and fast improvements. Already, we have over 1200 commits with new stuff over 8.1.85 that will become available in beta on Friday.

Changes in Elements 8.2 will include an update to Silver to support Swift 2.0, application templates for Windows 10 UAP, support for new Cocoa SDK features, such as ”kindof” and nullability info from Objective-C, language enhancements across the board, and much more.

Get It Now

As always, Elements 8.1.85 is a free update for all users with an active subscription (and of course Silver remains to be free for everybody). Having an active subscription also ensures that you will have access to the 8.2 Beta – so if your sub has lapsed, now is the perfect time to go and renew.

We hope you’ll enjoy the 8.1.85 release and that we’ll see you on the Elements 8.2 beta.

marc hoffman
Chief Architect

Profile photo of marc

by marc

WWDC 2015 and Elements

June 15, 2015 in "Silver", Fire, iOS, Mac, Nougat, watchOS, WWDC, Xcode

It’s been another exciting year at WWDC, even though i personally did not make it out to San Francisco this time. But staying home also has its upsides, as it means I had lots of time to dive into what’s actually been released.

As always there are many things new and coming in the Apple ecosystem that affect our Elements compiler, and with that Oxygene, C#, Silver and of course Fire. Let’s have a look.

New SDKs

Like every year, WWDC brings new editions of OS X and iOS, namely version 10.11 and 9.0. This time around, these new SDKs add not just new functionality (of which there is plentiful), but Apple also made some pretty drastic changes to the API headers, mostly in service of better inter-operation with Swift.

Because most of the headers use new Objective-C language features, such as annotations of nullability and (limited) generics, the new SDKs do not cleanly import with our current FXGen tool. After all, FXGen cannot know about new Objective-C syntaxes that just shipped.

But worry not. Myself and the team have been hard at work this week to update everything, so with the new Elements beta build we will post today (and the new official 8.1 update release coming next week), the new SDKs now import fine and are fully usable – including all the new frameworks and APIs. So get coding!

We’ll continue to work on the import so that for the next release (Elements 8.2, which goes into beta soon), we’ll be able to leverage a lot of the new information these SDKs headers now expose, which will allow us to represent Cocoa APIs even better in Silver, C# and Oxygene. For example, APIs will reflect the more accurate nullability information that’s now available, making them easier to deal with – especially from Silver.


Now, in addition to new iOS and OS X SDKs, Apple also shipped a third, brand new platform SDK: watchOS. On the SDK level, watchOS is very similar to the existing SDKs for Mac and iPhone – it’s just a bunch if frameworks.

In fact as part of the new work on the importer, the watchOS 2.0 SDK is already importing fine, and our compiler is already happily building against it. But of course fully integrating Watch support is more involved – there are many parts of the toolchain and the IDEs that we need to review and expand. Working on this will be a high priority over there next couple of months as watchOS gores thru the betas, and we plan on shipping watchOS support in Elements 8.2 in the Fall (and of course make it available incrementally in the betas, prior to that).

Swift 2.0

The third and last big thing to mention is of course Swift. At WWDC, Apple introduced Swift 2.0, which brings many cool (and some awkward) improvements to the language. Like with version 1.0, there’s a lot tom like here, but also some things that have us scratching our heads in terms of syntax choices ;). But in general, we’re very happy with how Swift is evolving.

Of course we already started on bringing Silver, ur implementation of Swift for .NET, Java and Cocoa, up to speed with the latest language changes. Some parts were easy to do, while others require some more thought.

For example, Apple added ”Error Handling” to Swift, but it is very different from exception handling as it is needed on .NET and Java (and supported in Silver via a Language Extension). We have some cool ideas hewn to integrate the two in a way that’s convenient and intuitive, but we’re still fleshing out the details.

We’ll be working on adding Swift 2.0 support over the course of the next couple of months, as part of Elements 8.2 (and remember that Swift 2.0 itself is in beta right now as well, and bound to change more between now and the time Xcode 7 ships. In fact, in there WWDC sessions Apple was already talking about features not in the current beta release yet).

We’ll update a page on our documentation site with progress on Swift 2.0 support as things move forward.


Let us know what you think. And make sure to check out Elements, if you have not already!

Profile photo of marc

by marc

Announcing Data Abstract and RemObjects SDK 8.3

May 27, 2015 in "Silver", Data Abstract, Delphi, Visual Studio

We’re happy to announce that we just shipped Data Abstract and RemObjects SDK 8.3, a set of significant updates to our flagship emoting and multi-tier frameworks.


Probably the most exciting change for Delphi users in this release is the inclusion of support for the “NEXTGEN” Delphi compiler, and with that support for building FireMonkey applications for iOS and Android in Delphi. We know that many of you felt strongly about being able to use Delphi to build apps for these platforms, and with DA8.3 you now can.

This support of course comes in parallel with our existing support for building apps for these platforms with out native libraries for Cocoa and for Java, respectively. Our platform-native libraries will continue to be a major focus point, and our recommended solution for building great mobile apps.


Version 8.3 also adds official support for using RO/DA in combination with our new a (and free) Silver compiler that we shipped last month. You can now use Data Abstract and RemObjects SDK to build clients and servers using the Swift language. Servers can be created for .NET/Mono, and clients are of course supported for .NET/Mono, Cocoa and Java/Android.

This is a change that should be exciting booth existing RO/DA users who want to use Swift, as well as to existing Swift developers looking to write server code to accompany their client apps.


This release also adds official support for Visual Studio 2015 (Release Candidate, or later), and includes tentative support for Fire, our new native development environment for Mac.

You can use DA with all three Elements languages (Oxygene, C# and Swift) in Fire, and in Visual Studio it of course supports Visual C# and Visual Basic, as well.


Version 8.3 is available now, both as full versions for licensed users, and as free trial. As always, this is a free update for all users with an active subscription.


Profile photo of marc

by marc

A Small Update

May 17, 2015 in "Silver", Data Abstract, Elements, Fire


This just to let you know that a couple of days ago we shipped a small interim update to Elements 8.1, which was originally released at the end of last month. This update, versioned, focuses on fixing a few minor but annoying issues in Elements (such as an endless reboot loop when installing the Visual Studio Shell on some older Windows systems) and a couple of Silver bugs, but adds no major new features to the core product.

Fire has also seen a few bugfixes as well as some small enhancements, such as support for the Force Touch feature on new MacBooks to invoke Peek at Definition (just force-press on an identifier to see its definition – very handy). As always, check out the full change log for there full scoop.

In other news, we’re still preparing our 8.3 update for RemObjects SDK and Data Abstract. A release candidate is available as Gamma now, and it looks like those bits will ship virtually unchanged, this coming week. New features in 8.3 include support for the “nextgen” Delphi/Mobile compiler, as well as for Silver. Stay tuned for the RTM.


Profile photo of marc

by marc

Announcing Elements 8.1, with Swift and Fire

April 30, 2015 in .NET, "Silver", Cocoa, Elements, Fire, Java

Elements 8.1

We are absolutely thrilled to announce the immediate availability of Elements 8.1, the next major version of our Elements compiler with Oxygene and RemObjects C#.

Don’t let the .1 version number trick you, Elements 8.1 is a significant and major update that brings a wide range of features and improvements, building on our 8.0 release late last year. From support for Visual Studio 2015 to IDE-integrated Help, from new language features in Oxygene to full support for C# 6.0 syntax, from Android GUI designer integration to iOS Extension templates, there’s bound to be something new and exciting for everybody.

But of course the most significant new feature in Elements 8.1 is Silver, our implementation of Apple’s Swift programming language.

With Silver, Swift joins the ranks of Oxygene and C# as a third Elements language, and is supported across all three platforms, and with all the bells and whistles you have come to expect from Elements. What’s more, we have decided to make Silver completely free to use for everyone — it will be included for free in your active Elements subscription, and new users who are interested only in Swift can use Silver without requiring an Elements license at all.

The second major new thing shipping with Elements 8.1 — and very close to my heart personally, because it represents the last years of my work – is Fire. Fire is our new native development environment for the Mac, written and designed from the ground up for Elements around our ideas of what a modern and lightweight IDE should look like in 2015. Fire is designed to be fast and nimble, yet powerful.

Fire is not quite ready for the “1.0” moniker yet, so the current version is still considered a preview – but it’s a production stable preview that you should be able to use for your day-to-day work (I personally have been working exclusively in Fire since the beginning of 2014 – that’s 16 months now). Even though still in preview, Fire is available as free public trial download now, and also supports the free Silver compiler – in addition to, of course, Oxygene and C#.

Get Elements 8.1 now

Elements 8.1 is available for download now – both for Windows with Visual Studio, and for Mac inside Fire. You can grab your copy at


marc hoffman
Chief Architect,
RemObjects Software

Profile photo of marc

by marc

An Update on RemObjects Silver

March 31, 2015 in "Silver"


I wanted to take a brief moment to give you an update on the status of Silver, our Swift compiler for .NET, Java/Android and Cocoa.

First of all, thank you again for trying out Silver. Interest in the compiler has been tremendous, with over 1600 people using the beta now. We could not be more thrilled.


Things have really been coming together over the last weeks and the past few weekly beta drops – the beta we shipped last Friday (build .1727) is really solid.

We’re ready for the next step, so this coming week we are planning to promote the current codebase to our lockdown/gamma branches. That means we’ll start preparing to ship based on this codebase, allowing only the most critical and stability-focused fixes to go into the branch between now and when we officially ship “Elements 8.1” (which will include updates to Oxygene and C#, as well as the first official “RTM” release of Silver).

We expect the next build you see to be a Gamma build, and hope to have the “master” Elements 8.1 release with you and all Elements users before the end of April.

Of course, even as we lock down for 8.1, work is already ongoing for the next releases as well, and we’ll make beta versions of that available, too.

Help Us Make Silver a Reality

If you like Silver and what we are doing, and would like to support our efforts, I would like to once again ask you to consider helping us out with a small (or large, if you prefer) financial contribution via the links here, or by purchasing a full Elements 8 license (which will give you all the great features of Silver using the C# and Oxygene languages, as well) here.

Silver is and will be free to use at no charge by everybody – that includes the command line compiler and the full IDE experience in Visual Studio and Fire. Your contributions help us finance the continued development of Silver and all of Elements, and enable us to make it available for free to everybody who wants it.

Thanx Again!

So, thank you again for your interest in Silver, and for taking the time to read this. We really appreciate your thoughts and feedback on Silver (and all of Elements), so please do not hesitate to contact us and let us now, via email or on the Talk forums.

Like you, we are very much looking forward to and excited about the upcoming release.

marc hoffman
Chief Architect,
RemObjects Software