You are browsing the archive for .NET.

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 Anton

by Anton

Little Things that make a difference. Part II. DA LINQ String Operations

January 5, 2015 in .NET, Data Abstract

One thing that DA LINQ lacked until recently was support of the string data comparison operations. This means that there was no easy way to properly express SQL statement like:

  Name > 'Alpha'

using DA LINQ. Even worse – a lot of .NET languages don’t support < or > operators with sting operands. This means that, for example, C# cannot compile code like:

bool r = "A" > "B";

Of course there are a lot of ways to compare strings in .NET, but to use them, you first have to load the data into the client app using DA LINQ and then filter that data locally using Linq2Objects. Obviously, an approach like this is not always feasible, especially on big datasets or slow network connections.

So a different way to express string comparison operations was needed. Data Abstract was recently expanded with a set of extension methods allowing to express string comparison operations in DA LINQ queries like for example:

var data = from x in dataAdapter.GetTable() where x.Name.IsGreaterThan("Alpha") select x;

These extension methods provide enough information for the internal magic of DA LINQ to construct proper SQL statements.

The full list of supported string comparison operations is available on the corresponding docs page at

Notice that while a set of .NET methods is used to express string comparison operations, the actual comparisons are still performed by the database. This has two implications:

  1. This feature will work only if sting comparison operations are supported at database level.
  2. String comparison results depend on database server collation settings.

Happy New Year!

Profile photo of Anton

by Anton

Little Things that make a difference. Part I. Application Base (addendum)

December 19, 2014 in .NET, Visual Studio

In this short article, the server application template created in the previous article will be turned into a real Visual Studio template. Greater minds have already described the process in the MSDN article at

Some preparation work is needed before the project can be turned into a real application template.

First, edit the AssemblyInfo.cs file, so it will look like this:

using System.Reflection;
using System.Resources;
using System.Runtime.InteropServices;

