Breaking Changes
- 10.0.0.1589 Release
- 10.0.0.1583 Release
- 10.0.0.1555 Release
- 10.0.0.1491 Release
- 10.0.0.1461 Release
- 10.0.0.1453 Release
- 10.0.0.1449 Release
- The May 2019 Release
- The March 2019 Release
- The November 2018 Release
- The October 2017 Release
- The April 2017 Release
- The March 2015 Release
- The June 2014 Release
- The Fall 2012 Release
- The Summer 2012 Release
- The Spring 2012 Release
- The Fall 2011 Release
- The Winter 2010 Release
- The Summer 2010 Release
- The Spring 2010 Release
Breaking Changes in the 10.0.0.1589 Release
Remoting SDK for Delphi
breaking change: Enum values in POST and XMLRPC messages were written incorrectly and they cannot be read by other platforms.
Note: it was affected only if Prefix Enum Value
checkbox in Service Builder was checked
Breaking Changes in the 10.0.0.1583 Release
- dataservice.ServeSchema property was added to both platforms (Delphi and .NET).
It can be considered as a security hole. We recommend to set it to False
for release configuration of your project.
Breaking Changes in the 10.0.0.1555 Release
Data Abstract for Delphi
- Generation of specific update SQL for ORACLE was removed. for reverting old behavior add
{$DEFINE DA3_ORACLE_SUPPORT}
intoDataAbstract_user.inc
and launchC:\Program Files (x86)\RemObjects Software\Build\install_DA.cmd
with admin rights.
Breaking Changes in the 10.0.0.1491 Release
Remoting SDK for Delphi
- breaking feature: generation of RODL in run-time from CodeFirst services was changed
old behavior can be reverted via disabling
CodeFirst_Use_RODL_Uses
&CodeFirst_Generate_Abstract_Services
inRemObjects.inc
Data Abstract for Delphi
- Ancestor for TBaseLoginService was changed from TDataAbstractService to TBaseDataAbstractService.
Breaking Changes in the 10.0.0.1461 Release
Remoting SDK for .NET
- Changed property names of the
CustomCrossOriginEventArgs
fromAllow*
toAllowed*
to better reflect their purpose
Data Abstract for .NET
-
Changed visibility of the REST serializer:
- Removed the
RestMessage
class - Changed visibility of the
JsonRestMessage
class to private - REST dispatcher: removed
Message
property
- Removed the
-
REST and OData dispatchers: Renamed Event Argument classes to conform to the .NET naming guidelines:
ODataOnGetServiceSchemaArgs
toODataGetServiceSchemaEventArgs
RestOnGetSchemaDataTableArgs
toRestGetSchemaDataTableEventArgs
RestOnLoginNeededArgs
toRestLoginNeededEventArgs
RestOnProcessTargetUrlArgs
toRestProcessTargetUrlEventArgs
RestOnUnknownRequestArgs
toRestUnknownRequestEventArgs
-
REST and OData dispatchers: Event handler types for corresponding events are now based on the
EventHandler<T>
type
These changes are a part of the planned integration of REST dispatcher into HttpAPI.
Breaking Changes in the 10.0.0.1453 Release
Data Abstract for Delphi
uDAActiveScriptProvider
was removed
Breaking Changes in the 10.0.0.1449 Release
Remoting SDK for Delphi
-
Channels were renamed:
-
Indy
prefix was added to Indy Super TCP channels:TROSuperTCPServer
->TRO
Indy
SuperTCPServer
TROSuperTCPChannel
->TRO
Indy
SuperTCPChannel
-
Prefix of Synapse-based servers was changed from
Ip
withSynapse
:TRO
Ip
HTTPServer
->TRO
Synapse
HTTPServer
TRO
Ip
SuperHTTPServer
->TRO
Synapse
SuperHTTPServer
TRO
Ip
TCPServer -> TRO
Synapse
TCPServer
-
- TROIcsAsyncSuperTCPServer server was removed
Backward_compatibility
define and all related aliases were removed.
Data Abstract for Delphi
Custom SQL macro (processing of custom SQL macro statement terms like {macro_name_here}
, done via OnUnknownSqlMacroIdentifier
event handler) is now DISABLED by default.
This is done for security reasons, as improper use of this feature (like allowing users to set values that will be later substituted as the macro value) results in SQL injection vulnerability.
Feature can be re-enabled by explicitly setting Data Service property AllowCustomSqlMacros
to true. The default value of this property is false, which means that an exception will be raised if custom macro is encountered in the schema SQL statement.
Note: old name of this event is OnUnknownMacroVariable
. this name wasn't removed for backward compatibility.
Breaking Changes in the May 2019 Release
Remoting SDK for Delphi
TROAsyncCallback
declaration was changed. old:
TROAsyncCallback = procedure (const aRequest: IROAsyncRequest) of object;
new:
{$IFDEF TROAsyncCallback_as_reqular_method}
TROAsyncCallback = procedure (const aRequest: IROAsyncRequest) of object;
{$ELSE}
TROAsyncCallback = {$IFDEF DELPHI2009UP}reference to{$ENDIF}
procedure (const aRequest: IROAsyncRequest);
{$ENDIF}
for reverting old behavior, just declare TROAsyncCallback_as_reqular_method
in your project or uncomment the same condition in RemObjects.inc
Breaking Changes in the The March 2019 Release
Remoting SDK for Delphi
TROUri.PathElements
property was removed. workaround: useTROUri.ParsePathElements
method instead of.ReadVariantFromBinary
/WriteVariantToBinary
reads/writes varBoolean value as Integer instead of Byte. This change was made for compatibility with Remoting SDK for NET.
Streams with session, stored with TROSession.SaveToStream
can not be read properly after this change.
Workaround: store boolean values into session as Integer like
Session.Values['xxx'] := Integer(ord(boolean_value));
and re-read/re-write such session streams before installing this release.
Breaking Changes in the November 2018 Releases
Data Abstract for Delphi
Parameter of the TDARemoteCommand.Execute
method was changed from in
to out
direction:
was:
function Execute(aCommandName: string; aInputParameters: DataParameterArray;aOutputParameters: DataParameterArray): Integer; override;
now:
function Execute(aCommandName: string; aInputParameters: DataParameterArray;out aOutputParameters: DataParameterArray): Integer; override;
If you are using this overload method, workaround will be in not creating aOutputParameters
.
old code:
lInput := DataParameterArray.Create;
lOutput := DataParameterArray.Create;
try
// initializing input parameters
DARemoveCommand.Execute(l_CommandName, lInput, lOutput);
// processing output parameters
finally
lInput.Free;
lOutput.Free;
end;
fixed code:
lInput := DataParameterArray.Create;
lOutput := nil; // changed
try
// initializing input parameters
DARemoveCommand.Execute(l_CommandName, lInput, lOutput);
// processing output parameters
finally
lInput.Free;
lOutput.Free;
end;
Breaking Changes in the October 2017 Releases
Remoting SDK for Delphi
We have introduced new types: ROAnsiString
and ROUTF8String
. They are aliases for String
type and used as a replacement for legacy AnsiString
/UTF8String
.
Since this version, codegen generates _Intf, _Invk and _Impl with these types.
Notwithstanding, these types are written/read to stream as before. pay attention to last parameter:
property fld_ansi: ROAnsiString read ffld_ansi write ffld_ansi;
property fld_utf8: ROUTF8String read ffld_utf8 write ffld_utf8;
..
__Serializer.WriteLegacyString('fld_ansi', l_fld_ansi, [paAsAnsiString]);
__Serializer.WriteLegacyString('fld_utf8', l_fld_utf8, [paAsUTF8String]);
You may need to update method declarations in your _Impl if you have errors that some methods aren't found in _impl.
Breaking Changes in the April 2017 Releases
Remoting SDK for Delphi
TROSession class was updated and now it uses the TDictionary class for storing session values. this is applicable for Delphi XE6+ or Nextgen compiler.
The TROSession.Keys
property was added. old TROSession.Names
property was deprecated.
Note: for using old implementation, uncomment ROUseGenerics
in RemObjects.inc
or add {$UNDEF ROUseGenerics}
after {$I RemObjects.inc}
line in uROSessions.pas
Breaking Changes in the March 2015 Releases
Remoting SDK for Delphi
TROProxy doesn't ignore RemoteService.ServiceName
as a result, this code:
RemoteService.ServiceName := 'ServiceA';
(RemoteService as IServiceB).MyMethod;
will call ServiceA.MyMethod
instead of ServiceB.MyMethod
as it was earlier.
possible problems: Unknown method XXXX for interface YYYY
can be raised for working code.
workarounds:
- validate that RemoteService.ServiceName specified correctly
- in RO8.3 uncomment
{.$DEFINE TROPROXY_IGNORES_REMOTESERVICE_SERVICENAME}
in RemObjects.inc - revert old behavior via editing
uROProxy.pas
as:
constructor TROProxy.Create(const aRemoteService: IRORemoteService);
begin
Create(aRemoteService.Message, aRemoteService.Channel);
fCloneMessage := aRemoteService.CloneMessage;
//fInterfaceName := aRemoteService.ServiceName;
end;
Breaking Changes in the June 2014 Releases
Remoting SDK for Delphi
- D6 support were removed
-
Sources were split to
- Client part
- Server part
-
Encryption support (property of channels and servers) is installed only if legacy component is selected in setup. also it is affected to
- RODEC folder
- uROEncryption.pas
- uROEncryptionEnvelope.pas
- TROAESEncryptionEnvelope class were moved to uROAESEncryptionEnvelope.pas
- <eventsink>_writer interface were moved from _intf to _invk file
-
ZeroConfHub support was removed:
- uROZeroConfHub.pas
- uROZeroConfHubSynapse.pas
- uROZeroConfStreamWorker.pas
Data Abstract for Delphi
- D6 support were removed
-
Sources were split to
- Client part
- Server part (files were moved to
Server
subfolder) - BaseLoginService_Impl.pas
- Data AbstractService_Impl.pas
- MultiDbLoginService_Impl.pas
- MultiDbLoginServiceV5_Impl.pas
- SimpleData AbstractService_Impl.pas
- SimpleLoginService_Impl.pas
- uDAADOInterfaces.pas
- uDABusinessProcessor.pas
- uDAConnectionManager.pas
- uDAConnections.pas
- uDADataDictionary.pas
- uDADatasetWrapper.pas
- uDADataTableReferenceCollection.pas
- uDADB2Interfaces.pas
- uDADBEventRepository.pas
- uDADBSessionManager.pas
- uDADiagrams.pas
- uDADriverForeignKey.pas
- uDADriverManager.pas
- uDAEBaseDataset.pas
- uDAEBaseStoredProcedure.pas
- uDAEConnection.pas
- uDAElevateDBInterfaces.pas
- uDAEngine.pas
- uDAESQLCommand.pas
- uDAHelpers.pas
- uDAHETConnections.pas
- uDAHETDriver.pas
- uDAIBInterfaces.pas
- uDAJavaScriptHttpDispatcher.pas
- uDALocalCommand.pas
- uDALocalDataAdapter.pas
- uDALocalHelpers.pas
- uDAMySQLInterfaces.pas
- uDANativeDatabaseAccessSupport.pas
- uDAOData.pas
- uDAODataDispatcher.pas
- uDAODataGenerator.pas
- uDAODataMetadata.pas
- uDAOracleInterfaces.pas
- uDAPostgresInterfaces.pas
- uDAQueryBuilder.pas
- uDASchema.pas
- uDAScriptContext.pas
- uDAServerLog.pas
- uDASimpleDataStreamer.pas
- uDASimpleQueryBuilder.pas
- uDASQL92Interfaces.pas
- uDASQL92QueryBuilder.pas
- uDASQLiteInterfaces.pas
- uDASQLMacroProcessor.pas
- uDASybaseInterfaces.pas
- uDAUnionDataset.pas
- uDAUtils.pas
- Legacy part (files were moved to
Legacy
subfolder): - DALoginService_Impl.pas
- DARemoteService_Impl.pas
- Data Abstract3_Async.pas
- Data Abstract3_Intf.pas
- Data Abstract3_Invk.pas
- uDAActiveScriptProvider.pas
- uDAADODataTable.pas
- uDABinAdapter.pas
- uDACache.pas
- uDACDSDataTable.pas
- uDADatasetProvider.pas
- uDALegacySupport.pas
- uDAMSScriptControl_TLB.pas
- uDAObjAuto.pas
- uDAPlainWhere.pas
- uDAXMLAdapter.pas
-
some interfaces from uDAInterfaces.pas were moved to uDAServerInterfaces.pas
-
deprecated properties of TDADatatable were removed in favour of TDALocalDataAdapter:
- LocalDAConnection
- LocalSchema
- LocalDataStreamer
- LocalConnection
- OnLocalUpdateDataBeginTransaction
- OnLocalUpdateDataCommitTransaction
- OnLocalUpdateDataRollBackTransaction
-
uDAClasses.pas unit was removed. content was moved to following files. Compiler can fail at compiling some forms. In this case, modify unit via adding a space in code or similar and save unit, IDE will add required units to uses section automatically.
- uDACore.pas
- uDAStreamableComponent.pas
- uDAConnectionManager.pas
- uDADataDictionary.pas
- uDADiagrams.pas
- uDAUpdateRule.pas
- uDADatasetRelationship.pas
- uDASchema.pas
-
some server-side properties of IDADataset interface were moved to IDAServerDataset. casting
<IDADataset> as IDAServerDataset
will return valid IDAServerDataset interface, e.g.
lsql := (ldataset as IDAServerDataset).SQL;
- support of
TDAWhere
was removed fromIDAServerDataset
in favourDynamicWhere
property. for backward compatibility is possible to set prepared where statement viaIDALegacyWhereSupport
interface as
(ldataset as IDALegacyWhereSupport).WhereClause := 'ID > 100'
- support of TDAWhere was removed from TDADataTable. for backward compatibily, class helper for TDADataTable with Where property was added into uDAPlainWhere.pas
Internet Pack for .NET
- The
HttpRequestInvalidException
exception class now accepts onlySystem.Net.HttpStatusCode
as Http status code instead of arbitrary integer values
Remoting SDK for .NET
Http Codes
- Properties pair
Code
/Status
that represents HTTP return code has been replaced with single propertyHttpCode
of typeSystem.Net.HttpStatusCode
. Old properties are marked as obsolete and are still accessible. However it is strongly recommended to use theHttpCode
property.
MasterServer support
- Classes related to the MasterServer Session Manager were removed from Remoting SDK
Moved Classes And Interfaces
- Interface
IRodlProvider
has been moved from namespaceRemObjects.SDK.Server.Extensibility
to namespaceRemObjects.SDK.Server
- Interface
IServiceManagerExtender
has been moved from namespaceRemObjects.SDK.Server.Extensibility
to namespaceRemObjects.SDK.Server
Obsolete Methods and Properties
- Property
ComplexType.TypeName
has been removed - Property
Service.IsAbstract
has been removed
Renamed Classes
- Exception
SessionsHasBeedDisposedException
has been renamed toSessionDisposedException
. Dummy exception classSessionsHasBeedDisposedException
is still available as obsolete one.
Service Activation/Deactivation methods
- Methods
Service.Activate
andService.Deactivate
are no longervirtual
and cannot be overridden. Instead virtual protected methodsService.InternalActivate
andService.InternalDeactivate
were introduced. This change was introduced to remove possibility of undefined behavior in case theService.Activate
andService.Deactivate
methods are overridden and their new implementation doesn't call the corresponding base method.Important
: Do not call thebase.Activate
orbase.Deactivate
methods in theirInternal*
counterparts
Session And Event Management
- Session properties
LastAccessedTime
andCreated
now returnUTC
time, not local - Remoting SDK now uses the
ISessionManager
interface to access the global session manager instead of the reference of the baseSessionManager
class type. - Remoting SDK now uses the
IMessageQueueManager
interface to access the global message queue manager instead of the reference of the baseMessageQueueManager
class type. - The
IStremableSession
interface has been removed. - The
IEventNotification
interface has been renamed toIEventDataProvider
- Obsolete method
void SessionManager.GetAllSessions(IList)
has been removed. MethodIList<Guid> SessionManager.GetAllSessions()
should be used instead. - Unused method
MessageQueueManager.ExpireSessions
has been removed. - Remoting SDK now uses the
IEventSinkManager
interface to access the global session manager instead of the reference of the baseEventSinkManager
class type.
ZeroConf support
- ROZeroConfHub has been phased out and is not shipped anymore
- Enum
ZeroConfEngine
is now marked as obsolete. Please consider to remove all references to values of this type. This enumeration will be completely removed from Remoting SDK in the late 2014 releases. - Nested type
RemObjects.SDK.ZeroConf.ZeroConfRegistration.ZeroConfRegistrationErrorArgs
was moved out and is now namedRemObjects.SDK.ZeroConf.ZeroConfRegistrationErrorArgs
- Property
ZeroConfRegistration.AutoStartZeroConfHub
is now obsolete and will be completely removed from Remoting SDK in one of the late 2014 releases.
Data Abstract for .NET
Assemblies
- The
RemObjects.Data Abstract.Linq
assembly has been merged into theRemObjects.Data Abstract
assembly - The
RemObjects.Data Abstract
assembly now requires at least .NET 3.5
Business Processor
- Event handler definition for the
BeforeGetTableData
event now requires sender ans 1st argument and is defined (for consistency reasons) as
method BeforeGetTableDataEventHandler = public delegate(sender: BusinessProcessor; e: BeforeGetTableDataEventArgs);
Moved Classes: Local Data Adapters and Commands
- The
RemObjects.Data Abstract.LocalCommand
(RemObjects.Data Abstract
assembly) class has been moved to theRemObjects.Data Abstract.Server
assembly - The
RemObjects.Data Abstract.Linq.LinqLocalDataAdapter
(RemObjects.Data Abstract.Linq
assembly) class has been moved to theRemObjects.Data Abstract.Server
assembly - The
RemObjects.Data Abstract.LocalDataAdapter
(RemObjects.Data Abstract
assembly) class has been moved to theRemObjects.Data Abstract.Server
assembly - The
RemObjects.Data Abstract.IData AbstractLocalServiceAccess
interface (RemObjects.Data Abstract
assembly) has been moved to theRemObjects.Data Abstract.Server.IData AbstractLocalServiceAccess
interface in theRemObjects.Data Abstract.Server
assembly - The
RemObjects.Data Abstract.Linq
assembly is now a stub and there is no need to reference it.
Obsolete Classes, Methods and Properties
- Obsolete class
BaseLoginService.LoginString
was finally removed. Use theRemObjects.Data Abstract.Server.LoginStringParser
class instead. - Obsolete (and unused)
SchemRelationship.RelationshipType
property and corresponding enumeration type were removed - Obsolete (and unused)
BusinessProcessor.IgnoreStaticCommands
property was removed - Property
BusinessProcessor.ServerEvents
is no longer available in the designer - Bin1 Streamer was removed and is no longer available.
- RemObjects.Data Abstract.Web assembly has been removed. Consider using ordinal Data Abstract infrastructure to access server data.
Renamed Classes and Enumerations
- Enumeration
RemoteDataAdapterStatus
was renamed toDataAdapterStatus
Breaking Changes in the Fall 2012 Releases
Interface code needs regeneration for .NET projects in some cases
Since URL Schemes
feature was introduced the code generation facility generates two additional constructors to allow convenient service Proxy
instances creation passing System.Uri
or URL string as a parameter. The generated code looks like this:
public partial class MegaDemoService_Proxy : RemObjects.SDK.Proxy, IMegaDemoService {
// ...
public MegaDemoService_Proxy(System.Uri aUri) :
base(aUri) {
}
public MegaDemoService_Proxy(string aUrl) :
base(aUrl) {
}
// ...
}
Affected users: Users who created a custom service hierarchy where the final service is derived from other custom service(s). This causes the corresponding proxy class to be derived from other custom proxy classes, not from the Proxy
class directly.
Required actions: Regenerate the interface code for all RODL files used in the project or solution.
NOT affected users:
- Users of platforms other than .NET
- The majority of users who don't use custom inherited services
- Data Abstract users who derive their services from Data Abstract built-in ones directly
Existing iOS projects must be linked against Security.framework
Since Remoting SDK for Xcode allows to deal with SSL certificates it requires the Security.framework
API for internal operations. But iOS implementation is a static library and contains no linking information inside. New applications created with RO templates have all requred library references out-of-the-box.
Breaking Changes in the Summer 2012 Releases
RemoteService class property CloneMesage removed
Misspelled property CloneMesage was removed from the RemoteService
. Please use the RemoteService.CloneMessage
property instead.
Removed property was marked as obsolete since 2009.
Breaking Changes in the Spring 2012 Releases
Relativity Server Default Channel type changed to SuperHttp
Relativity default channel now registers itself as superhttp
in ZeroConf environment, not as http
like earliser.
This change does not
break server access for existing Relativity clients because Relativity default channel now accepts both SimpleHttp and SuperHttp connections.
OlympiaServerSessionManager.GetAllSessions
result changed
The OlympiaServerSessionManager.GetAllSession(IList)
method now puts only session identifiers in the list provided instead of downloading entire sessions objects from the Olympia server as earlier.
It is highly recommended to use the strongly-typed IList<Guid> GetAllSession()
method overload instead.
RemoteDataAdapter ReconcileDialog events changes
- Obsolete
RemoteDataAdapter.ShowReconcleDialog
event was removed RemoteDataAdapter.ShowReconcileDialog
event handler signature changed fromdelegate(RemoteDataAdapter, DataSet, List, Boolean)
todelegate(Object, ShowReconcleDialogEventArgs)
RemoteDataAdapter.ShowReconcileRecordInAppUI
event handler signature changed fromdelegate(RemoteDataAdapter, DataSet, DeltaChange, Boolean, ReconcileDialogAction)
todelegate(Object, ShowReconcileRecordInAppUIEventArgs)
- Obsolete delegate types
ShowReconcleDialogEventHandler
andShowReconcileRecordInAppUIEventHandler
are no longer available
Breaking Changes in the Fall 2011 Releases
RemObjects.SDK.Server.Session
class renamed to SessionRolesHelper
The RemObjects.SDK.Server.Session
class has been renamed to RemObjects.SDK.Server.SessionRolesHelper
and changed to be a static
class. This change affects code that checked Session security roles using one of the RemObjects.SDK.Server.Session.ValidateRoles
methods directly. Please consider using method Service.ServiceValidateRoles
instead or fix code that called RemObjects.SDK.Server.Session.ValidateRoles
by replacing RemObjects.SDK.Server.Session
with RemObjects.SDK.Server.SessionRolesHelper
.
Breaking Changes in the Winter 2010 Releases
Default port changed for the IpSuperHttpServerChannel
Default port was changed for the IpSuperHttpServerChannel
server channel from 80 to 8099. This potentially affects Remoting SDK for .NET server applications created using pre-Winter 2010 releases if they were using IpSuperHttpServerChannel
server channel on port 80. To resolve this, simply set port 80 in the Server Channel's properties explicitly, if you want to keep using this port.
Pre-compiled binaries for Hydra / Remoting SDK Integration
Starting from the Winter 2010 release we no longer provide pre-compiled *.bpl
's for the Hydra - Remoting SDK Integration Library, in order to minimize build dependencies between the products. To use Remoting SDK for Delphi functionality in Hydra, you will need to manually compile and install Hydra_RO_D1*
and Hydra_RO_IDE_D*
into the Delphi IDE.
Poll Interval on ROEventReceiver in RO/Xcode now uses Seconds
For consistency with other Cocoa APIs, the poll interval setting on the ROEventReceiver is now specified in seconds, not milliseconds. If you were manually setting this value in code, your numbers might need adjustment to be 1/1000 of the values in use now.
Breaking Changes in the Summer 2010 Releases
Obsolete RemObjects.Common.Pooling
namespace removed from RO/.NET
The obsolete namespace RemObjects.Common.Pooling
was removed from Remoting SDK for .NET. This potentially affects Remoting SDK and Data Abstract for .NET server applications created using pre-Spring 2010 releases. Members of this namespace were used to specify PoolingBehavior
for the ConnectionManager. Build error may occur in case non-default values like RaiseError
or IgnoreAndReturn
were used for this property. To resolve this error it is enough to just replace RemObjects.Common.Pooling
with RemObjects.SDK.Pooling
.
RemObjects.Common.Pooling
had already been marked as "obsolete" and emitted warnings, in previous releases.
BPDX Channels Have Been Discontinued for RO/Delphi
As per request form the original author, we are no longer shipping the BPDX based server channels in Remoting SDK for Delphi, nor the underlying RO/DXSock libraries. This affects the \BPDX and \RODX folders of the source tree, as well as the RemObjects_RODX_*
and RemObjects_BPDX_*
packages.
If you are upgrading from a previous version of Remoting SDK, the source files will not be removed, and you can of course continue using them, while they still work with the current RO code base (Over time, and as Remoting SDK for Delphi adapts to newer versions of Delphi and different platforms supported by Delphi or FPC, they may cease working).
We recommend that users migrate to one of the other choices of channels we provide, such as Indy, Synapse or IP based channels.
We are working with the authors of DXSock to create new channels based on their latest DXSock 6.0, for a future release, but do not as of yet have a definitive timeline to announce.
RO/.NET Variant Serialization Incompatibly was Fixed
In Remoting SDK for .NET, the Variant
class is designed to provide compatibility with the Delphi variant type. When the variant instance contains boolean value, it was erroneously (de)serialized as Int32
by error, i.e. the boolean value occupied 4 bytes in a stream. This was incompatible with the behavior of Remoting SDK for Delphi. This has been changed in the current release, so variants containing boolean values are now serialized as Byte
occupying 1 byte in the stream.
Gthis change restores binary compatibility with Remoting SDK for Delphi (and also the new Variant support in Remoting SDK for Xcode added in this release, but may break in the unlikely event of variants being sent between .NET servers and .NET clients, if not both client and server are updated to use Summer 2010 release.
Breaking Changes in the Spring 2010 Releases
Method Signature Changes in Data Abstract for Xcode
The [DADataTable getDataTables*]
methods have been changed to return an NSDictionary instead of an NSArray. We realize this is a breaking change, but given the relative newness of the DA/OX API and that a return value of an array was really quite unhelpful (there's no easy way to get at the appropriate tables by name), we decided this was worth changing now, while the product is still young.
Only the synchronous versions of the methods are affected.
Events Subscription and Compatibility between Delphi and .NET
This change is not really breaking, all existing functionality has been left intact. However, the explanations below are important to understand to succeed in cross-platform events implementation.
Overview
If you have used both Remoting SDK for Delphi and .NET simultaneously, you may have noticed that the callback events processing approach differs slightly and it was impossible to, for example, build a Delphi server that sends callback events to a .NET client application.
In this release we have fixed this problem, but discovered a security flaw in the Delphi events approach: the client application was allowed to manipulate with its own events subscription. It allows to create a malicious client application that will flood the server with millions of subscriptions causing the denial of service and the server has no ability to resist it. That's why we have decided to not propagate the Delphi events approach to the .NET side. The .NET approach has been implemented in RO SDK for Delphi instead.
Summary:
- Remoting SDK for .NET was not affected at all.
- The LegacyEvents property of boolean type was added to the TROEventReceiver class. This property is true by default and allows to switch the receiver's operation mode from the legacy Delphi style to the new .NET style.
- The LegacyEvents property of boolean type was added to the TRORemoteDataModule class. This property is true by default and when set to false disallows the self-subscription of events for the client applications.
Directions for developers
- In order to provide compatibility between a Delphi client and a .NET server, the TROEventReceiver.LegacyEvents property must be set to
false
and the client application has to be recompiled with version 6.0.45 or later of Remoting SDK for Delphi. - To provide compatibility between a .NET client and a Delphi server, the server application must be recompiled with with version 6.0.45 or later. It is also advised to set the LegacyEvents property of the service implementation class to
false
if there are no legacy clients (ie clients written with prior versions of Remoting SDK for Delphi) connecting to the server. - Even in the single platform scenario (both client and server applications are Delphi-written), it is advised to set both mentioned properties to
false
and recompile both applications with the latest version of Remoting SDK. This will remove the events security flaw.NOTE:
If the client application can't be upgraded for some reason, there is nothing to be done, because setting LegacyEvents to false on the server side will only make the server incompatible with legacy clients. - After the server upgrade it is vitally important to take control over the clients subscription/unsubscription on the server side. The TRORemoteDataModule.RegisterEventClient method must be called from inside the service before any events are sent to the client. The opposite method is TRORemoteDataModule.UnregisterEventClient. In the most common case, developers don't need to pay no attention to the unsubscription because the client will be unsubscribed automatically when its session dies.
Example (based on the File Broadcast sample of how to change the method in the FileBroadcastService_Impl.pas file:
procedure TFileBroadcastService.uploadfinished(const filename: Unicodestring; const filesize: Int64);
begin
// This line should be added so the event can reach the client:
RegisterEventClient(GuidToString(ClientID), EID_FileEvents);
(EventRepository as IFileEvents_Writer).OnNewFileAvailable(Session.SessionID, filename, filesize);
end;
WideString vs UnicodeString types in Unicode versions of Delphi (2009 and later)
Overview
In Delphi 2009, a new data type for wide strings - UnicodeString was introduced, which is more efficient than the old WideString. During the migration Remoting SDK to Unicode, a mistake was made, and RODL codegen was not changed to use the new UnicodeString type (with an alias being provided for Delphi 2007 and below), as was intended; instead WideString was still used. Starting with the Spring 2010 releases, this has been rectified, and RODL-generated code now uses UnicodeString.
Summary:
- For fields, parameters and array elements in RODL with type
WideString
, generated code will now useUnicodeString
type. - This will affect all auto-generated sources: interface, async interface and implementation files.
Directions for developers
- For developers using
Delphi 2007 or older
, no change is required. Your Intf files will be rewritten to containUnicodeString
, but that is defined as an alias toWideString
, and remains compatible. - For developers using
Delphi 2009 or newer
, you may need to manually adjust your Impl files (which are not updated automatically) to replaceWideString
withUnicodeString
, to match regenerated Intf units.