Unable to get IiLogicAutomation interface.

[Will.Ehrendreich]

I am attempting to get the IiLogicAutomation from an Addin im writing.

i get it like this:

  public static class iLogicUtilities
  {
    private static string iLogicAddinGuid = "{3BDD8D79-2179-4B11-8A5A-257B1C0263AC}";

    private static IiLogicAutomation _iLogicAutomation = null;

    public static IiLogicAutomation GetiLogicAutomation(Application app)
    {
      var addin =app.ApplicationAddIns.ItemById[(iLogicAddinGuid)];
      try
      {
        if (_iLogicAutomation is null){
          _iLogicAutomation = (IiLogicAutomation)addin.Automation;}
        return _iLogicAutomation;
      }
      catch
      {
        return (IiLogicAutomation)addin.Automation;
      }
    }
  }

unfortunately i get

Unable to cast COM object of type 'System.__ComObject' to interface type 'Autodesk.iLogic.Interfaces.IiLogicAutomation'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{91DF0977-6AF7-305B-A571-67AF76D7A4C9}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).

Does anyone have any idea how i can fix this?

[basautomationservices]

The type/interface IiLogicAutomation is not correct. It should be 'Autodesk.iLogic.Automation.iLogicAutomation'

[Will.Ehrendreich]

I found it in Autodesk.ilogic.interfaces. I thought using the interfaces would be perfectly reasonable, but if it isn't supposed to be used that's totally fine, my guess is that there is a COM issue. I am just now getting into understanding what COM actually is and does, which is to say, I have no idea about the particulars of what's needed or how it actually functions. COM seems to make discoverability incredibly difficult, and it's really not clear what is going wrong when it does go wrong.

Trying it with casting to iLogicAutomation results in this error

{"Unable to cast COM object of type 'System.__ComObject' to class type 'Autodesk.iLogic.Automation.iLogicAutomation'. Instances of types that represent COM components cannot be cast to types that do not represent COM components; however they can be cast to interfaces as long as the underlying COM component supports QueryInterface calls for the IID of the interface."}

For reference this is how i changed my code to give me that exception.

  public static class iLogicUtilities
  {
    private static string iLogicAddinGuid = "{3BDD8D79-2179-4B11-8A5A-257B1C0263AC}";

    private static iLogicAutomation _iLogicAutomation = null;
    public static iLogicAutomation GetiLogicAutomation(Application app)
    {
      var addin =app.ApplicationAddIns.ItemById[(iLogicAddinGuid)];
      try
      {
        if (_iLogicAutomation is null){
          _iLogicAutomation = (iLogicAutomation)addin.Automation;}
        return _iLogicAutomation;
      }
      catch
      {
        return (iLogicAutomation)addin.Automation;
      }
    }
  }

I wonder if @adam.nagy or @AlexFielder have run into this before?

[adam.nagy]

You have to reference 2 dll's:
https://adndevblog.typepad.com/manufacturing/2013/04/call-ilogic-from-net.html 

[Will.Ehrendreich]

Thank you for your help @basautomationservices  and @adam.nagy ,

Sorry i just didn't include that in the post, but yes I've got refs to both of those, as well as Inventor.

My assembly references are all from the bin folder of my current inventor install, and I'm not embedding interop types for anything.

[AlexFielder]

The only obvious difference I can see between your code and how I do it is this:

public static IiLogicAutomation GetiLogicAutomation(Inventor.Application app)

Wherein I call Inventor.Application instead of just Application as in your case.

Why that makes any difference whatsoever I have no idea.

[Will.Ehrendreich]

Thanks @AlexFielder ,

It is the Application from the Inventor namespace, It's just not using the fully qualified Inventor.Application because I've got it in my "usings" section, which in csharp is just the same as the Imports in vb.

I SO Wish it was just because I was getting the wrong Application interface, haha. It's probably something finnicky like that that's going wrong though, for real. It always seems to be something small that stops the whole train.

[basautomationservices · Accepted solution]

Hi will,  

are you sure you're running this from an add-in? I'm getting the same results as you when I run this from an external application, but from an add-in its working fine. 

[Will.Ehrendreich]

WAAAAAAIIIIT a minute.. you're right..  @basautomationservices ,

