c# Add-in deployment

[aleitao]

Hi,  
i am developing an add-in in c# for EA. It is all great in my development computer, but once i try to deploy it somewhere else i get problems, i put the dll's and tlb generated with regasm (generated in the development computer) in the EA directory. i put the key in the registry like it is supposed, with the name of the namespace, then the project and entry point. when i try to run the EA it gets the error "there was an error loading addin ..." i have only installed the .net redistributable package in the deployment computer. what else do i need to do?  Does the assembly have to be signed with a strong name? i think that only applies if the dll is not on the same directory of EA right?

thank you in advance for your time
Andre

[thomaskilian]

I actually have been through this several times (always after I had to re-install some major SW-components of my computer). It always turned out that I forgot one step in the installation. But as being blindfold until the add-in really runs, it takes hours to find it out. My "advice": try to follow the documented steps for installation in a relaxed mood. I also have a vanilla add-in for such kind of install problems that only shows up with "I'm here and you can now add more functionality". Not really very helpful, I know...

[bittercoder]

This should be easy to figure out:

First off, have a look at the COM interop registy entries for your addin class - has it got a codebase assigned to it? If not you will need to re-register the assemblies using the "/codebase" switch, otherwise fusion won't be able to locate your assemblies unless you register them in the GAC, or place them in the same directory as the EA executable - the assemblies don't need to be signed (unless your register them in the GAC) but I think it's good practice, especially if you make use of any unsafe code.

If you still seem to be having trouble, I would suggest using the fusion logger (part of the windows sdk) - and making sure no assembly location failures are occuring...

In some cases you will need to handle assembly resolution failures, and direct the .Net runtime to locate your code, you can do this by adding an event handler to AppDomain.CurrentDomain.AssemblyResolve, which loads the apropriate assembly from the directory your application is installed into.

Last of all, if you plan to putting your add-in on more then a couple of machines, I would suggest taking a couple of hours to build a WiX installer for it - it will save you a lot of time in the future.

Chez,

- Alex

[Eric Johannsen]

I wrote a single plugin framework (in C#) that dynamically loads any number of other plugins (written in any .NET language) from a special plugins directory, so that I only have to deal with the COM interop hassle once.

I did not want to install any code in the GAC and did not want to have to sign it, so I used code to locate the unresolved assemblies:

Code: [Select]


       // In my framework constructor:
                   AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);

       // Then implement the assembly resolver:

       System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
       {
           string assemblyBasePath;
           string altAssemblyBasePath;

#if DEBUG
           assemblyBasePath = DEBUG_ASSEMBLY_BASE;
           altAssemblyBasePath = DEBUG_ASSEMBLY_BASE; // No alternates in debug mode
#else
           string exeName = Application.ExecutablePath;
           assemblyBasePath = Path.Combine(Path.GetDirectoryName(exeName), @"CanonicPlugins\");
           altAssemblyBasePath = Path.GetDirectoryName(exeName);
#endif
           //This handler is called only when the common language runtime tries to bind to the assembly and fails.

           //Retrieve the list of referenced assemblies in an array of AssemblyName.
           Assembly myAssembly = null; //, executingAssemblies;
           string tempAssemblyPath = string.Empty;
           string dllName = args.Name.Substring(0, args.Name.IndexOf(",")) + ".dll";

           tempAssemblyPath = assemblyBasePath + dllName;

           //Load the assembly from the specified path.
           if (File.Exists(tempAssemblyPath))
           {
               myAssembly = Assembly.LoadFrom(tempAssemblyPath);
           }
           else
           {
               tempAssemblyPath = altAssemblyBasePath + dllName;
               if (File.Exists(tempAssemblyPath))
               {
                   myAssembly = Assembly.LoadFrom(tempAssemblyPath);
               }
           }

           //Return the loaded assembly or null if not found.
           return myAssembly;
       }



I also found the Assembly Binding Log Viewer (FUSLOGVW.exe) useful... it shows any .NET assemblies that could not be resolved, and what path(s) were attempted to resolve them.

This approach will not get you over the initial hurdle of registering the framework class for COM interop, but allows you to add any other plugins written in .NET (C# etc) without further interop issues.

I did leave out some of the details of the framework (it's still under development but we may post it once it's done).  Feel free to email me if you have questions:

eric D0T johannsen AT canoniccorp D0T com

Eric

[Paolo F Cantoni]

Hi Eric...

This is a very useful artifact.  Would it be possible for you to add it to the [size=13]EA User Group Wiki[/size]?
That way, it is more available to everyone...

TIA,
Paolo

[Charlie]

As suggested by Alex above, I have been creating a Wix installer for the add-in I am building.  However, I've not been able to get the installed add-in available to EA.  What settings did you use for your dll file in Wix:
- Did you add the dll to the GAC (I get an error in manage add-ins screen).
- SelfRegCost='1' (I get an error during the msi install "unable to register dll").