Loading of different configurations of a AutoCAD plugin bundle silently fails

Loading of different configurations of a AutoCAD plugin bundle silently fails

Anonymous
Not applicable
1,338 Views
8 Replies
Message 1 of 9

Loading of different configurations of a AutoCAD plugin bundle silently fails

Anonymous
Not applicable

Hello,

 

We are developing an AutoCAD 2016 plugin to interface with our calculation software.

We have a basic setup where the plugin loads via a bundle registers it's commands and sets up a network connection with the back end via net pipe, this is a working setup.

 

 

As we are developing we would like to load multiple  versions (dev, release candidate, production version etc..) of our plugin into AutoCAD so that our testers don't have to uninstall their production software to test and reinstall etc.., this is were the problem starts.

 

When a version is placed in the ApplicationPlugins folder by itself, the plugin works as expected, the plugin is installed, commands are registered and work as excpected.

When multiple versions are installed, the plugins are both reported as successfully installed, however, only the last plugin (as far as i can tell, in alphabetical order) is loading correctly (works as expected). 

 

The plugin versions differ in the following aspects:

  • Bundle names are different for each configuration
    • Sarens.Autodesk.2016.plugin.LDev.bundle, Sarens.Autodesk.2016.plugin.LRel.bundle, etc...
  • PackageContents.xml:
    • ApplicationPackage attribute UpgradeCode is different for each configuration
    • ApplicationPackage attribute ProductCode is unique for each build
    • ApplicationPackage attribute Name is different for each configuration
    • ApplicationPackage/Components/ComponentEntry attribute ModuleName is different for each configuration
  • Project differences
    • assembly: AssemblyTitle, AssemblyProduct, Guid are different for each configuration
    • AssemblyName and dll filename are different for each configuration
    • [CommandMethod] attributes are different for each configuration using constants: eg:
      [CommandMethod(Prefix + "Sarspace Test", Prefix + "TestLogging", CommandFlags.NoNewStack)]
    • Namespace for class containing the methods that are registerd as a commandmethod is different for each configuration:
      • namespace Sarspace.Plugins.Autocad._2016.Launcher.Debug 
        // Debug changes to Release in a different configuration { public class CadExtension : IExtensionApplication { // abbreviated [CommandMethod(Prefix + "Sarspace Test", Prefix + "TestLogging", CommandFlags.NoNewStack)] public static void HelloWorld() { _logger.Debug("Send information to {0} registered clients", _serviceHostHandler.CountConnectedUsers()); _serviceHostHandler.SendInformationToSubscribers(); } //abbreviated } }

 

As far as I can tell from an outsider point of view these assemblies are completely different and should work side by side.

 

When debugging from visual studio, with a single installed plugin, the output shows the loading of the plugin:

'acad.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'C:\ProgramData\Autodesk\ApplicationPlugins\Sarens.Autodesk.2016.plugin.LDev.bundle\Sarspace.Plugins.Autocad.2016.Launcher.Ldev.dll'. Symbols loaded.

However when running with two plugins installed, only the last plugin (in I assume alphabetical order is loaded) full output in attachment:

'acad.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'C:\ProgramData\Autodesk\ApplicationPlugins\Sarens.Autodesk.2016.plugin.LRel.bundle\Sarspace.Plugins.Autocad.2016.Launcher.Lrel.dll'. Symbols loaded.

I would expect the ldev dll to be loaded as well, but it is never mentioned.

 

I'm running out of ideas:

  • What else can i do to make the plugins differ from each other?
  • Where can I check how the plugins/plugin commands are registered?
  • All other ideas are welcome.

 

Best Regards,

 

Evert

0 Likes
Accepted solutions (1)
1,339 Views
8 Replies
Replies (8)
Message 2 of 9

Anonymous
Not applicable

Ok,

 

After reinstalling autocad, both plugins were loaded correctly and their commands were  loaded correctly. 

It looks like somehow my autocad insallation became corrupted, I have installed and uninstalled the plugins fifty times or so, perhaps some corruption occured.

 

