Profile photo of marc

by marc

Staring into the Fire: Search and Replace

August 4, 2014 in Fire

This post is part of a series in which I want to take a closer look at some of the features and functionality in Fire, our new IDE for the Mac. In this post, I’d like to look at Search and Replace.

Search and Replace is a core feature of any development environment, so of course Fire has sophisticated support for it. The basics work pretty much exactly how you would expect, but Fire goes a bit beyond, so let’s look at the feature in detail.

To start with, as you would expect, you invoke Find/Replace using the standard Cmd-F keyboard shortcut (or via Edit|Find in the menu), which brings up the Find/Replace popup:

Here, you can type a search term and — as you’d expect — you can also choose whether this search term should be treated case sensitive, whether to match whole words/tokens only, or whether to treat the term as a RegEx. As you make your selection here, you will see that it will automatically reflect in the open editor, highlighting every occurrence of the search term in text marker yellow. This will persist even as you dismiss the Find/Replace popover.

What’s more, the search term and settings will automatically synchronize between all files you have open — all across your project, and even across multiple solutions. So as you switch files, or switch to a different document window, you will see your search term is highlighted everywhere. And, like just about all state in Fire, it will also persist across restart of the IDE.

The Find/Replace popover gives you the usual options to Find Next, Find Previous, and of course to replace either one or all occurrences of the search term with a new string.

After you dismiss the Find/Replace popover, these options continue be available via keyboard shortcuts and the Edit|Find menu. Cmd-G will jump to the next occurrence, and Shift-Cmd-G will jump to the previous, both allowing you to cycle round-and-round in the current file. Option-Cmd-G will replace the current/next occurrence of the search term, while Control-Option-Cmd-G will replace all in the entire file.

When replacing, you will notice that the editor also highlights each occurrence of the replace term as well, with a more subtle yellow. This highlighting allows you to easily keep track of what matches your search and what has been replaced already.

If you had enough of your search, you can clear the search term, and make the yellow highlights disappear with it, by pressing Control-Option-Cmd-F (or choosing Clear Search Term from the Edit|Find menu).

But that’s not all. One frequent task while navigating code is navigating between occurrences of the same token, so Fire has a shortcut for that as well. When the cursor is on a word/token, you can press Control-Option-Right or Control-Option-Left to quickly jump to the next (or previous) occurrence of that token. Fire will automatically make the token at the cursor the current search term (so you will see it highlighted all across the file). If not already turned on, Fire will also temporarily enable the “whole words only” option for this search to make sure you only find the exact token (if you want to jump from one use of ‘i‘ to the next, you don’t want to also hit the ‘i’ in ‘begin‘).

When you do a manual search later, the “whole words only” will automatically revert back to its original setting. You’ll find that the Control-Option-Right or Control-Option-Left navigation is something that, once you’re used to it, you can no longer live without

All in all, Fire’s Find and Replace support is well-rounded and — along with Fire’s other navigating mechanisms that I’ll dive into in another post — designed to make it really easy and intuitive to find your way around your code.

Profile photo of Anton

by Anton

AES encryption envelope and Xamarin PCL

July 31, 2014 in .NET

Recently I’ve been asked a question about how the AES encryption envelope can be used with a PCL build of Data Abstract, the issue being that PCL doesn’t expose the needed cryptography API. Although I don’t known the reason for this, I am still going to provide a solution.

Before we dive into the technical details, I have to say that relying on AES message encryption alone is not the best option. Once someone steals your password, they will be able to intercept, read and modify any client-server traffic. So keeping passwords safe and not storing them in non-encrypted form is an absolute must. But you should still consider SSL to protect your communication channels.

Let’s go back to AES for now.

For most of the platforms supported by RemObjects SDK “natively”, the AESEncryptionEnvelope can be instantiated in the application and then this instance can be added to the .Envelopes collection of the Message instance created in the PCL communication library (this is the magic of PCL, yes). Unfortunately, there are two quite important platforms that are supported only by the PCL build of RemObjects SDK. So a solution is needed.

Assume we have a very simple PCL library that calls a RemObjects SDK server and that the server has AESEncryptionEnvelope enabled, so we have to enable it on the client side as well. The client is a Xamarin.iOS application (but the Xamarin.Android approach is exactly the same). Below, I’ll be talking about ‘native’ code, by which I mean code that directly references Xamarin libraries, opposed to code that references PCL.

So the solution is dead simple: In the ‘native’ code part, wrap Crypto API into a form that the PCL code part can understand and provide this wrapped instance to the RemObjects SDK message instance. Obviously, the best way to provide something is to wrap it into a form that RemObjects SDK understands. In our case, we’ll derive a class from the abstract class MessageEnvelope. For further reference I’ll provide the code entirely:

using System;
using System.ComponentModel;
using System.IO;
using System.Text;
using RemObjects.SDK.Helpers;
using System.Security.Cryptography;

