Thanks for dependant assembles feature was going to ask about that.

Ugh, you have no idea how frustrating it was to implement. So, .Net has a appdomain, which they feel should be limited to the current file folder for security. Why? I have no idea - but Microsoft feels that any other installed software must be a virus... i guess!

So when you load an assembly, the refelection method doesn't look in the loaded assembly's folder for any of it's dependencies. In fact, it only looks in the calling application's domain (which is the ARC installation folder).

This isn't a problem when loading an unmanaged DLL with interop - because at that point, .Net doesn't seem to care what folder it is in, long as the path is specified.

So to get around this, there is an event which the current AppDomain will raise when it is resolving assemblies.

void method() {
        AppDomain currentDomain = AppDomain.CurrentDomain;
        currentDomain.AssemblyResolve += currentDomain_AssemblyResolve;

       // load the main  plugin assembly

        currentDomain.AssemblyResolve -= currentDomain_AssemblyResolve;
}

    System.Reflection.Assembly currentDomain_AssemblyResolve(object sender, ResolveEventArgs args) {
 // Do something here to detect, find, load and return the assembly
}

So the idea is before loading the plugin, assign an event to resolve assemblies. Then load the assembly, resolve the dependencies, and finally un-assign the event so it doesn't happen again.

Took all evening to figure out :). I was trying to make the Oculus Rift plugin, and the dependencies just wouldn't load!

*Note: I just updated this from 2015.12.04.00 to 2015.12.05.00 because my code was being a little selfish. By selfish, i mean the only time ez_builder attempted to resolve assemblies was during the loading/initialization of a plugin. I did not take into consideration libraries being loaded after initialization, for example on the click of a button.

So now the search for missing assemblies is global. However, it will only search for the assembly in the plugin root folder still. An error will be displayed otherwise.

For example, i should have not been removing the -= the assembly resolve event after the plugin has been loaded. Now it is moved into a single global init when ARC first loads, to ensure resolving failed dependencies searches for the required assembly in your root plugin folder.

I was using the c# svg graphics library .Dll and I copied it into the ARC folder where all the ARC dlls where that seemed to resolve the issue. I knew there would be trouble with the plug in installation issues amongst the community so I ended up manually drawing the shaped using gdi+. With your hard work the community should be able to use any dlls now. Awesome.

I am using custom fonts for the plugin and they seems to be okay residing/loading in the plugin directory.

Nice!

If you do need to read files from the plugin folder, here's how you can get the path to the plugin root folder, by combing the guid and windows environment settings for the public path.

This code example combines the user's public ARC skill plugin folder, that comes from the windows environment settings, the guid and the filename.

using System.IO;

string OculusRift_Fx_File = EZ_Builder.Common.CombinePath(
        EZ_Builder.Constants.PLUGINS_FOLDER,
        _cf._pluginGUID,
        "OculusRift.fx");

if (!File.Exists(OculusRift_Fx_File)) {

    MessageBox.Show("Unable to find the OculusRift.fx file that should have installed with this plugin. Cancelling");

    return;
}

So if you have a fonts sub folder in the plugin folder, or some sub in the plugin folder, you can do this...

      string FontFile = EZ_Builder.Common.CombinePath(
        EZ_Builder.Constants.PLUGINS_FOLDER,
        _cf._pluginGUID,
        "Fonts",
        "SomeFont.ttf");

Or to read the files from a sub folder of the plug directory...

      using System.IO;

      string fontFolder = EZ_Builder.Common.CombinePath(
        EZ_Builder.Constants.PLUGINS_FOLDER,
        _cf._pluginGUID,
        "Fonts");

      foreach (string fontFile in Directory.GetFiles(fontFolder)) {

            Console.WriteLine("File: {0}", fontFile);
      }