However, I still have an issue with the namespaces: both dlls reference a constants class that is part of the unmodified namespace. It looks like the namespaces of both plugins are not separate. Is there a good strategy to handle this in an autocad plugin?

 

Best Regards,

 

Evert

0 Likes
Message 3 of 9

_gile
Consultant
Consultant

Evert.Bevernage a écrit : It looks like the namespaces of both plugins are not separate. Is there a good strategy to handle this in an autocad plugin?

 

Best Regards,

 

Evert



This is a .NET behaviour, not related to AutoCAD. A single namespace can be defined in different assemblies (e.g. Autodesk.AutoCAD.ApplicationServices is defined in both AcMgd.dll and AcCoreMgd.dll).

 

Separated namespaces must have different names.



Gilles Chanteau
Programmation AutoCAD LISP/.NET
GileCAD
GitHub

0 Likes
Message 4 of 9

Anonymous
Not applicable

I would have expected some kind of sandboxing around the plugins. 

In my case it is pretty obvious that there is a namespace conflict, but when two plugins rely on a third party dll but a different version with a different filename but the same namespace all sorts of unexpected behavior could occur, that might not immediately be obvious or easily replicable. Are there any design suggestions to avoid these issues?

 

Best Regards,

 

Evert

0 Likes
Message 5 of 9

_gile
Consultant
Consultant

You can extend existing namespaces.

If you build the following code as a class library (DLL) and then reference it into some project, the StringExtension class class will be appended to the System namespace adding the String.ToTitle() method.

 

namespace System
{
    public static class StingExtension
    {
        public static string ToTitle(this string s)
        {
            Globalization.CultureInfo cultureInfo = Threading.Thread.CurrentThread.CurrentCulture;
            Globalization.TextInfo TextInfo = cultureInfo.TextInfo;
            return TextInfo.ToTitleCase(s);
        }
    }
}

 



Gilles Chanteau
Programmation AutoCAD LISP/.NET
GileCAD
GitHub

0 Likes
Message 6 of 9

_gile
Consultant
Consultant

If I don't misundertand, you have, on one side some 'by version' specific classes (or enum, interfaces) with differnt codes, and on the other side, some other 'imutable' classes common to every version. And you want all the versions to be loaded at the same time.

 

I'd buid one assembly with all the common classes. This assembly may defined one or more namespaces (e.g. Sarspace.Plugins.AutoCAD.Common) and be referenced by all the version specific projects.

 

Each version specifi classes should be built as a different assembly (i.e. a different filename) for each version. For maintenance facilities, each project may have the same class names, so to avoid name conflicts, you can use different namespaces in each assembly (e.g. Sarspace.Plugins.AutoCAD.Development Sarspace.Plugins.AutoCAD.ReleaseCandidate, Sarspace.Plugins.AutoCAD.Production).

And, of course, command names must be different for each version.

 

Hope it helps...



Gilles Chanteau
Programmation AutoCAD LISP/.NET
GileCAD
GitHub

0 Likes
Message 7 of 9

Anonymous
Not applicable

You understood correctly. 

 

However for us due to the project design it would be too much work to separate the different versions, especially the namespaces for all required dlls, and potential namespaces we don't have control over. We have deceided to install de-install when testing different versions.

 

I wonder how AutoDESK recomends getting around this issue. In a more generic case, when two plugins refer to the same DLL, but both require a different version with slightly different implementations of functions conflicts will occur that are very difficult to reproduce or resolve as we don't have cotnrol over the external namespace.

 

Best Regards,

 

Evert

 

 

0 Likes
Message 8 of 9

Virupaksha_aithal
Autodesk Support
Autodesk Support
Accepted solution

Hi,

 

does blog http://adndevblog.typepad.com/aec/2012/06/loading-multiple-versions-of-the-same-dll-used-in-revit-pl... provides you the required hints for your issue of when two plugins refer to the same DLL, but both require a different version with slightly different implementations



Virupaksha Aithal KM
Developer Technical Services
Autodesk Developer Network

0 Likes
Message 9 of 9

Anonymous
Not applicable

This looks like what i've been looking for, thx.

0 Likes