namespace RemObjects.SDK
     public class AesEncryptionEnvelope : MessageEnvelope
          #region Default values
          private const String CATEGORY_ENCRYPTION = "Encryption";
          private const String IV = "@1B2c3D4e5F6g7H8";

          private const Int32 BUFFER_SIZE = 65536;//64k
          private const Int32 BLOCK_SIZE = 128 / 8;

          #region Private fields
          private Byte[] fEncodedPassword;

          public AesEncryptionEnvelope()
               : base()

          public AesEncryptionEnvelope(String password)
               : this()
               this.Password = password;

          #region Properties
          public String Password
                    return this.fPassword;
                    this.fPassword = value;
          private String fPassword;

          public override String DefaultEnvelopeMarker
                    return "AES";

          protected override MemoryStream InternalWrap(Stream source, Byte[] header)
               // Size of the original stream
               Int64 lStreamLength = source.Length - source.Position;
               Byte[] lStreamSizeBuffer = BinHelpers.Int32ToBuffer((Int32)lStreamLength);

               // Create bytes array containing
               // [... original header ...][stream size]
               // This is cheaper than creating MemoryStream and then converting it to Byte[]
               Byte[] lHeader = new Byte[header.Length + 4];
               Array.Copy(header, lHeader, header.Length);
               Array.Copy(lStreamSizeBuffer, 0, lHeader, header.Length, 4);

               return this.InternalEncrypt(source, lHeader);

          protected override MemoryStream InternalUnwrap(Stream source)
               // Read size of the original stream
               Byte[] lBuffer = new Byte[BinHelpers.SIZE_INT32];
               Int32 lBytesRead = source.Read(lBuffer, 0, BinHelpers.SIZE_INT32);

               if (lBytesRead != BinHelpers.SIZE_INT32)

               Int32 lStreamSize = BinHelpers.Int32FromBuffer(lBuffer);

               MemoryStream lDecryptedData = new MemoryStream();
               this.InternalDecrypt(source, lDecryptedData);

               if (lDecryptedData.Length < lStreamSize)
                    throw new Exception("Decryption error. Invalid length of the stream.");


               return lDecryptedData;

          private void EncodePassword()
               if (String.IsNullOrEmpty(this.Password))
                    this.fEncodedPassword = null;

               this.fEncodedPassword = new Byte[32];

               Byte[] lPasswordBytes = Encoding.UTF8.GetBytes(this.Password);
               Array.Copy(new SHA1CryptoServiceProvider().ComputeHash(lPasswordBytes), this.fEncodedPassword, 20);
               Array.Copy(new MD5CryptoServiceProvider().ComputeHash(lPasswordBytes), 0, this.fEncodedPassword, 20, 12);

          private CryptoStream GetCryptoStream(Stream baseStream, CryptoStreamMode mode)
               if (this.fEncodedPassword == null)
                    throw new Exception("No password configured for AesEncryptionEnvelope.");

               RijndaelManaged lSymmetricKey = new RijndaelManaged();
               lSymmetricKey.Mode = CipherMode.CBC;
               lSymmetricKey.Padding = PaddingMode.None; // Do padding manually
               lSymmetricKey.Key = this.fEncodedPassword;
               lSymmetricKey.IV = Encoding.UTF8.GetBytes(IV);

               ICryptoTransform lTransform = (mode == CryptoStreamMode.Write) ? lSymmetricKey.CreateEncryptor() : lSymmetricKey.CreateDecryptor();

               return new CryptoStream(baseStream, lTransform, mode);

          private MemoryStream InternalEncrypt(Stream source, Byte[] header)
               MemoryStream lEncryptedData = new MemoryStream(header.Length + (Int32)AesEncryptionEnvelope.GetEstimatedStreamLength(source));
               lEncryptedData.Write(header, 0, header.Length);

               using (CryptoStream cryptoStream = this.GetCryptoStream(lEncryptedData, CryptoStreamMode.Write))
                    StreamHelpers.CopyStreamToStream(source, cryptoStream);

                    // Add tail
                    Int32 lTailLength = ((Int32)(source.Length - lEncryptedData.Length)) + header.Length;
                    if (lTailLength != 0)
                         lTailLength = AesEncryptionEnvelope.BLOCK_SIZE - lTailLength;
                         Byte[] lTail = new Byte[lTailLength];
                         cryptoStream.Write(lTail, 0, lTailLength);


                    // The original lEncryptedData stream will be enclosed together with the CryptoStream instance
                    // Note that the used constructor doesn't actually copy the data, so memory consumption/performance
                    // is not an issue here
                    MemoryStream lResult = new MemoryStream(lEncryptedData.GetBuffer());

                    // Otherwise the tail contained in the buffer will break the AES decryption on the other side

                    return lResult;

          private void InternalDecrypt(Stream source, Stream destination)
               using (CryptoStream cryptoStream = this.GetCryptoStream(source, CryptoStreamMode.Read))
                    StreamHelpers.SetStreamCapacity(destination, source, AesEncryptionEnvelope.GetEstimatedStreamLength(source));
                    StreamHelpers.CopyStreamToStream(cryptoStream, destination);

          private static Int32 GetEstimatedStreamLength(Stream source)
               Int32 lSourceLength = 0;
                    lSourceLength = (Int32)(source.Length - source.Position);
               catch (NotSupportedException)
                    return -1; // Unknown

               Int32 lResult = (lSourceLength / 16) * 16;
               if (lResult < lSourceLength)
                    lResult += 16;

               return lResult;

