E3 Type library compatibility

Hi!

I am developing an application which interact with E3 projects. I am using Visual Studio 2017 .NET 4.5 and C#.

In my system I have E3 2018 19.03 and so I added to the project a reference to the corresponding Type Library (see below the screenshot)

The problem is that when I try to connect to the application via COM using the command:

e3App = Activator.CreateInstance(Type.GetTypeFromProgID("CT.Application")) as IApplicationInterface;

The object e3App is null and I get an error message if the PC target where I setup the application has E3 2017 (18.XX)

What is the right approach in order to have an application fully compliant with both version?

Thanks for your support.

 

Best regards

Michele Mura

0

Comments

12 comments
  • I've not figured this one out. I have E3 2016, 2017 and 2018.

    If I have to go back to an older scripting project with E3 2016, then I will re-register the COM.

    In this case, I close all E3 sessions and launch a new one using E3 2016. If I develop for E3 2018, then I do the same.

    It is a minor inconvenience...

    ... but it can be embarrassing when performing a live demo for a customer and the script fails because  the wrong COM is registered!!!

    There's a section that tersely covers this in the E3 COM Help called "Registration of COM Classes when Starting E³.series"

     

    0
    Comment actions Permalink
  • Hi Bob,

    I am not sure I was clear enough in my first post. I have understood your reply but I will try to summarize my problem with the first single direct question:

    Is it possibile to create/develop an application (Visual Studio and c#) that works indistinctly if I run its setup on a machine with E3 2017 or on a machine with E3 2018?

    After this answer I will ask a second direct question.

    Thanks again for your support and time.

     

    Best regards

    mm

    0
    Comment actions Permalink
  • You're E3 objects are strongly typed to your E3 Type Library reference.

    In order to be not dependent on the E3 Type Library I would remove it from project and change all E3 declarations to type object. 

    Downside is is no more intellisense. I'm so used to the API that I'm not dependent on intellisense. 

    I haven't tried this but you might try keeping the type library reference for intellisense and create E3 declarations that are strongly typed and those that are object type. When developing then comment out the object declarations. When deploying then comment out the strongly typed declarations. 

    1
    Comment actions Permalink
  • Hi Bob,

    Now I think I am understanding your solution but it is not enough to remove the reference and use object instead of strong types..

    You have to use Reflection to call methods and get properties, right? Something like this: (example taken from Microsoft web site)

    using System;
    using System.Reflection;

    public class MagicClass
    {
    private int magicBaseValue;

    public MagicClass()
    {
    magicBaseValue = 9;
    }

    public int ItsMagic(int preMagic)
    {
    return preMagic * magicBaseValue;
    }
    }

    public class TestMethodInfo
    {
    public static void Main()
    {
    // Get the constructor and create an instance of MagicClass

    Type magicType = Type.GetType("MagicClass");
    ConstructorInfo magicConstructor = magicType.GetConstructor(Type.EmptyTypes);
    object magicClassObject = magicConstructor.Invoke(new object[]{});

    // Get the ItsMagic method and invoke with a parameter value of 100

    MethodInfo magicMethod = magicType.GetMethod("ItsMagic");
    object magicValue = magicMethod.Invoke(magicClassObject, new object[]{100});

    Console.WriteLine("MethodInfo.Invoke() Example\n");
    Console.WriteLine("MagicClass.ItsMagic() returned: {0}", magicValue);
    }
    }

    // The example program gives the following output:
    //
    // MethodInfo.Invoke() Example
    //
    // MagicClass.ItsMagic() returned: 900

    0
    Comment actions Permalink
  • Sorry, not object (that's how I do it in VB.NET)

    Change to dynamic.

     

            static void Main(string[] args)
    {
    dynamic e3App = Activator.CreateInstance(Type.GetTypeFromProgID("CT.Application"));
    e3App.PutMessage("Hello World");
    }
    1
    Comment actions Permalink
  • Ok! So using "dynamic" type is the key to always have a late binding and avoid compile errors..

    I like your solution, quite a lot! 

    But what happens if the target machine where you setup the application has two E3 versions? (let's say 2017 and 2018). Can you control which version "open" when you invoke .CreateInstance()?

    I think you only have to use E3 methods that work in both versions in the same way (same parameters, same return values, etc...)

    Thanks again for your advices.

     

    Best regards

    mm

    0
    Comment actions Permalink
  • That was what I alluded to in my original response. I haven't found a way to specifically target an E3 COM... but then I haven't really tried. For me its not a pressing matter. More of an inconvenience when I run into these issues which might happen once in couple months.

    What I do is re-register the COM by starting the desired version of E3 using a couple special purpose Windows shortcuts on my desktop where I set the /register flag. I also have short-cuts to unregister (I'm superstitious). See image below. I have short-cuts for 2016 and 2018 for register/unregister.

    This is something another E3 developer showed me.

    1
    Comment actions Permalink
  • OK! So one of the possibile solution is not a "developer" solution but something like a configuration of the target machine itself.

    Example: if the target machine has two E3 installed, unregister 2016 and then register 2018 in order to be sure to use COM interface 2018 (and develop the source code by using dynamic type without linking to a specific type library...)

    Very, very nice..

    Thanks a lot again!

     

    mm

    0
    Comment actions Permalink
  • I think it would be preferred that end-users did not have more than one version of E3 installed. There reason is that there is no backward compatibility of drawings saved by E3 2018 to E3 2016.

    If someone accidentally opens a legacy drawing created in E3 2016 while using E3 2018, then E3 will migrate it forward. If drawing is saved, then end-users will not be able to open it in E3 2016.

     

    1
    Comment actions Permalink
  • Yes! I already did know this issue and I completely agree with you. Just one version installed on a single machine.

    Thanks anyway for remembering it to everybody.

    0
    Comment actions Permalink
  • You can watch the sources of my E3series COM wrapper on github:

    https://github.com/alex-buraykin/E3Series.Wrapper

     

    It works in cases then multiple instances of E3series is installed

    0
    Comment actions Permalink
  • Thanks Alex! I will take some time to take a look also at your source code.

     

    mm

    0
    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post