topic Re: Odd .net plugin behaviour in Maya Programming Forum

Odd .net plugin behaviour

Anonymous — Fri, 13 Jul 2018 16:25:52 GMT

Hey all,

We've created a .net (C#) plugin linked against the 2016 version of the Maya SDK (openmayacs.dll).

We've experienced the following:

on some machines with Maya 2016, 2017 and 2018, the plugin with load AND RUN on all versions of Maya.
on other machines, the plugin will not load on the appropriate version of Maya, with the following error:

// Error: file: C:/AW/Maya2016/scripts/others/pluginWin.mel line 781: Invoking ExecuteInDefaultAppDomain() failed. //
# Error: pymel : Failed to get controlCommand list from ProjectA.PluginA #
# Error: pymel : Failed to get modelEditorCommand list from ProjectA.PluginA #
# Error: pymel : Failed to get command list from ProjectA.PluginA #
# Error: pymel : Failed to get constraintCommand list from ProjectA.PluginA #
# Error: pymel.core : Failed to get depend nodes list from ProjectA.PluginA #
// Error: file: C:/AW/Maya2016/scripts/others/pluginWin.mel line 781: (ProjectA.PluginA.nll) //

In addition to this, we have also noted that .net plugins linked against newer versions of the MayaSDK will run on older versions of Maya. IE: linking against MayaSDK 2017 (openmayacs.dll) will run on Maya 2016.

My assumptions have been, since we're loading this assembly, it's fairly indifferent as to what version of the SDK you're linked against. But that feels dangerous.

What I'm looking to find out are:

Are my assumptions about loading the assembly correct?
How do I enable maya to spew what's actually the problem when it won't load the assembly. I'm assuming that it's missing a dll of some sort, but all essential dll's have been provide.

Thanks for your responses.

Re: Odd .net plugin behaviour

cheng_xi_li — Mon, 16 Jul 2018 02:09:23 GMT

Hi,

For your questions

1. Are my assumptions about loading the assembly correct?

It is quite dangerous in my opinion. Maya .net sdk is a wrapper for C++ API, if C++ APIs's prototypes are changed it is fairly dangerous to use an old version of .net SDK in a newer version.

2. How do I enable maya to spew what's actually the problem when it won't load the assembly. I'm assuming that it's missing a dll of some sort, but all essential dll's have been provide.

I am afraid you can't. Sorry for the bad news.

From your description, it could be CAS policy. I remember I downloaded a sample from a client several years ago, it violated .NET's CAS policy on my computer. When an app tries to load an assembly from remote location, sometimes it will block that assembly.

You could try to create a maya.exe.config with loadFromRemoteSources inside maya/bin to check if it was the issue.

<configuration>  
   <runtime>  
      <loadFromRemoteSources enabled="true"/>  
   </runtime>  
</configuration>

If a dll is missing, you could try dependency walker(for native) and ILSpy(for .net). Hope it helps.

Yours,

Re: Odd .net plugin behaviour

Anonymous — Mon, 16 Jul 2018 17:14:32 GMT

@cheng_xi_li wrote:
Hi,

For your questions

1. Are my assumptions about loading the assembly correct?

It is quite dangerous in my opinion. Maya .net sdk is a wrapper for C++ API, if C++ APIs's prototypes are changed it is fairly dangerous to use an old version of .net SDK in a newer version.

I should have been clear in my first question - are my assumptions that Maya can load plugins (.net based) compiled for other SDK versions? I was always under the impression that you could not do that. Read: I'm trying to confirm that the behaviour I'm seeing isn't some magic fluke.

I am afraid you can't. Sorry for the bad news.

From your description, it could be CAS policy. I remember I downloaded a sample from a client several years ago, it violated .NET's CAS policy on my computer. When an app tries to load an assembly from remote location, sometimes it will block that assembly.

You could try to create a maya.exe.config with loadFromRemoteSources inside maya/bin to check if it was the issue.
<configuration>  
   <runtime>  
      <loadFromRemoteSources enabled="true"/>  
   </runtime>  
</configuration>  
If a dll is missing, you could try dependency walker(for native) and ILSpy(for .net). Hope it helps.

I'll give that a try and see - If I could reproduce this behaviour on my machine, that would aid in my debugging of this problem. However, just creating a simple 'Hello world' assembly causes this issue - no links to other external dll's outside of openmaya.cs, which I have also included in the plugin distribution.

Re: Odd .net plugin behaviour

Anonymous — Mon, 16 Jul 2018 20:28:40 GMT

Just to update, adding that `maya.exe.config` file totally resolved the issue.

Now I have to sort out why that's happening on the destination machine(s).

Thanks for the info, I don't know how long I would have been digging around to sort that out on my own.