I'm running it from Fsharp Interactive.. (I'm actually developing in fsharp and only dipping into csharp territory when it's absolutely necessary ) it's the REPL and, yeah, technically it's a separate exe outside of the memory space of inventor, it's just calling the addin code.

OK, so how is anyone who's writing an outside exe supposed to get this interface? There has to be some way, right?

Because I'm not gonna lie, up until I've tried to do this, using the incredibly fast iteration loop of a REPL has been an absolute godsend. It's seriously MANY times faster to develop this way, because I don't have to wait for long builds constantly, don't have to wait for Inventor to spin up which is.. well it's painfully slow. lol.

Is there anyway to trick inventor into believing the FSI process is actually part of the addin? Using MEF or something? Do I have to inject a REPL into inventor? I've already done some of that, using this:

https://github.com/oriches/Simple.Wpf.FSharp.Repl , though I'm not sure if it will work there either, if it also spins up a separate exe... which I'm pretty sure it would, how else would it do that?

[basautomationservices]

Yes that should be the problem.

I don't know anything about F# but I always use solutions with some class libraries, of which one add-in, one or more 'functionality' dll's and one forms app in which I can test the commands in inventor, without having to restart inventor all the time. (theres also edit & continue, but doesn't always work for me.)

I don't know if there's a way to access it from the outside, I hope someone else can help you with this. My end products are mostly add-ins because I like the inventor UI and it feels more natural to have the commands in the UI than in a separate exe. 

What I do is develop everything (as much as possible) in the functionality libraries and the forms app, when it's required I change the startup project, and start-stop debug in inventor to try things that I can't try from the outside, or when it gets to slow. The slowness is usually not that much of a problem if you break your project up into pieces enough. 

[adam.nagy · Accepted solution]

It seems you just have to use late-binding: Object in VB.NET / dynamic in C#

That's what one of the samples I got from a colleague that's running out-of-process is doing as well:
https://github.com/ADN-DevTech/iLogicRuleExporter 

You could develop the code using the appropriate iLogic interfaces in order to get intelli-sense, then switch the types to dynamic. 

Note: in C# the properties look different than what you'll need with dynamic: e.g. it offers get_Rules(), but you'll need Rules()

[Will.Ehrendreich]

Oh my goodness @basautomationservices , FSharp is incredible.

I didn't know anything about it till recently, and while it's a bit of a learning curve at first, it is SO much nicer a language than C# or VB.

Just having proper type inference alone is worth the switch, it automatically figures out what you mean like.. 90% of the time when you're referring to a normal base class library type or a function you've written being passed in as an argument. that's pretty nice, because when you inevitably have to change a function, it usually just automatically switches to the new types, and everything works, where as in C# or VB you'd have to go through EVERYWHERE that that thing affects and manually change the function signature.. which.. is a pain..

Aside from that not falling into Object Oriented hell is really wonderful. GONE are the IMonkeyAroundFactoryServiceFactoryBuilder's and the endless configuring of IOC containers, or the shared mutable state of everything so you never know when some piece of data is just going to be ripped out from under you, or the GAZILLION bitty class files that you need complicated folder structures just to keep straight. Idiomatic fsharp (which is not perfectly doable when dealing with Inventor and COM, of course, but still MUCH better.) is nothing but immutable data, and the functions that operate on them. It's Glorious, and you don't need to have the entire code base memorized to figure out what's happening. It's mostly public and globally scoped, but since it's immutable, you're perfectly fine to operate on that data, because you don't get into trouble with threads or anything. AND, because it's another DotNet language, all the libraries and speed and everything else you want from using DotNet is right there, open for you to use as you please, so incrementally changing small parts of existing solutions over to using the functional style is REALLY easy to do.

I have only been doing it for a few months, but I am floored with how much more productive I am. It's really worth checking out.

Take the Red pill, and see how deep the Rabbit Hole goes. (https://fsharpforfunandprofit.com/csharp/... 

ok.. FSharp fanboying over..

[Will.Ehrendreich]

it indeed looks like that works, though i sacrifice all typesafety to do it.

perhaps there's a good way to throw a wrapper around it after it successfully binds. 

thanks~!