// General Information about the assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with the assembly.
[assembly: AssemblyTitle("$projectname$")]
[assembly: AssemblyDescription("$projectname$")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("$registeredorganization$")]
[assembly: AssemblyProduct("$projectname$")]
[assembly: AssemblyCopyright("Copyright (c) $registeredorganization$ $year$")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

[assembly: ComVisible(false)]

// The version information for the assembly consists of the following four values:
//      Major Version
//      Minor Version
//      Build Number
//      Revision
// You can specify all values, or you can default the Revision and Build Numbers
// by using the '*' as shown below:

[assembly: AssemblyVersion("")]
[assembly: AssemblyFileVersion("")]

[assembly: NeutralResourcesLanguageAttribute("")]

In the ServerApplication.cs file, change the Application ID, Application Name and Service Name properties to:

protected override string Identifier
        return "$guid1$";

protected override string ServiceName
        return "$projectname$ Service";

protected override string ApplicationName
        return "$projectname$";

Open the MainService.cs in the designer and set the ServiceName property to “$projectname$ Service“.

Open the ProjectInstaller.cs in the designer and set the ServiceName property of the ServiceInstaller component to “$projectname$ Service“, as well.

Then replace the namespace ServerTemplate string with namespace $safeprojectname$ project-wide.

Save all changed files and issue the menu command File -> Export Template. Export the project as a project template. Set the template name and description and press the Finish button.

Restart Visual Studio. The template you just created will be available in the Visual Studio project templates.

P.S.: If you really don’t want to follow all those boring steps, here is the download link for the template project. Download, unzip and open it in Visual Studio, then export it as a project template.

Profile photo of Anton

by Anton

Little Things that make a difference. Part I. Application Base

December 18, 2014 in .NET, Visual Studio

This is the first of a set of short articles related to different Data Abstract or SDK features that I feel are important and interesting. Some of them will be just minor improvement notifications, while others will highlight something that can be called a feature but is still way too specialized to be highlighted in a big article. This first article will be about the common application base class that can be used for RemObjects SDK and Data Abstract server applications.

RemObjects SDK contains the ApplicationServer class which provides base application startup infrastructure including Windows Service management and single instance checks.

The ApplicationServer class was designed to provide a common codebase and simplify development of RemObjects SDK and Data Abstract-based server applications. It provides the following features:

  • 3 application run modes – GUI mode (WinForms or WPF), command-line interface or Windows Service.
  • Windows Service management (installation/deinstallation).
  • Optional Single Instance check.
  • Extensible startup arguments parser. The ApplicationServer class provides an overridable method to handle command-line arguments not handled by the default arguments parser. It is also possible to use your own implementation of the command line arguments parser.
  • Single exception intercept point (useful for logging etc.).

By default, ApplicationServer-based applications recognize the following command-line arguments (not case-sensitive):

-I, /I, –INSTALL Install as a Windows Service
-U, /U, –UNINSTALL Uninstall a Windows Service
-Q, /Q, –QUIET Suppress messages on service installation and uninstallation
-C, /C, –COMMANDLINE Run in CLI mode
-D, /D, –DEBUG Request extended debug info (i.e. full stack traces)
-H, /H, -?, /? Show command-line arguments help message

There is no need to write any code to handle these actions.

Data Abstract project templates rely on the ApplicationServer class, but the RemObjects SDK ones are still old-fashioned Windows Forms applications. The next part of this article describes how to create a base application that can later be used as a seed for new server apps development.

  1. Create a new RemObjects SDK project named, say, ServerTemplate.
  2. Delete the ServerTemplateClient from the solution.
  3. Delete the Getting Started.html file from the ServerTemplate project.
  4. The next major steps are to provide network connectivity infrastructure, Windows Service stuff and to tie them all together using the ApplicationServer class.
    First, update the licensing.licx file with the following content (so there won’t be any need to adjust the licenses file for each server project).

    RemObjects.SDK.Server.IpTcpServerChannel, RemObjects.SDK.Server
    RemObjects.SDK.Server.IpSuperHttpServerChannel, RemObjects.SDK.Server
    RemObjects.SDK.Server.IpHttpServerChannel, RemObjects.SDK.Server
    RemObjects.SDK.Server.NamedPipeServerChannel, RemObjects.SDK.Server
    RemObjects.SDK.Server.LocalServerChannel, RemObjects.SDK.Server
    RemObjects.SDK.Server.HttpSysServerChannel, RemObjects.SDK.Server
    RemObjects.SDK.Server.HttpSysSuperHttpServerChannel, RemObjects.SDK.Server
    RemObjects.SDK.Server.SuperTcpServerChannel, RemObjects.SDK.Server
    RemObjects.SDK.Server.EventSinkManager, RemObjects.SDK.Server
    RemObjects.SDK.Server.MemoryMessageQueueManager, RemObjects.SDK.Server
    RemObjects.SDK.Server.MemorySessionManager, RemObjects.SDK.Server
    RemObjects.SDK.Server.OlympiaMessageQueueManager, RemObjects.SDK.Server
    RemObjects.SDK.Server.OlympiaServerSessionManager, RemObjects.SDK.Server
  5. The next step is to create a component that will perform the networking operations. Unfortunately, it is not feasible to use the components already generated by the project template, as they are placed on a Windows Form. So add a new Component Class project item and set its name to Engine. Open the component and add the IpHttpServerChannel, BinMessage and MemorySessionManager components to the designer pane. Register the newly added BinMessage component in the IpHttpServerChannel.Dispatchers collection.

    Also, add the following methods and properties to the Engine.cs code:

    public void Start()
    public void Stop()
    public bool IsActive
            return this.serverChannel.Active;
  6. Now create the Windows Service definition and infrastructure it needs. Add a new Windows Service item to the project and set its name to MainService. Open the code-behind file of the newly added service and set its code to:
    partial class MainService : ServiceBase
        private Engine _engine;
        protected override void OnStart(string[] args)
            this._engine = new Engine();
        protected override void OnStop()
            this._engine = null;
        protected override void OnPause()
        protected override void OnContinue()

    The code above is quite simple. It handles the service state change events and either creates and opens the server channel or closes it and disposes the corresponding components.

  7. Now open the service in design mode again and right-click the designer pane. In the context menu, choose the Add Installer item. This command will automatically add a service installer instance that encapsulates the WinAPI calls needed to install or uninstall a Windows Service.

    At this point, the ServerTemplate project has almost all code and components needed to work as a Windows Service.

  8. Delete the Main.cs form present in the ServerTemplate project and add a new Windows Form to the project named MainForm. Add the following code to its code-behind file:

    public partial class MainForm : Form
        private Engine _engine;
        public MainForm()
            // Required for Windows Form Designer support
            this.FormClosed += OnFormClosed;
        private void StartServer()
            if (this.IsServerActive)
            this._engine = new Engine();
        private void StopServer()
            if (this.IsServerActive)
                this._engine = null;
        // Properties
        public bool IsServerActive
                return ((this._engine != null) && this._engine.IsActive);
        private void OnFormClosed(object sender, FormClosedEventArgs e)
  9. The next step is to tie all these components together using the ApplicationServer class. Add the following class to the ServerTemplate project:
    using System;
    using System.ServiceProcess;
    using System.Windows.Forms;
    namespace ServerTemplate
        sealed class ServerApplication : RemObjects.SDK.Server.ApplicationServer
            private Engine _consoleEngine;
            protected override String Identifier
                    return "2a42e444-5b2c-4f5c-b73a-dd1cab801c0a" ;
            protected override String ServiceName
                    return "SimpleProject Service";
            protected override String ApplicationName
                    return "SimpleProject";
            protected override void RunAsConsoleApplication()
                this._consoleEngine = new Engine();
            protected override void ShutdownAsConsoleApplication()
            protected override void RunAsWindowsService()
                ServiceBase.Run(new MainService());
            protected override void RunAsWindowsApplication()
                Application.Run(new MainForm());
  10. And as the very last step change the application entry point code in the Program.cs file to:
    using System;
    namespace ServerTemplate
        static class Program
            static void Main(string[] args)
                new ServerApplication().Run(args);

And that’s it: The server application project template. Applications created using this template can be run as Windows Forms apps, Windows Services or Linux daemons and are able to install themselves as Windows Services.

If you really want a quick result but don’t want to go over all the steps, here is the download link for the project created during this article: ServerTemplate

So far the only way to use this project template is to copy it to a new place when a new SDK server app is needed. In the next article, this application will be turned into a real Visual Studio project template.

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 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

Data Abstract, RemObjects SDK and Hydra “Spring 2014” Releases

March 31, 2014 in .NET, Cocoa, Data Abstract, Delphi, Hydra, Java

On Friday, we released the latest updates to our Data Abstract and RemObjects SDK products for all five platforms, as well as for Hydra. Like always, a whole bunch of fixes and improvements across the product lines are gathered together in this release.

For Data Abstract and RemObjects SDK, this is also our last planned release for the 7.0 product version, as we prepare for a major new product cycle — codenamed DA8 — starting with our summer release in May. As such, this update focuses mainly on bug fixes and smaller enhancements (of which there are many).

The new release also includes official support for use with our recently released RemObjects C#, including project templates and IDE improvements to let you build .NET, Cocoa and Java apps with RO/DA using our C# implementation, as well as building managed hosts and plugins for Hydra.

As always, the new update is free for all users with an active subscription, and available on the customer portal. Our free 30-day trial downloads have also been updated to the new version.

If your subscription has elapsed, then now is a great time to renew. Renewing will not only give you access to the new 7.0 update, but also access to the beta versions of DA8 that will become available over the course of April, as well as the first (and future) DA8 or RO8 releases throughout the year.

If your previous subscription ended a while ago, you will be happy to hear that we recently updated our online shop to automatically grant “amnesty renewals”. That means you can be assured that your renewed license will always cover the current product and at least six months of future updates from your renewal date.

If you have or are considering getting a Suite subscription, remember that the Suites for .NET, Cocoa and Java now also include RemObjects C# — so you get been more value at the same great price as before (and you can always up-renew from RO or DA to the Suite, of course).

But enough talk, i’m sure you’re anxious to try out the new bits. We’re happy to have this new set of updates out to you now, and we’re extremely excited about what we have coming for DA8 and RO8 this summer and beyond.

marc hoffman
Chief Architect

Profile photo of Anton

by Anton

Winter has come

December 23, 2013 in .NET, Data Abstract

By the time this blogpost will be published, the Winter 2013 release of Data Abstract will already become available. I feel that I should talk about several important features made available in it, and about a few things that will soon fade in oblivion.

So the new features first.

Private Schema tables access. Local Data Adapters (both dataset-based and DA LINQ ones) are now allowed to access Schema tables that aren’t marked as ‘public’ and thus aren’t accessible by remote clients. There is no need anymore to write additional code to access these tables using local data adapters or from Schema scripts.

Data Abstract for Portable Class Library (aka DA/PCL). Yes, this release contains a (limited) port of Data Abstract to Portable Class Library. You can now build one Class Library and then reuse it in Silverlight, Windows Phone or Windows Store application.

Unfortunately the dreaded Technical Debt monster arose and strikes from the back so the PCL library has some limitations on the desktop .NET Framework. The problem is that the RemoteLinqDataAdapter class is located in differently named assemblies in desktop .NET and in all other platforms (namely RemObjects.DataAbstract.Linq.dll and RemObjects.DataAbstract.dll). Introducing the .Linq assembly back-when was a good (and the only) way to introduce DA LINQ without breaking support of .NET 2.0. And an additional assembly wasn’t an issue until a need to create portable set of assemblies arose.

I can say that we plan to provide improve this to more seamlessly support all four .NET platforms (i.e. Windows Phone, Windows Store (WinRT), Silverlight AND desktop .NET) in the next release of Data Abstract. Stay tuned ;)

