Building Apps with Dimensions Components

[James Corriveau]

Building custom applications using Dimensions components is great. However, you need to be aware of a few things...

1) You are NOT allowed to redistribute Dimensions components with your applications. This means your application is dependent on the version that is installed on the client's machine.
2) Dimensions components are "strong named" (installed in the GAC) which means your application is hard-coded to use the component versions that you used when you compiled your application.

Long ago, we had to deal with DLL Hell. We could just instantiate MDMLib and not worry about the version. This was good and bad (mostly bad). With strong named components, you must specify the version you want to instantiate.

For example, let's say you build an application which has a reference to MDMLib.dll and you compiled your application on Dimensions 4.5. On 4.5, the component version for MDMLib.dll is 2.119.2.0.
This means your application will work on any Dimensions version as long as MDMLib.dll still has a version of 2.119.2.0. The MDMLib.dll version changed on Dimensions 5.6 so your application will fail.

There are two solutions to the problem:

1) Re-compile your application on the new version of Dimensions. This is a pain because then you have multiple install kits (one for each version of Dimensions you want to support).
2) Use the application configuration file to redirect component versions. This is what I've done in my applications. It does NOT require re-compiling your application. It just requires a modification to the application configuration file.

For #2...
In Visual Studio, add an Application Configuration File to your project. It will (by default) be called "app.config". I've made the following change to the configuration file which will redirect version 2.119.2.0 to 2.122.2.0 for MDMLib.dll. This will make the application work on 5.6 without having to recompile. You can do this for multiple .dll's if you need to.

Code: Select all

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

      <dependentAssembly>
        <assemblyIdentity name="MDMLib" culture="neutral" publicKeyToken="8174058f62942e31"/>
        <bindingRedirect oldVersion="2.119.2.0" newVersion="2.122.2.0"/>
      </dependentAssembly>


    </assemblyBinding>

  </runtime>
</configuration>


When you compile and install your application, the "app.config" file will be automatically renamed to "<application_name>.exe.config". You can make changes to this file at any time without having to recompile.

Best,
Jamey

[klaus]

Hi Jamey,
thanks a lot for sharing this information. It clarifies really a lot for me. I'm just wondering, how flexible this may be used. I mean, is it possible to create a list of redirections for all those versions that may be installed on the target system. I.e.: If I compile the program using Dimensions 5.5 and would like to be able to support versions 4.5, 5.0 and 5.6 can I have three redirections in the config file or do I need to have three different config files on stock for those three versions. In the latter case the installation program may have a kind of "intelligence" to find out about the installed version on the target system and then add the correct version of the config file?! I'm not really familiar with the creation of "intelligent" installation scripts which may even differ for the different tools being around for this task.
Thanks,
Klaus

[James Corriveau]

The "oldVersion" parameter can be a range, but the "newVersion" parameter can only be one specific version. So, you can't really have one super-duper config file that works in every situation. It's unfortunate, but I haven't found any better solution.

Yes, you can certainly create an intelligent installation script that builds the configuation file. I've been reading up on this lately and it can be done. But I don't have any useful examples for you.

[swinstanley]

There are a couple of other ways you could go in order to attempt to get some kind of version neutrality, I'm not saying any are better than what Jamey is suggesting which is "The Right Way"

What I'll say first is that its COM interops such as MDMLib and TOMLib which provoke the most problems here, what that means is they aren't "the real thing" they are just .Net wrappers of COM type libraries. Not that many of the back end PASW Data Collection (Dimensions) components are actually .Net but there are some exceptions. The handy hint is that if you are referencing something that ends with Lib its probably an interop. So MDMLib.dll is just a generated component that tells .Net how to call MDM2.dll etc...

The thing with interops is that they are Generated libraries there's no programming in them, that means you can actually generate your own without really doing anything remember I am not suggesting you do this, just saying its an option. For example if in your .Net project you Add a reference from the COM tab to PASW Data Collection MDM2 Library it will make its own MDMLib.dll that you can ship therefore you have control over its version. The gotcha here is that if something actually does change in the real MDM2.dll from the point of view of its COM interfaces or if SPSS breaks some rules of COM then you can get runtime errors if there's a version issue. In short, its safer to call the version of the interop that SPSS makes or at least one that was generated for a specific version of Data Collection.

The other way you can do it, is really for the type of people who enjoy Pain which means using .Net's reflection API's to manually Load Assemblies and Invoke methods... you would only want to do this if you wanted to call only 1-2 methods but it does at least mean your .Net application can run without having any references at all to SPSS code.. This is kind of like doing the leg work that MRScript/VBScript does for you and its called "late binding". I won't even start to give an example on this however I won't say that I haven't ever done it. There was this one time where the only single call I had to make to Dimensions was IAgent2.Login and I wanted to be version proof so I did it and I've never had to recompile that app which as far as I know is still in use 4 dimensions version later

[klaus]

Just to let you know: I followed Jamey's advise and it worked for me like a dream. I now created two different config files, one for DImensions 5.5 and one for PASW DC 5.6. The only library I had to deal with was the MDM2Lib which has changed the version number between those two versions. My setup script is now figuring out wheter or not PASW DC 5.6 MDM2Lib is available on the system and then takes the apropriate config file to be installed on the system. I haven't yet checked about Dimensions 4.5 as some of our customers are still working on this version. But I am confident to be able to handle that version as well quite easily.

I have just one concern, as I am not yet a real "crack" about .NET programming: I cannot imagine that this work around is really fail safe. I expect to run into trouble with this construction as soon as there are changes in those routines a program is using. If any part a program is using of the library does change the way it is called, the return values or what ever I would expect to run into trouble with my application. Is there any advise about how this can be handled? Maybe in such a case the program itself needs to determine the version of the software it is running on and then use the objects accordingly.

I probably need to read a lot more about .NET programming and need to understand more about the background of the whole story. I am wondering why I can use the "late binding" easily for MS Office but not for Dimensions/PASW DC? Obviously there are serious differences in the way the object from these two systems are presented to the programmer and the system. Just to have it mentioned: the program I was working on us using MS Excel as well and runs really happily on Office 2003 and Office 2007. This is quite easily done following the according advises from Microsoft for the late binding, i.e. I do not create objects on the "Dim" statement as an office object but only as a neutral object. Only in the moment when this object is used as e.g. Excel Object I create this object accordingly. This is only done when the program is running and the system then is taking the office library that is available on the system. I would be very interested to learn why this kind of thing is not possible with Dimensions objects (I tried this without any success!). Maybe the reason is what Sam described as the .NET components of Dimensions just being wrappers for COM objects. I don't know.

But maybe this thread can help others to find their way to writing own applications for Dimensions/PASW DC.
Cheers,
Klaus