Posted: Feb 12, 2009 @ 08:03 PM             Msg. 1 of 4

Hi all,

With the pending v3.3 update we are struggling to get our software to work with the Production server (v3.2 for a couple more weeks) and the SIM server (v3.3 starting tomorrow evening) for our end users.

Our app is written in C++ / MFC developed in Visual Studio 2005. Up until now we had been pulling in the library definition via #import "libid:e4b286b1-1f04-4cf7-1978-151d72e9b724". We are considering changing that to point to one or another tdl file based on the build target, but even if we get that working, OECAPICOM::APIHelper which we use to CoCreateInstance has the same UUID between the two API versions. Additionally OECAPICOM.dll has had it's version (1.0.0.0) stay the same even though the file size changed between 3.2 and 3.3.

We have grudgingly accepted that we must build two executables, but we are struggling to figure out how have two versions of the COM API registered on our system.

Posted: Feb 13, 2009 @ 12:26 PM             Msg. 2 of 4

We have a single application that until tonight has alllowed our users to switch between SIM and Production logins by changing a radio button group before clicking login. We deploy the software by installing it and the OEC dll's into our program's directory and having the installer register it.

We are now trying to figure out a way to have one or two pieces of software installed that work with the new and old API versions.

If we install the latest OEC API COM, it registers the typelib and all the COM CLSID's to point to it's directory. Building our application at this point creates an executable that can log into the API server and not the SIM or Production servers. If we then run an older copy of our program that was built against the previous typelib, it crashes with a memory error listed below.

If we move the DLL files out of the OEC API COM folder and again attempt to run our older application, it runs fine. If we copy the new DLL's to the folder that our new build is sitting in, it also runs. We have tried tons of other combinations and this is the only one that we have found to work: have the CLSID's registered and pointing to a location that no longer has the OEC API.DLL and OECAPICOM.dll, and put the right versions of these DLL's in the same folders as the application. Nothing else worked. Not even <app_name.exe>.local.

(http://msdn.microsoft.com/en-us/library/aa375142.aspx

Is it possible to have two applications, one using v3.2 and one using v3.3, with properly installed and registered OEC COM interfaces without using the kludge listed above?

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.RuntimeType.ForwardCallToInvokeMember(String memberName, BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData& msgData)
at OECAPICOM._DOECClientEventInterface.OnError(Exception ex)
at OECAPICOM.OECClient.HandleAndFireOnError(Exception ex)
at OEC.API.OECClient.FireOnError(Exception ex)
at OEC.API.Core.LoadClient(InitializationResponse initdata)
at OEC.API.Core.ProcessResponse(Object response)
at OEC.API.Core.ReadConnection()


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
OECAPICOM
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Program%20Files/Gecko%20Software/Track%20'n%20Trade%20Live/OECAPICOM.DLL
----------------------------------------
API
Assembly Version: 3.2.0.0
Win32 Version: 3.2.0.0
CodeBase: file:///C:/Program%20Files/Gecko%20Software/Track%20'n%20Trade%20Live/API.DLL
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

Posted: May 31, 2013 @ 08:00 PM             Msg. 3 of 4

The same unique id between minor version updates and no update to the version number (3.5.0.0) for all dlls continues to hamper our development using the OEC API.

The reason why it would be a great idea to perform (industry standard) version number updates (even for "minor" updates) and change the uuid for each new version is because:
- it would allow us to test these dlls side by side
- provide a way for our users to switch between old and new dlls if the new api somehow broke existing functionality in a way that had escaped our testing.

We again request version # updates and new uuids for each API release.

Thanks,

---

CHW
Edited by CWeber984 on May 31, 2013 at 20:02:10

Posted: Mar 19, 2014 @ 09:55 PM             Msg. 4 of 4

We still hold this idea that OECAPICOM.dll would get regular version # updates on rolled out code changes at the top of our wish list. Has there been any discussion of that on your side?

Thanks,

---

CHW