Important note: Up to this release, non-desktop Data Abstract assemblies had a platform name suffixes in their names (f.e. RemObjects.DataAbstract.Silverlight.dll or RemObjects.DataAbstract.WinRT.dll). Since this release these suffixes exist no more, so ALL assemblies have the same name.

And now to the stuff now considered obsolete.

Data Abstract provides two binary data adapters: BinDataAdapter and Bin2DataAdapter. The former one, BinDataAdapter data adapter, is now considered obsolete and will go away in the next major releases. We have Bin2DataAdapter data adapter that serves the same purpose, is way more advanced and feature-full and, unlike the BinDataAdapter, is supported by Data Abstract on platforms other than .NET and Delphi. The only reason we still shipped BinDataAdapter this long was backwards compatibility. Yet it is time to finally take a step forward and leave this obsolete data adapter behind. So, in the unlikely case that you are still using this data adapter, you really should to consider to switch to the Bin2DataAdapter data adapter. There’s no downside.

Also we have a set of ASP.NET components provided in the RemObjects.DataAbstract.Web.dll. This entire .dll will be removed in the next major release, and has been marked as obsolete. The reason behind this is that the very approach implied by these components is outdated and based on an old model of using ASP.NET. Mixing the UI (ie .aspx code) and data access results in dirty code and errors that can be detected only at runtime, thus resulting in a nightmare while supporting such apps. Believe me, I know. So if you are not using the RemObjects.DataAbstract.Web, then there is no need to worry. If you do then I’d strongly suggest you to either move to the properly layered architecture, where UI has no data access code and/or to take a look at the Data Abstract for JavaScript. It allows to create modern and robust UI and is shipped together with Data Abstract for .NET.

