@dan, @brian, @dale, @JohnM, @andy, @curtisw, @Alain, @piac, @DavidRutten
I just committed changes to Mac Rhino source with respect to .NET plug-ins that you guys may be interested in knowing about. Here’s a breakdown on what has changed:
- The xcode build process now passes the correct build configuration for compiling the .NET based source so you will actually get debug flavored assemblies when building a debug version of Mac Rhino and release flavor when building release Mac Rhino.
- The plug-in loader loads .NET plug-ins 2 different ways:
- .NET assemblies with a .rhp extension are loaded (same as before)
- If a directory name ends in .rhp, then the loader will look for a .dll inside this directory with the same name in either the top level subdirectory or a subdirectory named Contents/Mono. If a matching named .dll is found, that .dll is loaded as a plug-in.
For example, for a directory name AbcdPlugIn.rhp, the plug-in loader will look for a file named AbcdPlugIn.dll inside of that directory and load it if one is found.
Because of the new loading scheme, I was able to get rid of the post build python scripts which were renaming dlls and mdbs in our build solution. RhinoDLR_Python.rhp, Commands.rhp, and Export_DAE.rhp are now directories with all of the necessary assemblies the the plug-ins inside of those directories.
This required quite a bit of change in the xcode build scripts as well as the .NET projects and solutions. Please let me know if you see anything strange with respect to .NET plug-ins as you build Mac Rhino with the latest source.