As mentioned recently I upgraded my Universe and Unidata Personal Editions to the latest releases. Actually I just did trial runs earlier in the week but today I did the real thing. After upgrading UniAdmin, Uni SDK, Universe and Unidata, I checked telnet connectivity, then decided to check my mv.NET connectivity. I thought I’d share the painless experience.
I have to keep remembering that we only get two licenses with UVPE and UDPE. Same goes for some other MV DBMS trialware or freeware for developers. Open a telnet window and that’s one license. Open a Server Console Window to enable an application account for use with mv.NET, that’s the second license. Try to connect to the newly enabled account… bewm. We need to log out of one of the others first. So for any of you developers installing this all on one system, just remember that you do get two session licenses with mv.NET but those won’t help if you run out of DBMS licenses.
There is a lot of confusion about which UniObjects DLLs will work with mv.NET. I’ll clarify that here as well as explain how to get mv.NET working with UniObjects (COM) and UniObjects.NET.
If you are using a UniObjects connection then any release "should" work, provided that it’s binary compatible with the release used by BlueFinity during their compilation and testing. The specific release they used for mv.NET v3.5 was UniObjects v184.108.40.20696. So, for example, if you originally start using mv.NET with UniObjects v220.127.116.1196 and then you upgrade to v18.104.22.16876, it "should" work because these releases are binary compatible. There were a few transition builds of UniObjects, so if you look at the properties of your UniObjects.DLL file you may see some number between 7196 and 7276. If you have a number outside of that range then some functions may not work correctly, or you may not be able to connect at all.
So, use regsvr32 to register the latest DLL which you should find here: \IBM\UniDK\redist\i386\register.
For UniObjects.NET, mv.NET was built against a specific versioned DLL. As long as this DLL is on your system, you can use UO.NET as the connectivity pipe rather than the COM version of UO. This is very helpful if you have some software that requires UO build 7276 but you still want to use mv.NET which was built with the older build.
I’m tempted to explain how DLLs are referenced in COM and .NET, DLL Hell, and other factors, but for now I’d just like to make sure everyone knows how to just get things working. If anyone is interested in these other things, please leave a comment, otherwise I’ll assume everyone reading this understands (in part anyway) why there is a transition from COM to .NET.
With .NET, DLLs are versioned and registered in the Global Assembly Cache (GAC). Multiple DLLs with the same name and different versions can co-exist peacefully in the GAC, and software that relies on version X is not affected when version Y is installed. So, all you need is the file UODOTNET.DLL, version 22.214.171.12496. Unless you’re using this for other purposes, on the (middle-tier) server that is running the session manager service, copy this to the path:
If you need that assembly for other purposes then put it somewhere more centrally located on your server. See a note several paragraphs below for a suggestion.
As to where you get that assembly: it’s much easier to load a single DLL than all 400-500MB of an old release of the UniSDK. We got permission a couple years ago to provide the DLL on our FTP site for our clients who agree to the terms and install the latest UniSDK. Yes, the older client communicates with the newer server components, they didn’t change that interface between point-releases. If you did not purchase mv.NET from Nebula R&D, this is one of the many value-add services that we provide our clients, and all I can do is recommend that you contact your support provider(s) to obtain the DLL from them.
Open a DOS (cmd) window and go to that directory. There is a program there called gacutil, which is the .NET equivalent of regsvr32 and registers a DLL for system-wide use. (Gacutil comes with the .NET Framework and is widely distributed, it’s not specific to mv.NET.) Use the following command:
gacutil.exe -i uodotnet.dll /nologo
You should see the response:
Assembly successfully added to the cache
Now, just in case, restart the session manager service from the Services control panel or from the mv.NET Session Monitor on the middle-tier server.
When you set a Server Profile to use UniObjects.NET, the connection should work.
If you need the latest version of UniObjects.NET, you can register that too. Just cd to \IBM\UniDK\uonet\bin (or wherever you installed it), and you should find the latest version of UODOTNET. Copy gacutil to that directory and use the exact same command as above.
To see both versions of UO.NET in the GAC, use:
gacutil -l uodotnet
(Note the header info which was not visible when we used the "/nologo" switch.) The output will show one or more assemblies that will be used, depending on the code that calls them.
As mentioned above, if you need more than one version of the UO.NET assembly registered at the same time, you might want to put them close together. I would recommend the following:
– Copy the directory \IBM\UniDK\uodotnet\bin to it’s build-specific counterpart, \IBM\UniDK\uodotnet\bin\7276.
– Create another directory, \IBM\UniDK\uodotnet\bin\7196.
– Copy the UODOTNET.dll files to their appropriate directories.
– Unregister prior registrations using "gacutil -u uodotnet".
– Use gacutil as indicated above to re-register both assemblies.
If you upgrade to something like (ficticious) 126.96.36.19909, you can safely uninstall the entire UniSDK and it "should not" remove the directories you’ve created manually. Reinstalling "should" re-create the same directory structures, with a new UODOTNET.dll under bin. You can create a new directory there, bin\7309, copy the assembly there, gacutil it, and your system will now run all three versions without a hiccup.
As always, I hope this was helpful. If you have follow-up questions you can post them here. If you have a more involved question, please post it to our forum. For official product support, please call or email.