That’s all for now.

Still stay tuned – soon I’ll show you some exciting new features of RemObjects SDK and Data Abstract.

Profile photo of Anton

by Anton

Code Deodorant

October 28, 2013 in .NET, Elements, Tools, Visual Studio

We all write smelly code from time to time. Reasons are different, from ‘I’ll rewrite this code later, I just need this feature working now somehow’ to ‘Deadline is coming and this pesky bug is still not fixed’ or some mistake from a junior developer, yet the result is always the same. Every large codebase has lines of code that smell and stink. Of course there is an ideal codebase repository somewhere that does not have a single line of dirty code, or odd reinvent-the-wheel solutions, or patterns misuse etc… But, I’m afraid, that is along the lines of a flying unicorn. In the real world, we sometimes have to sacrifice code purity to deadlines or other reasons. In this case the main goal is to keep the unclean code and the technical debt caused by it manageable. Not a simple task, when the project has more than 55k lines of code, like ROFX/.NET (i.e. Data Abstract, RemObjects SDK, Internet Pack and Script for .NET) does.

So we need a tool that analyzes our source code and helps to pinpoint code that is potentially dirty. Such tools are called Static Code Analyzers. There are several of them available for .NET and I’d like to highlight the one I like best. This particular tool is not tied to C# or VB.NET and works perfectly with Oxygene code. It also provides Visual Studio integration (including the upcoming VS 2013), and it can also be run on a build machine as a part of the build process. This awesome tool is called NDepend (

In the following, we will create a simple application and apply NDepend to it. We’ll use Oxygene, as I need to show you how to avoid some sharp edges. While C# support in NDepend is near perfect, there are some (minor) nuisances that need to be avoided for Oxygene projects.

Let’s create an Oxygene for .NET Class Library project and add some code like this:

namespace SampleClassLibrary;


  Class1 = public class
    var fUnusedField: Int32;

    method NeverCalledMethod(); empty;
    constructor(); empty;

  UtilityClass = public class
    class method Foo(); empty;

 SomeBaseClass = abstract class
    constructor(); empty;

    method AbstractMethod(); abstract;