(You'll have to reference the RemObjects SDK assemblies to get this code compiled.)

Then provide an instance of this AesEncryptionEnvelope class to the code part where the communication components are instantiated and add it there to the Envelopes collection:

message.Envelopes.Add(envelopeInstance, true);

And that's it. AES encryption is enabled.

I also want to mention that while theoretically it is possible to implement AES encryption/decryption completely in managed PCL code, there are reasons NOT to do this. Re-implementing part of the base class library leads to code bloating. What's more important is that cryptography APIs implemented by Xamarin platforms might utilize low-level platform methods for better performance and security – something that a PCL managed code-only implementation won't be able to provide by definition.

PS.: The above-mentioned approach can be extended. More powerful (and resources-consuming) cryptography algorithms can be used instead of AES, like asymmetric encryption. Custom envelopes based on them can be used in RemObjects SDK-powered applications – all you need to do is to properly override the abstract methods of the MessageEnvelope class.

Profile photo of marc

by marc

Two Major Announcements Today, here at RemObjects

July 24, 2014 in "Silver", Cooper, Echoes, Elements, Fire, Nougat, Oxygene, RemObjects, RemObjects C#

Today is a day I’ve been looking forward to for a while. Why? Because today we officially announced two major projects that I am really excited about, and one of them is a project I have been working on for a long time that — as of today — is in the hands of thousands of Elements developers.

So First, Fire.

I cannot overstate how excited I am about Fire. I started working on this project almost two years ago, as a side/weekend project. It evolved slowly at first, and then began picking up speed and came to the point where — much sooner than I had expected — it had become usable. Late last fall, Fire was promoted to be an “official company project”, this spring, it went out to less than a handful of very dedicated external testers. And today, while still considered Beta, it’s being made available to every Oxygene and RemObjects C# user as part of their active subscription.

What is Fire? I am glad you asked.

Fire is a Mac native app, and it’s a place to go to cook up great apps. If you want to use less fancy terms, you could also say that Fire is a new IDE for Oxygene and RemObjects C# that runs on Mac OS X.

My reasons for starting work on Fire where two-fold.

One, I’ve been a Mac user for a long time now (since 2007), but I’m always keeping a Windows VM around to do what? To run Visual Studio. I really wanted to break out of that and develop in Oxygene (and more recently RemObjects C#) directly on my Macs. On my laptop, a VM is way too much overhead, so I never bothered installing one; but even on the desktop, it’s annoying to always have your IDE in a “box”.

Two, while I (kinda) like Visual Studio and love Xcode, I’ve had my own ideas about what would make an IDE great, and I wanted to put those in practice. For version 1.0 those mainly revolve around lightweightness and the IDE not getting in my way. Beyond 1.0, I (and all of us) have more radical ideas.

Fire is the fulfillment of both of those dreams. Since early this year, I have been using it exclusively for all my Elements developing tasks and — if you’re a Mac user — I hope you will be as well, starting today.

You can read more about Fire at, and I’ll also be talking about it more, and going into features in more detail, in future blog posts.

Second, Silver

But just one announcement would be boring, right? That’s why we have two. Today, we also took the wraps off another project we have been cooking up — this one not quite so long, but for about a month and a half.

As you probably know, last month at WWDC, Apple announced Swift, their new programming language for Mac and iOS. We started digging into Swift immediately, and really liked what we saw. So much in fact that we thought about what would be involved in bringing Swift into the Elements language family as a third member. And we didn’t just think about it, we put Carlo to work on it immediately as well.

So today we’re pre-announcing “Silver”, which is our project to do just that. “Silver” will bring the Swift language to Android/Java and .NET developers (and it will work on Cocoa too, for completeness sake). In essence, any place where you can use Oxygene or RemObjects C# now, you’ll be able to use Swift as well. And it will of course work in both Visual Studio and Fire.

While “Silver” is already working pretty great internally, we don’t have a public preview quite yet — but we will soon. You can leave your email with us on the “Silver” home page (below), and we’ll keep you in the loop.

You can find more info on “Silver” and sign up at

Exciting times are ahead. Let us know what you think!

Profile photo of marc

by marc

Introducing DA8, the next major version of Data Abstract and RemObjects SDK

June 27, 2014 in Data Abstract, Relativity

We are incredibly pleased to announce the immediate availability of “DA8″, the next major version of our long-standing Data Abstract and RemObjects SDK products.

What’s New in Data Abstract 8 (and RemObjects SDK 8), Summer 2014?

The Summer 2014 release marks only the first update in our “DA8″ product cycle that brings a revitalization of the Data Abstract and RemObjects SDK frameworks, which now can look back on a proud history of twelve years and five platforms. This release contains a range of major new features that we are very proud of, and that we think will make DA and RO even more useful for your day-to-day work; it also contains a lot of cleanup for our oldest platforms (in twelve years, any library will gather some cruft) and a lot of streamlining, and it sets the base for more features and improvements that we have in the works for DA8 over the near future.

Relativity in the Cloud

One of the big new features for Data Abstract 8 is support for what we like to call “Relativity in the Cloud”. The hosting landscape has changed since DA was first conceived, and, to achieve scalability, more and more businesses are using cloud solutions such as Amazon Web Services or Azure to host their services.

While it has always been possible to run DA server on these services “manually”, we wanted to do more, so for DA8 we have extended Relativity Server to fully embrace the kind of changes and challenges that go hand-in-hand with those deployment scenarios.

For the first release of DA8, we focused on AWS, and Relativity Server now knows about the services provided by AWS that it needs to interact with, all without you writing manual code or setup scripts. You can boot our pre-built machine images to have Relativity Server up and running within seconds, and Relativity Server can automatically configure itself from S3, use databases hosted in RDS, and optionally use DynamoDB for world-scale session management.

It’s never been this easy to get an infinitely scalable middle tier up and running, with just a few clicks and without a single line of code.

You can read more about this here.

We’re working on other cloud services for subsequent updates, with Microsoft Azure being next on our list.

Strongly Typed DataTables in Cocoa

Users of Data Abstract on .NET have long enjoyed working with strongly-typed data tables, where classes are generated based on your schema that let you access the individual fields by proper names. With DA8, we’re bringing this over to Data Abstract for Cocoa, making it even easier than before to write client-side database code.

With just a couple clicks in Schema Modeler for Mac or in the Visual Studio IDE, you have protocol/interface stubs for your tables in the language of your choice — be it Objective-C, Oxygene, RemObjects C# or Swift — that let you work with your data much more naturally. row[@“CustomerName”] simply becomes row.customerName — it’s as easy as that.

Relativity Web Admin

To make administration of Relativity Server even easier, we have added a brand new Web Admin interface that lets you administer your servers right from your browser, without the need for the Admin Tool or Server Explorer for Mac. This works well with Relativity Server in the Cloud, but also with regularly hosted Relativity Server.

Just go to the /admin URL of your Relativity Server, log in with your Admin or Developer login, and you’ll have full access to controlling your server — from changing network settings over configuring logins to managing your domains and Schemas. And you can launch right into Schema Modeler with a single click to start modeling your data layer.

All New “PCTrade 2.0″ Suite of Sample Apps

Data Abstract 8 also includes a brand-new sample database and brand-new suite sample applications that go with it. PCTrade version 2 has been redesigned from the ground up to make it easier to get you started with Data Abstract and try out its features. That’s great whether you’re new to DA or a veteran user learning a new feature.

The new samples are more consistent across platforms, and many samples come in simple command line versions (that let you focus on the core technology) as well as GUI versions (that show you how it integrates with your app). There’s also a new all-encompassing “PCTrade Office” sample that shows you how everything can come together in a more complex and sophisticated project.

You can read more about this here.

PCL Support for .NET

Cross-Platform development is an important topic for many of you, and while Data Abstract comes in distinct native versions for all platforms, many developers choose to use the .NET and Mono framework to target multiple platforms from one managed codebase. Data Abstract 8 comes with full support for building Portable Class Libraries (PCLs) that allow you to build one set of code, in one assembly, and reuse that on all versions of the .NET runtime — from the desktop to Silverlight, Windows Phone and WinRT to cross-platform Xamarin apps.

You can read more about this here in Anton’s blog post.

Improved/New Async APIs for RO/.NET and RO/Delphi

There’s been a big paradigm shift for how network code is written since the original versions of RemObjects SDK for Delphi and for .NET shipped over ten years ago, and more and more developers are using asynchronous call methodologies. The newer platform editions of RemObjects SDK and Data Abstract, starting with RO/Cocoa back in 2008, have already embraced this in their API design, but writing asynchronous code with RO/.NET and RO/Delphi has been difficult on the client side. That is, until now.

Starting with version 8, RemObjects SDK for .NET and for Delphi have brand new APIs that make it easier than ever to write async code. On .NET, these new APIs leverage the new async/await pattern available in C# and Oxygene with .NET 4.0; on Delphi, they work with callbacks, using anonymous methods in newer versions of Delphi, for a model that is similar to block-based APIs on Cocoa.

These changes will make it a lot easier to write responsive client applications, and they also bring the two “more mature” platforms more in line with how client call code already worked in the three newer playrooms, Cocoa, Java and JavaScript.

Cleanup and Freshen-up

New features aside, we’ve also taken the opportunity of this new major release to do some house cleaning. As you know, some of the platform editions of Data Abstract and RemObjects SDK are now over ten years old. They have evolved a lot in that time, and we also had a lot of chances to learn, as we kept adding additional platforms to the mix — rewriting, and to a certain degree re-inventing the product from scratch for each platform. DA8 takes the opportunity to freshen up the older code bases to things we learned from the newer implementations (such as the async support mentioned above), and also to remove and trim some old cruft that had accumulated over time.

As a result, the new editions are leaner, meaner, and ready to move forward for the next ten years of innovation we have planned.

But don’t worry — we have taken special care to make sure that all your existing projects will of course still build ok, and that updating/migrating to the new version is as easy as ever. And of course RO8 and DA8 remain fully wire compatible with older versions, as well.

Bugfixes, Enhancements and More

And of course, as always, in addition to these major new features, the new releases also come with a huge number of other, smaller fixes, improvements and enhancements to make the product even better and more enjoyable too, day to day. This includes improvements to the Schema Modeler and Service Builder tools, updates to the APIs, and enhancements to the IDE integration and experience.

Here at RemObjects, we’re super excited about this new release and about where Data Abstract is going, moving forward. We hope you’ll enjoy it, too!

Profile photo of Anton

by Anton

PCLs, async/await server calls, and more…

June 26, 2014 in .NET, Data Abstract

The new Data Abstract 8 is out. So I’d like to highlight some of its features and the changes they imply.

Xamarin support changes

To start with, the Xamarin iOS and Android platforms are now supported via Data Abstract for the Portable Class Library. This means that there is no more separate Data Abstract for MonoAndroid or MonoTouch builds.

On the bright side, this means that both target platforms now share the same set of features and, due to the PCL support, development of code shared between iOS and Android targets becomes a little easier. There are, however, some caveats you should be aware of:

  • Only DA LINQ data access is supported, DataSet support on the iOS side is not available anymore, so a data access code revamp is needed.
  • Only the simple HTTP client channel is available in Data Abstract for PCL. While this might look restricting, it is still the best choice for apps targeting mobile devices operating with a potentially unstable connection. In such conditions, SuperHTTP has no considerable advantage over the simple HTTP client channel.
  • Only asynchronous server calls are possible. While this is a must in the mobile world due to unpredictable network delays, it can be a real headache when the Begin/End asynchronous calls pattern is used, especially when several remote calls are chained in the same method. Luckily, starting this release, RemObjects SDK for .NET now provides support for async/await remote calls.

async/await remote calls

Old async code with callback methods and BeginOperation/EndOperation calls was hard to develop and maintain. Starting with the Summer 2014 release, RemObjects SDK now allows to call remote servers using code like:

var result = await service.SumAsync(1, 2);

Of course, the target platform also has to support await calls, so this feature is not supported for .NET 3.5 clients. For all other target platforms,_Intf code will contain method declarations like:

public interface ISampleService_Async : RemObjects.SDK.IROService_Async {
    System.IAsyncResult BeginSum(double a, double b, System.AsyncCallback @__Callback, object @__UserData);
    double EndSum(System.IAsyncResult @__AsyncResult);
    System.Threading.Tasks.Task SumAsync(double a, double b);

Note the last method declaration. It is the asynchronous server call proxy that can be called using the async/await pattern.

Unfortunately, it is not possible to expand the DataAdapter class with …Async methods due to the necessity to support .NET 3.5. Instead, a set of extension methods was introduced that provide nearly the same experience.

These extension methods are defined in the assembly RemObjects.DataAbstract.Async.dll. For platforms that support Extension SDK packages (f.e. Windows Phone) this assembly is included in the Data Abstract packages. On other platforms (f.e. desktop .NET) this assembly has to be referenced explicitly.

Note that to call an extension method, you need to add the namespace this method is declared in to the using (C#)/Imports (VB.NET) or uses (Oxygene) clause.

The following extension methods are provided:

  • IBaseLoginService_Async interface, methods are declared in the RemObjects.DataAbstract namespace.

    • Boolean LoginExAsync(String)
    • LogoutAsync()
  • DataAdapter (including LocalDataAdapter and RemoteDataAdapter), methods are declared in the RemObjects.DataAbstract namespace. All methods are awaitable versions of corresponding synchronous DataAdapter methods.

    • FillAsync(DataSet, Boolean)
    • FillAsync(DataSet, Boolean, Boolean)
    • FillAsync(DataSet, String[], Boolean)
    • FillAsync(DataSet, String[], WhereExpression[], Boolean)
    • FillAsync(DataSet, String[],TableRequestInfo[], Boolean)
    • FillAsync(DataTable, WhereExpression, Boolean)
    • FillAsync(DataTable,TableRequestInfo, Boolean)
    • FillWithDASqlAsync(DataTable, String, DataParameter[])
    • UpdateAsync(DataSet)
    • UpdateAsync(DataSet, String[])
    • UpdateAsync(Delta[], Boolean)
  • LinqDataAdapter (including LocalLinqDataAdapter and RemoteLinqDataAdapter), methods are declared in the RemObjects.DataAbstract.Linq namespace.

    • LoadListAsync<T>(IQueryable<T>) – asynchronously loads data into List<T>
    • LoadBindableListAsync<T>(IQueryable<T>) – asynchronously loads data into BindingList
    • ApplyChangesAsync()

    Asynchronous data loading using one of these methods will look like

    var list = await fDataAdapter.LoadListAsync(
            from x in fDataAdapter.GetTable<Clients>() select x);

Windows Phone Applications support

This application type has a somewhat misleading name. Microsoft has renamed the good old Windows Phone apps based on Silverlight to Windows Phone Silverlight applications and introduced new WinRT based phone applications as Windows Phone. We register Data Abstract and RemObjects SDK as Extension SDKs for both these platforms. In case you want to reference Data Abstract assemblies directly, you need to reference assemblies from the WindowsPhone folder for Silverlight based applications and assemblies from the WinRT folder for Windows Phone Store applications. It is strongly recommended to use the ExtensionSDKs’ references instead of direct assembly references to avoid situations where wrong assemblies are referenced and the application just cannot be built.

That’s all for now. See you around and don’t forget to check the Breaking Changes page!

Profile photo of marc

by marc

Announcing the Elements “June 2014″ Update

June 19, 2014 in Elements, RemObjects C#

We are pleased to announce the new “June 2014” update to Oxygene and RemObjects C#.

“June 2014” is a small interim update for our Elements compiler that focuses mainly on improvements and bug fixes, but nonetheless brings — alongside over one hundred fixes — a handful of very significant new features and enhancements:

  • We’ve made major improvements to the WinRT and Windows Phone tool chains that will help you build apps for Microsoft’s modern app platforms. This includes support for new toolchain changes that come in Visual Studio 2013 Update 2 (which is a rather significant new release of VS, despite the incremental sounding name).

  • We’ve improved the Cocoa toolchain in significant ways, such as the ability for Elements to automatically pick your default Profile and Certificate when opening and building new iOS projects, and an improved UI that handles the case where you updated Xcode and need newer versions of the iOS or OS X SDKs — including the option to automatically download support for new SDKs, where available.

  • The new release has also been tested with the iOS 8.0 and OS X 10.10 Yosemite beta SDKs to make sure you’ll be able to import these SDKs and start working with the new features right away. (Unfortunately, we cannot ship pre-imported .fx files for these SDKs until they are out of beta and not under NDA anymore).

  • Cross Platform Compatibility Warnings have been improved for this release, with new warnings added and improved handling of these warnings inside conditionally compiled code, irrelevant warnings will, for example, now be suppressed in parts of the code that is clearly intended for a single platform based on $IFDEFs.

  • The code editor smarts have been improved, with automatic parenthesis and bracket completion, making it yet a bit more quicker to type your code on a day-by-day basis.

  • Finally, the June release of Elements integrates with our new Help Viewer app (currently available as separate download from the beta portal) to show you context sensitive help at the press of a button — not just from our Elements Wiki but also from the core platform docs off all our supported platforms — including the .NET Framework, the OS X and iOS SDKs, as well as the Java and Android SDKs.

And as always, this lists just the tip of the iceberg. Check out our full change log for details and more changes.

Also as always, the new release is a free update to all customers with an active subscription. If your subscription has lapsed, you can renew for $499 (single language) or $699 (to renew to both Oxygene and RemObjects C#).

New user licenses are available at $699 for both Oxygene or RemObjects C#, or $999 for both.

Happy Coding!

Profile photo of marc

by marc

“Under new Management”

June 9, 2014 in non-tech, RemObjects

On behalf of all three co-owners of RemObjects Software, I am very pleased to announce that we have chosen Steve Scott (“Scotty”) to serve as the new Chief Executive Officer (CEO) for the company.

I have known Scotty personally for many years, and he has worked with us for the last 7 months as a developer evangelist. In that time, he has shown an excellent strategic understanding of both our business and the industry that surrounds it. When it came to choosing a new CEO, Scotty was the obvious choice, and we are very excited about this change.

As one of the many benefits of welcoming Scotty to this new position, it frees me (the CEO until now) to focus more tightly on the technical side of the company, both across our current line of products (including Elements and Data Abstract) and for future technical direction development. Our upcoming “Fire” product later this year will be the first to benefit from this additional technical attention.

We feel that with this new structure, RemObjects Software is now in an even better position to move on to the next level as a company that provides high quality and industry-leading software tools to developers who care about getting it right.

marc hoffman

Profile photo of marc

by marc

Xcode 6, iOS 8, Yosemite, Swift, and You

June 4, 2014 in Data Abstract, Elements, RemObjects C#, WWDC

As you’ve probably heard by now, Apple release a whole lot of goodness for developers on Monday. As an Oxygene or RemObjects C# (or even a Data Abstract for Cocoa) developer, you’re probably asking yourself how these changes affect you.

Obviously, there’s a lot of things we cannot talk about yet — in part because it’s been less than two days since the new stuff was announced and we need to do a lot more research — and in part because many of the details are under NDA, and will remain so until Fall.

So, what can we say?

iOS 8 and OS X 10.10 Yosemite SDKs

The new SDKs import fine with the latest Gamma build of Elements that’s available to licensed users, and they will import fine with the imminent June release (based on that Gamma) that is coming later this week.

Why do you need a new build? Two reasons: We expected OS X 10.10 to not import with the previous version, simply because the internal integer versioning system Apple uses for OS X was reaching a conflict at 10.10 and our importer wouldn’t know how to calculate the right version code, until we looked at what Apple decided to do there. So that is broken “by design”. There were also a couple of small oddities in both 10.10 and 8.0 that our importer didn’t handle (basically, some Objective-C construct that was too weird for us to run into it sooner). Those had to be fixed.

In general (and moving forward) we aim for new Beta SDKs to import clean with current/previous Elements builds, w/o requiring action from us, of course.

Xcode 6

With the new SDKs imported, Oxygene and RemObjects C# work, as far as we can tell in our limited testing, fine against the new Xcode 6 command line tools, besides some issues with the Simulator APIs, which have changed pretty significantly in version 6.

If you run into any problems, remember that you can always change the version of Xcode that Elements sees back to Xcode 5.1, using the xcode-select tool, without needing to de-install Xcode 6. So you don’t need to hesitate about installing Xcode 6.

Of course we need to and will do more testing (especially on some of the areas with new features) to get Xcode 6 fully supported by the time it ships.


Of course the big announcement on Monday was Swift — Apple’s new programming language that’s destined to replace Objective-C in the long (or even short) run. It’s very exciting to see Apple take this step, which frankly I had been expecting – but not quite so soon, and not with such a drastic change in language style (Swift is *very different).

Swift opens up a lot of opportunities, but also challenges. On the one hand it “competes” with our Oxygene and RemObjects C# compilers for the spotlight of “more modern languages on Cocoa”, but on the other, it also opens developers up to the very idea that Cocoa does not have to mean Objective-C.

There’s also a lot of technical work for us to do. Swift does not compile to straight Cocoa objects, but brings its own object layer and APIs that Oxygene an RemObjects C# developers will want to interact with, and there’s work needed there — work that I can’t talk about in more detail, because much of Swift is covered by the Apple NDA until it is released. Of course we are fully committed to making this work, so that you can use code written in Swift as seamlessly from Elements as you can use the code written in Objective-C today.

If you’re a Data Abstract or RemObjects SDK for Cocoa developer, you’ll probably just want to use those libraries from Swift. This should just work out of the box, because Swift and Objective-C already mix and interact seamlessly in Xcode 6. Of course we’ll do a lot of testing on this front, see if maybe RO/DA can use some API revisions to make it work even better with Swift, and we’ll be providing project templates for Swift once Xcode 6 ships.

I will keep you updated as things develop. For now, I’ll let you get back to playing with the new toys!


Profile photo of marc

by marc

Announcing Elements 7.1

April 30, 2014 in Cocoa, Elements, RemObjects C#

Welcome back.

Hot on the heals of the brand new first release of RemObjects C# last month, we have just shipped the new 7.1 update to both RemObjects C# and our Oxygene language.

Despite the very short timeframe, 7.1 deserves the increased version moniker, as it includes — next to a huge amount of fixes, tweaks and improvements — several major new features that we’re very excited about.

Generics for Cocoa

You’ve asked and we listened, so version 7.1 brings full support for generic types to the Cocoa platform — for both Mac and iOS.

While 7.0 already allowed generics to be used on mapped types and provided generic variations of NSDictionary and NSArray, the new version now extends this to support generics on all types – including custom types derived from standard Cocoa classes such as NSObject or more concrete types. The sky is the limit.

Of course this feature is available in both the RemObjects C# and Oxygene languages, and I think this is yet another big step towards language parity between the platforms.

Colon operator, meet C#.

We just could not live without it ourselves, so we went ahead and implemented support for the ?. operator that’s rumored to be officially coming in C# 6.0 to our RemObjects C# dialect, ahead of time. The ?. is, essentially, what the colon (:) operator has been in Oxygene for ages: a way to safely call members of objects, whether the reference is null or not.

So you can now, for example, write if (myArray?.count > 0) and not care if myArray is null or not.

As in Oxygene, the ?. operator will convert the result into a nullable type, and RemObjects C# benefits from the full nullable arithmetic and ternary boolean logic as Oxygene when working with these types.

This means that if you mix nullable types in more complex expressions, the entire expression will become nullable. For example, myArray.count *5 could be null, 0, 5 or 10, depending on whether myArray is null.

We find that the ?. operator (and Oxygene’s colon one) comes in especially handy on the Cocoa platform, where calling members on null objects is second nature for developers coming from Objective-C. I’ve been porting a huge chunk of code from Objective-C to C# these past few weeks, and it’s been a lifesaver.

iOS 7.1 Support in the Box

Timing was not on our side when Apple shipped iOS 7.1 shortly after we shipped Elements 7 last month, and so manual import of the iOS 7.1 SDK was needed for anyone wanting to use RemObjects C# or Oxygene with the new SDK and the new Xcode 5.1. This new update — fittingly enough, given the version number — now includes support for iOS 7.1 in the box to make this easier. And we’re working on infrastructure to make these overlap periods less painful going forward, in time for iOS 8 and the next OS X release.

And there’s more

Further language and compiler enhancements include:

  • We’ve introduced a new [Category] aspect to make it easier to implement extension classes (i.e. “categories”, in Cocoa parlance) in RemObjects C# without the need for a special syntax (Oxygene, of course, has dedicated extension class syntax for this, but it can also use the new aspect).
  • We’ve extended Cross-Platform Compatibility Mode so that it now ignores the difference in case for the first letter of class called members, and ignores the case of namespaces in cross-platform code. This makes it a lot easier to deal with shared code on .NET (which prefers PascalCase) and Java or Cocoa (which prefer camelCase, and require lowercase namespaces).
  • We’ve added additional Fix-Its and Auto-Fixes.
  • We’ve added support for methods on records/structs on the Cocoa and Java platforms — yet another checkmark against language compatibility across all three targets, as .NET has had this feature from day one.
  • We’ve created new templates and added support for the ASP.NET Razor view engine.

Finally, for everyone downloading Oxygene or RemObjects C# fresh, we have also converted the “with Visual Studio” installers from .ISO files to embedded .exe installers to make them even easier to use.

What are you waiting for?

The new release is available now, and as always it is a free update for everyone with an active subscription. You can find it for download either in your Licensed Downloads area, as well as on the public Trials page. It (optionally) includes the Visual Studio 2013 IDE.

If your Oxygene subscription has lapsed, there has never been better time to renew than now to get both the new release, and everything we have planned for the the rest of the year (and beyond). Such as cough Fire cough. As always, you can renew your Oxygene license for a mere $499 per user. And we also have a special “up-renewal” that lets you renew Oxygene and add RemObjects C#, for only $699.

If your RemObjects C# subscription has lapsed, then, well, you’re a time traveller, and regular rules do not apply to you ;).


Also, for the very last time a reminder that if you are a Prism user, abandoned by Embarcadero, chances are you might be entitled to extended Oxygene for .NET releases from us, and/or qualify for special renewal or cross-grade pricing for both Oxygene and/or RemObjects C#. Check our Prism FAQ for details, or contact us if you have questions.


I’m very excited about this release. In many ways, it is what the 7.0 release we shipped in March should have been like. It received a ton of attention, testing and bug-fixing internally, and it’s probably the most solid release we ever shipped (only to be topped by what we have coming for May ;)..

I hope you enjoy it, too. Let me know what you think!

marc hoffman
Chief Architect

Profile photo of marc

by marc

New Betas!

April 24, 2014 in Data Abstract, Elements, RemObjects C#

Hi everyone.

Over the past weekend, we shipped major new beta builds for, well, just about every single one of our products.


On the Elements front (Oxygene and RemObjects C#) we’ve also shipped the first beta for the May 2014 update, which will be a minor bug-fix update, but has a lot of significant improvements nonetheless. Check out the change log for details. (Of course, before that, the April update with version 7.1 is imminent and has been in gamma and locked down for a while; we expect that to ship as RTM this week.)


For our ROFX products, including Data Abstract and RemObjects SDK, I know that many of you are looking forward to the major new “DA8” (and RO8) release. Well, last week’s beta is the first publicly available beta off that development branch, and will give you a first peek at what’s coming in DA8. It’s far from feature complete, but there’s a lot of new and exciting stuff already there, from new features to support hosting Relativity in AWS, over better asynchronous APIs for Delphi and .NET (all the other, newer platforms already had pretty nice async APIs to begin with), to our all-new and very extensive PCTrade2 sample suite. From improved DA SQL client support in DA/Delphi, over Amazon DynamoDB Session Manager support, to our new Login Provider infrastructure. But there’s still more to come.

As part of the new DA8, we’ve also been doing a lot of “spring cleaning”, bringing the codebase (especially for the older and more mature products for Delphi and .NET) up wit the times, and removing some old cruft that as accumulated over the years as the frameworks evolved. Please refer to the change logs (available on and in the Beta app), as well as the ROFX Beta forum on Talk for details.

Oh, I should mention that this beta also includes support for the just-released Delphi XE6, and the same goes for the new Hydra 4 gamma build that is available, as well.

We’ll be publishing more regular semi-weekly beta updates for ROFX (much like we always do for Elements) as we prepare for the first “DA8” release to launch officially in May.

We’re very excited about this next release, and the team has been very busy. We hope you’ll like what you’ll see — and please let us know in the comments, in the beta forum, or via email to info@.