Setting up .NET synchronization logic

When you implement synchronization scripts in .NET, you must tell MobiLink where to find the packages, classes, and methods that are contained in your assemblies.

 Implement synchronization scripts in .NET
  1. Create your own class or classes. Write a method for each required synchronization event. These methods must be public.

    For more information about methods, see Methods.

    Each class with non-static methods should have a public constructor. The MobiLink server automatically instantiates each class the first time a method in that class is called for a connection.

    See Constructors.

  2. Create one or more assemblies. While compiling, reference iAnywhere.MobiLink.Script.dll, which contains a repository of MobiLink server API classes to use in your own .NET methods. iAnywhere.MobiLink.Script.dll is located in %SQLANY12%\Assembly\V2.

    You can compile your class on the command line, or using Visual Studio or another .NET development environment.

    See MobiLink server .NET API reference.

  3. Compile your project.

    For example, compile from Visual Studio as follows:

    1. On the VS.NET Project menu, click Add Existing Item.

    2. Locate iAnywhere.MobiLink.Script.dll.

      In the Open list, click Link File.

      Note

      For Visual Studio, always use the Link File method. Do not use the Add Reference option to reference iAnywhere.MobiLink.Script.dll. The Add Reference option duplicates iAnywhere.MobiLink.Script.dll in the same physical directory as your class assembly, creating problems for the MobiLink server.

    3. Use the Build menu to build your assembly.

    You can also compile from the command line, as follows:

    Replace dll-path with the path to iAnywhere.MobiLink.Script.dll. for example, in C#:

    csc /out:dll-pathout.dll /target:library /reference:dll-pathiAnywhere.MobiLink.Script.dll sync_v1.cs
  4. In the MobiLink system tables in your consolidated database, specify the name of the package, class, and method to call for each synchronization script. No more than one class is permitted per script version.

    For example, you can add this information to the MobiLink system tables using the ml_add_dnet_connection_script stored procedure or the ml_add_dnet_table_script stored procedure. The following SQL statement, when run in a SQL Anywhere database, specifies that myNamespace.myClass.myMethod should be run whenever the authenticate_user connection-level event occurs.

    CALL ml_add_dnet_connection_script( 
        'version1',
        'authenticate_user', 
        'myNamespace.myClass.myMethod'
    )
    Note

    The fully qualified method name is case sensitive.

    As a result of this procedure call, the script_language column of the ml_script system table contains the word dnet. The script column contains the qualified name of a public .NET method.

    See ml_add_dnet_connection_script system procedure and ml_add_dnet_table_script system procedure.

    You can also add this information using Sybase Central.

    See Adding and deleting scripts.

  5. Instruct the MobiLink server to load assemblies and start the CLR. You tell MobiLink where to locate these assemblies using options in the mlsrv12 command line. There are two options to choose from:

    • Use -sl dnet ( -MLAutoLoadPath )   This sets the given path to the application base directory and loads all the private assemblies within it. This is usually the preferred option. For example, to load all assemblies located in dll-path, enter:
      mlsrv12 -c "DSN=consolidated1" -sl dnet(-MLAutoLoadPath=dll-path)

      When you use the -MLAutoLoadPath option you cannot specify a domain when entering the fully qualified method name for the event script.

      See .NET assembly loading and -sl dnet mlsrv12 option.

    • Use -sl dnet ( -MLDomConfigFile )   This option requires a configuration file that contains domain and assembly settings. You should use this option when you have shared assemblies, when you don't want to load all the assemblies in a directory, or when for some other reason you need to use a configuration file.

      For more information about loading shared assemblies, see .NET assembly loading.

      For more information about the mlsrv12 option -sl dnet, see -sl dnet mlsrv12 option.

      Note

      You can use the -MLAutoLoadPath option or the -MLDomConfigFile option, but not both.