As you can see, there are several things that are not ideal, like unused fields and methods or the public constructor of an abstract class. This is, of course, simplified code, where all such things are clearly visible. At the same time, it is very hard to find all suspicious places in a real-world codebase, where the code was created by dozens of different developers and is spread between several projects containing several hundreds of code files. Of course thorough code review would help, but it is still a question of how much efforts it would require. And the question that remains – even after the code review – is to be sure that everything is clean?.

Enter NDepend.

Attach NDepend to the current solution using the menu item NDepend -> Attach new NDepend project to current VS solution.

Because NDepend doesn’t recognize Oxygene projects out of the box, we need to reference the compiled assemblies instead of the source code project, as we would do for C# or VB.NET projects. Press the ‘Add assemblies in Folder‘ button and select the folder containing the current project’s compiled assemblies. Note that NDepend will automatically preselect the folder containing compiled assemblies for the active project.

Confirm the folder selection. Assemblies will be added to the NDepend project.

Press the ‘Analyze a single .NET assembly‘ button and the project analysis will start. After it completes (a very fast procedure, even for big full Data Abstract for .NET solution), a helper dialog will appear.

Open the NDepend rules explorer (NDepend -> Rule -> View Queries).

As you can see, some entries are marked with a warning sign. These are rules that are potentially violated and were successfully detected by NDepend.

  • The abstract class SomeBaseClass should have a protected constructor instead of a public one.
  • The UtilityClass class should be static.
  • The abstract class SomeBaseClass is potentially dead code (it has assembly-only visibility and isn’t used anywhere it this assembly).
  • The Class1.fUnusedField field is not used anywhere and is thus not needed.

Try NDepend on your project and most likely you’ll find some potentially dangerous code lines.

As you can see, NDepend is mostly language independent, so all tutorials and tips ‘n tricks found at can be used with Oxygene, too.

One last advice: For some rules you won’t be able to navigate to a method or class violating some rule by double-clicking the method’s name.

This happens because in some cases (for navigation purposes) NDepend relies on its built-in language parser (that is limited to C# only) rather than on .PDB information. This custom source code parser is used because .PDB files provide information about source code declarations of concrete methods only, so additional effort is needed to acquire information about source code for namespace and type declarations.

To make it easier to find the problematic method, modify the code validation rule output by adding the full method (or class) name. To do this, just change the “rule output statement” (usually found at the very end of each rule’s query code) from code like this (for the Methods that could have a lower visibility rule):

select new { t, t.Visibility , 
                CouldBeDeclared = t.OptimalVisibility, 
                t.TypesUsingMe }

to this:

select new { t, t.Visibility , 
                CouldBeDeclared = t.OptimalVisibility, 
                t.FullName }

Now you’ll see the full path (including namespace and class name) of the problematic entry.

P.S.: Don’t be afraid of the NDepend query language. It is a very powerful way to define own or customize existing code validation rules. At the same time, the predefined rules set allows to use the code analyzer without even touching the query language at all (except for the above-mentioned issue).

P.P.S.: Before you say ‘Hey, this thing is way too expensive’, try to estimate how much time it will save you and your team members and how much this time costs.

Profile photo of Anton

by Anton

Data Abstract for Beginners Guide

October 11, 2013 in .NET, Data Abstract

Do what I do. Hold tight and pretend it’s a plan!


Not long ago we published the RemObjects SDK Beginners Guide. Now we’re taking it one step further and look at the Data Abstract framework.

Most present-day business applications operate with some database data, and most often they are required to run on a variety of mobile devices (from laptops accessing the network over WiFi connections to iPad and Android tablets); now add performance and security concerns and you get an explosive mixture that could take an unpredictable amount of efforts to deal with.

So how can Data Abstract help to minimize these software development risks? Take a look at just some of the features this framework provides:
a) Supports a huge variety of platforms on the client side and .NET (or Mono) on the server side.
b) Provides the ability to create SSL-protected or AES-encrypted communication channels.
c) It is possible to use literally any relational database that has an ADO.NET driver.
d) Data source (database schema or even database server type) can be changed without any changes in the server or client code.
e) Data is sent over the wire in binary-serialized compressed form to keep network traffic at a minimum.
f) The .NET client side provides simple-to-use LINQ interfaces, as well as old-fashioned DataTable-based interfaces to the remote data.
g) With our pre-built Relativity Server you can set up your own middle tier server without writing a line of code.
…and much more.

The article below describes the core Data Abstract facilities and their relationships. It also provides a (very short) jump-in crash course into Data Abstract. In just a few minutes you will be able create your first Data Abstract-based server and client applications.


