mv.NET CRDK or SRDK?

I recently assisted a client with an upgrade of mv.NET from v3.2 to v4.0. This is one of the value-add services provided to our clients who purchase mv.NET from us. A minor code change was required.

This site doesn’t run the mv.NET services or DBMS on the web server. The web server is in a DMZ, separated from their intranet by a firewall.

We did have the mv.NET SRDK installed on this system, with services turned off, and ConfigurationPath file pointing to the services system, also with the SRDK installed. At upgrade time I decided that we should be using the CRDK since it didn’t have the services, just the base libraries required to call services. So we uninstalled the SRDK, then installed the CRDK … and it wouldn’t work.

A recap of the various mv.NET install packages:

• The SRDK is the Server Runtime Deployment Kit, and it contains the services, config files, and data manager.
• The CID is the Client Interface Developer package. The CID includes everything in the SRDK, plus documentation, and tools for Visual Studio. Many of us just install the CID on a server and select the option to avoid installing docs or VS components. In hind sight I thinnk it’s better to install the SRDK because upgrades are easier and there’s no confusion when we look at the Add/Remove Programs panel.
• The CRDK is the Client Runtime Deployment Kit, which only contains libraries, no docs or services. The install process loads the assemblies to the GAC. This is the package to use on PCs running thick clients, or web servers that only proxy requests to another server running the mv.NET services.

The reason the CRDK didn’t work where the SRDK did was that the CRDK doesn’t have configuration files, nor a ConfigurationPath file like the older SRDK. In code deployed to a system with the CRDK, the code must identify not only the profile(s) that it will be using, but the server that has the profiles and which is running the services.

To backtrack a bit:

• Your configuration files are hosted in the middle tier.
• That system also runs the Session Manager service.
• Clients connect to the Session Manager service which then provides local configuration data. Clients use this data to make a connection to a desired DBMS.

In the absence of local configuration data, we used to have a ConfigurationPath file that pointed to something like //servername/path/mv.NET where it was expected that a Configuration directory would be found.

In the absence of that ConfigurationPath file, code could do this:

mvEnvironment env = new mvEnvironment( "path/here" );
mvAccount account = env.Login("profile.name");

Now a preferred method would be to do this:

mvAccount account =
   new mvAccount("profile.name","server:port");

Note that we don’t need mvEnvironment for this anymore, though mvEnvironment is still useful for other purposes. The server:port is the address of the Session Manager service – the server where you would typically use the Data Manager for configuring server profiles and account profiles. The port is typically 10013.

If your middle-tier server is also the web server then the local Configuration data will be used. Otherwise you need to tell clients where to find the services and configuration files.

So a minor modification to the client app was required for this upgrade. The Login Profile was already stored in their web.config file, and the data was pulled in something like this:

account= new mvAccount(
  Configuration.Settings["LoginProfile"]);

The mod was to add a SessionManager key to the web.config and modify the account instantiation lines:

account= new mvAccount(
  Configuration.Settings["LoginProfile"],
  Configuration.Settings["SessionManager"]
);

In this app there were a few of those lines to be changed and the task was accomplished in a few minutes. In other apps there may be many more of these lines. I recommend if you do have several initializers or .Login() calls, put them all into a class somewhere, perhaps a static/shared class, and get all of your code to call the single reference. It would look something like this:

public static class DAL {
  public static mvAccount Login() {
    try {
     return new mvAccount( GetProfile(), GetServer() );
    } catch { return null; } 
  }
}

Then call it as:

mvAccount account = DAL.Login();

I recommend that the right package be installed on each tier in an mv.NET topology. If you suspect this will be a problem or if code changes seem to be required, please let me know. In any case, I hope this information proves helpful to anyone trying to understand how the connectivity works. Thanks go to BlueFinity Support for notes provided about exactly how the process has changed from v3 to v4 so that we could work out how to approach this.