Data Abstract is built on top of the RemObjects SDK communication framework. In short, a Data Abstract server application is a RemObjects SDK-based server with database connection management, efficient data exchange protocol and declaratively (i.e. not in the program code) defined mapping between the database schema and the data structure exposed to the client applications. On the client side, Data Abstract provides components to simplify the data access so there is no need to manually compose calls to the server.

So the whole picture looks like this:
Data Abstract Overview

As you can see, the core Data Abstracts components are:

  • The ConnectionManager that manages connections to the underlying database (or databases). It allows to pool database connections if the database’s ADO.NET driver doesn’t provide this feature or when more precise control over the connections pool is needed.
  • The Schema that describes mapping between the underlying database tables and data structures exposed by the server (called data tables). The client application only has access to the data exposed via Schema tables, without direct access to the underlying database tables. Schemas can be edited using the Schema Modeler tool.
    Note that the Schema mapping is not necessarily a 1-to-1 mapping (i.e. the database table is exposed as a Schema table). For example, it is possible to expose the result of an SQL SELECT statement as a Schema table and to handle any data updates applied to this Schema table using stored procedures. This approach allows to filter data on data access, do additional data integrity checks on data updates, etc., completely transparent to the client application. Also, some database tables are not suited to be exposed as Schema tables.
  • The DataService, a predefined RemObjects SDK service that exposes Schema data. In most cases there is no need to add any code to this service’s definition.
  • The DataStreamer component that serializes data request results and and data update requests. DataAbstract provides two data streamers – one that exposes data using the highly effective Binary format and another that uses the JSON format to exchange data. The latter one allows to exchange data with platforms that we don’t provide a Data Abstract client library for (f.e. PHP or Ruby server code).
  • The DataAdapter, a client-side component that encapsulates the server method’s calls.

Sample Application

Let’s create a simple server and client application and see how the Data Abstract components are used in a real Data Abstract-based application. Luckily, Data abstract provides a simple-to-use project wizard, so an application skeleton can be created in literally 10 seconds. Just follow these steps:

  1. Start Visual Studio and create a new solution using the Data Abstract -> Windows Forms Application template.
    New Project
  2. Select the ‘Client and a New Custom Data Abstract Server’ project kind on the Wizard screen to create both server and client Data Abstract applications, so we’ll be able to investigate both server- and client-side code.
  3. Select the Default Connections -> PCTrade-SQLite database connection. This pre-defined connection points to a sample SQLite database created whith the Data Abstract installation.
    Database Connection
  4. Now we need to select the database tables that will be included in the Schema generated for the server application. Leave all tables selected and proceed to the next wizard page.
    Schema Tables
  5. The last Wizard page allows to set up some additional options for the solution. We need to keep things simple, so uncheck the ‘Add Login Service’ and ‘Add support for Business Rules Scripting’ project options.
    Project Options

After the Finish button is pressed, the new solution containing the Data Abstract server and client applications will be generated.
You can find a detailed description of both server and client application projects in the corresponding Wiki articles:

For now, let’s examine the core Data Abstract components used in the solution and proceed to actually retrieving data from the server.

Server Application

DataService and DataStreamer

First, we need to take a look at the server’s RODL and the DataService definition.
Service Builder
As you can see, the server’s data service descends from the DataAbstractService defined in the core Data Abstract RODL and doesn’t define any new service methods. This allows us to avoid importing the custom interface file generated for this project, because a pre-generated interface for all service methods is already included in the RemObjects.DataAbstract.dll assembly.
Note that the DataService code file doesn’t actually contain any custom method definitions. All methods used in the Data Abstract client-server communication process are already defined in the base DataAbstractService class. Of course it is possible to add event handlers or even to override method definitions inherited from the base DataAbstractService class, yet this is not needed in the current sample application. However, there are some vital settings that have to be set for the Data Abstract Server to function. In our case, these properties were already set by the New Project Wizard.
Open the DataService implementation in design mode.
First you will see the DataStreamer component. It is tied to the Data Service via its ServiceDataStreamer property.
Also note the AcquireConnection and ServiceSchemaName properties. The first one defines whether the database connection should be acquired using the default Connection Manager when the service is accessed by the client app or if a more advanced connection retrieval process should implemented in the user code (this is not needed for simple Data Abstract servers, but for example Relativity Server uses its own connection management engine). The ServiceSchemaName property points to the project file containing the Schema definition. On application startup, Data Abstract will load this file, deserialize the Schema from it and cache the result.

Connection Manager

The Engine.cs file contains definitions of network-communications-related stuff like Server Channel, Session Manager and Message (see the RemObjects SDK Beginners Guide for more information about these components). Additionally, it contains the Connection Manager that will handle connections with the underlying database.
The Connection Manager will load connection definitions from the .daConnection file on server application startup and will provide connection instances (either from its own internal pool or directly from the driver).


The last (but not least) server application element is the .daSchema file. It contains the mapping between the underlying database and the data structures actually exposed by the server application.
In the simplest case, the database tables are mapped on a 1-to-1 basis to the Schema tables. This the easiest scenario. At the same time, Data Abstract makes it possible to, for example, define a Schema table that exposes data from a complex SQL query involving joins of several tables as a plain table. Given that the needed SQL statements (either stored procedures or plain SQL statements) are defined to handle insert, update and delete operations, the client application will work with the data as if it was a simple plain table. Furthermore, if in the future the data source structure will be changed (for example if a data table containing the needed data will be introduced to the database schema) it would be possible to point the Schema table to this changed data source without changing a line of code in either the server or the client application.
The .daSchema file can be edited using a tool called Schema Modeler. The Schema Modeler can be started either as a standalone application from the Windows Start menu or by double-clicking the .daSchema file in the Solution Explorer.

Additional Information

You can find more about the generated server application project in the following Wiki article.

Client Application


The client application doesn’t differ much from an ordinary WinForms (in this case) application. It contains the main form, the regular Program.cs file, as well as a usual set of references.
Client-side Data Abstract stuff is contained in the RemObjects.DataAbstract.dll assembly. Also, the RemObjects SDK client-side set of assemblies (i.e. the RemObject.InternetPack.dll, the RemObjects.SDK.dll and the RemObjects.SDK.ZLib.dll) is required for Data Abstract, because the network communication relies on the RemObjects SDK infrastructure.
Note that the client application doesn’t contain a custom interface file. It is not needed because all interface classes and interfaces needed to communicate with the server are already defined in the RemObjects.DataAbstract.dll assembly. Of course, if the client application needs to call some custom server methods, a custom interface file will be required.
Look at the Data Module project element. It contains pre-configured server communication components.
Data Module

The Client Channel and Message components are used to send data to the server and retrieve its responses.
The Data Streamer, Data Adapter and Remote Service components, however, are Data Abstract-specific. They are configured to work together:

  • Remote Service receives requests from the Data Adapter and sends them to the server using Client Channel and Message.
  • Data Streamer is used by the Data Adapter to serialize and deserialize requests (including data table data and data update requests). Data Abstract supports two types of Data Streamers – binary and JSON-based. The binary Data Streamer (implemented in the Bin2DataStreamer class) is the preferred one to use, because it is faster and its use consumes less network traffic. Please note that Data Streamer types used by the client and server applications should match, otherwise data exchange won’t be possible.
  • Data Adapter is basically the core of the client-side Data Abstract infrastructure. It exposes the APIs needed to retrieve data from the server and to send data update requests without the need to explicitly call Data Streamer to serialize the data, call server methods etc. And again, there are two Data Adapter kinds that differ in the way data is accessed – via LINQ request or using plain System.Data.DataTable instances (either typed or untyped). Both kinds of data adapters can be used with the same server application (or even in the same client application).

Additional Information

You can find more about the generated client application project in the following Wiki article.

Data Access via DA LINQ

Now let’s fetch some data from the server and then post some update data back to it. In the following, I’ll show both the LINQ and the DataTable way of accessing the data. Let’s begin with DA LINQ, as it is the more advanced approach. You can consider DA LINQ as a (very simple) ORM that fetches data from the remote server and converts it into objects.
As you can see, the client application contains a TableDefinitions_… file. This mysterious file contains a set of classes that are code representations of Schema tables. Each public Schema table is mapped to one of the classes contained in this file, including all table fields represented as class properties. This means that this file should be regenerated in case the data structure of the Schema tables exposed by the server is changed. This article describes how to manage the table definition classes. I suggest you to read this article later, as for now we already have the needed set of Table Definition classes.
To emphasize that Data Adapters (and any other Data Abstract or RemObjects SDK component) can be configured in code and designer support is just a way to speed up development, the following code will use a Data Adapter defined in code.
So let’s instantiate the Data Adapter, create some data access and data update methods and tie them to the GUI.

1. Data Adapter definition
Define private field

LinqRemoteDataAdapter fLinqDataAdapter;

Add the following code to the constructor (AFTER the InitializeComponent method call):

this.fLinqDataAdapter = new LinqRemoteDataAdapter();
this.fLinqDataAdapter.DataStreamer = this.dataStreamer;
this.fLinqDataAdapter.RemoteService = this.remoteService;

Now the Data Adapter is instantiated and tied to the Data Streamer and Remote Service instances.
2. Data access
The simplest Data Access method would look like this:

public BindingList<Customers> GetData()
  var lServerQuery = from x in this.fLinqDataAdapter.GetTable<Customers>() select x;
  return lServerQuery.ToDABindingList();

Note how the data is accessed with a simple LINQ statement on the this.fLinqDataAdapter.GetTable() object. Data Abstract does all the work needed to convert the provided LINQ expression into a form that can be understood by the server application, send the request over the network and retrieve the data. The query used here is very simple. More advanced queries are shown by the DA LINQ Sample, including queries with conditions and queries that fetch only a subset of the target’s table columns.

The mysterious BindingList is a class that simplifies data binding. You can read more about this class in the corresponding wiki article. Of course, the data can be loaded into a simple List<T> as well.

3. Data update
The data update method is very simple:

public void UpdateData()

The Data Adapter tracks changes made to the data into a BindingList, so all changes can be applied using a single line of code. More advanced scenarios are out of the scope of this article. You just need to know that it is possible to make data changes using methods like AddRow, UpdateRow and DeleteRow exposed by remote table instances that can be acquired using the GetTable<T> method of the Data Adapter.

4. GUI
Add 2 buttons and a Data Grid View to the main form of the client application.
Data Abstract Client Main Form
Add the following code to the Click handler of the Get Data button:

this.dataGridView1.DataSource = this.fDataModule.GetData();

Add the following code to the Click handler of the Update Data button:


Run both server and client applications and try to fetch data from the server, update some fields in the data grid and then push the updated data to the server. And that’s it. You have created a network server and client application and added load and save data features to the client application using just a few lines of code.
Data Abstract Client Main Form

Data Access via DataTables

While DA LINQ is the more preferred way of accessing data, Data Abstract also exposes a more old-fashioned data access interface, based on the System.Data.DataTable instances, both strongly typed (corresponding to the server Schema) and untyped ones. This article describes how to manage the strongly typed dataset definitions.

In the following part of the tutorial, we’ll use the untyped dataset, for simplicity reasons.

So let’s again instantiate the Data Adapter, create some data access and data update methods and tie them to the GUI.

1. Data Adapter definition
Define private field

RemoteDataAdapter fDataAdapter;

Add the following code to the constructor (AFTER the InitializeComponent method call):

this.fDataAdapter = new RemoteDataAdapter ();
this.fDataAdapter.DataStreamer = this.dataStreamer;
this.fDataAdapter.RemoteService = this.remoteService;

As you can see, the instantiation of the Data Adapter and its setup are very similar to the LINQ Data Adapter.

2. Data access
In the case of the table-based Data Access, the simplest data access method would look like this:

public System.Data.DataTable GetDataTable()
  System.Data.DataSet lDataSet = new System.Data.DataSet();
  this.fDataAdapter.Fill(lDataSet, new String[] { "Customers" }, true);
  return lDataSet.Tables[0];

This code fetches only the Customers data table from the server.

3. Data update
The data update method is very simple:

public void UpdateData(System.Data.DataTable table)

Note that unlike the LINQ Data Adapter, the Table Data Adapter relies on the .NET DataSet to track data changes.

4. GUI
Change the Click handler of the Get Data button to

this.dataGridView1.DataSource = this.fDataModule.GetDataTable();

Also change the Click handler of the Update Data button to


Run both server and client applications and try to fetch data from the server, update some fields in the data grid and then push the updated data to the server.
As you can see, the table-based access is similar to the DA LINQ-based one, but still differs from it in some details. It is up to you to choose the approach to use, as both of them are valid and fully supported by Data Abstract.


This article only scratches the surface of the Data Abstract framework world. Again (as in the RemObjects SDK Beginners Guide) many features weren’t touched or even mentioned to simplify the article.

Search our Wiki for the questions you are interested in. If for some reason you can’t find the info you need, don’t hesitate to call on our support via RemObjects Connect or drop an email to
I would also be glad to hear your suggestions on what to describe next – Relativity Server, Olympia, or something else?