ArcGIS Pro Add-ins: Runtime method-not-found error when sharing a class library between two modules

[rdc_hirohara]

Hi,

I’m developing an ArcGIS Pro SDK for .NET add-in, and I’m encountering a runtime issue when sharing a class library between two module add-ins.

Project Structure:

• ClassLibrary1: a shared class library
• ProAppModule1: references ClassLibrary1
• ProAppModule2: also references ClassLibrary1

Steps to reproduce:

1. Add only Method1 to ClassLibrary1 and build all projects.
2. Implement ProAppModule2 to call ClassLibrary1.Method1 from a button.
3. Add Method2 to ClassLibrary1, rebuild all projects.
4. Implement ProAppModule1 to call ClassLibrary1.Method2 from a different button.

At runtime (inside ArcGIS Pro):

• Pressing the button in ProAppModule2 (which calls Method1) works fine.
• Pressing the button in ProAppModule1 (which calls Method2) throws a MissingMethodException or similar, saying the method is not found.

It seems that ClassLibrary1.dll from ProAppModule2 is always the one being loaded, even though ProAppModule1 has its own reference to the updated DLL.

This behavior occurs only when both add-ins are present. If only one add-in exists, everything works as expected.

Question:
Is there a known issue or best practice for referencing a shared class library from multiple ArcGIS Pro Add-in modules?
How can I ensure that both add-ins use the correct and updated version of the shared assembly at runtime?
Is there a recommended way to isolate or unify shared library usage between add-ins?

Any advice would be greatly appreciated. I've attached a minimal repro project (CommonClassLibraryTest.zip).

Thank you!

[SelimDissem]

I got it to work, needed a couple of changes:

- ProAppModule2 has a copy of the folder inside of itself (that makes the build fail). Just delete it. Probably a zipping oversight.

- For ProAppModule2 to work without a problem, add the ClassLibrary1 project to the ProAppModule2 using the Add/Existing project, then in the ProAppModule2 project dependencies add ClassLibrary1 as a project (the same as it is in ProAppModule1).
That way each esriAddinX will have its own copy of the compiled ClassLibrary1 as a DLL and will not have any conflict or problem loading it.

You probably don't need it but I'm attaching a Zip file of the fix for reference.

[rdc_hirohara]

Thank you for taking the time to check the project and share your version.

However, it looks like the modified sample you posted doesn't use ClassLibrary1 at all — it just shows a message box directly from the button click handler. My original issue is specifically about what happens when both modules reference the same shared class library, and one of them tries to call a method that was newly added.

The runtime error only occurs when:

• Both add-in modules are present
• ClassLibrary1 is updated to include a new method (e.g., Method2)
• One module (e.g., ProAppModule1) tries to call the new method

It seems like only one version of the shared DLL is loaded at runtime, and if it's the older one, the new method cannot be found.

Could you try testing the project as-is with those conditions? I’d really appreciate your insights if you’re able to reproduce the issue in that context.

Thanks again!

[rdc_hirohara]

Hi SelimDissem,

Thank you for taking the time to look into my issue.

I just realized that the original CommonClassLibraryTest.zip I uploaded might not have been in the correct state — it was missing the actual call to ClassLibrary1.Method2, which is essential to reproduce the runtime error.

I'm very sorry for the confusion this may have caused.
I've now updated the ZIP file with the correct version of the project that includes the added method and both modules referencing it properly.

Thank you again for your time and understanding. I really appreciate your support.

Best regards,

[rdc_hirohara]

Please note that the original CommonClassLibraryTest.zip attachment in the main post is outdated.
The correct version is attached in the second reply below.

[SelimDissem · Accepted solution]

You have a couple of options:

- revise the need to have different versions of the same library/DLL shared across multiple add-ins. You could just have the latest referenced by all your add-ins and then only have one version loaded and shared by all the add-ins.

- if you do have a requirement for multiple versions of the same library to co-exist for different add-ins, you'll have to:

      1. give your library a strong name / sign it and version it so .NET can tell the various versions apart.

      2. enable side by side loading of add-ins as documented in ProConcepts Advanced Topics · Esri/arcgis-pro-sdk Wiki (Pro 3.5+)

If you have to support a version of Pro prior to 3.5, the simplest solution is the first one (one version of the class library for all add-ins, deployed only once).

Hope this answers your question

[rdc_hirohara]

Thank you SelimDissem!
That’s exactly what I tried yesterday — I added a _ at the end of the assembly name (ClassLibrary1_), and it worked.
It's great to know this is a reproducible behavior and not just something on my setup.

[Wolf]

The ArcGIS Pro SDK community samples repo contains an example of two Add-ins interfacing.  Under the Framework folder you'll find AddInOne and AddInTwo and the shared component AddInShared.
If you have a reusable versioned class library, you'll have to sign the add-in (and library) as @SelimDissem  said above. If you just want to 'share' common source code between your two Add-ins you can also add a reference to your 'shared' CS source code as shown here (in which case, you don't need to worry about DLL versions):

[rdc_hirohara]

Thank you, Wolf — you're absolutely right.
I tried switching to a shared DLL (instead of embedding it via project references), and the problem is resolved when both add-ins refer to the same external DLL.

The challenge, of course, is in distributing that shared DLL: since it's not embedded in the .esriAddinX files, it has to be placed manually or via installer on all target machines.

In environments where we need to keep deployment simple — for example, by just distributing .esriAddinX files — this can become a bit of a maintenance concern.

That said, I completely agree that your approach is the cleanest and most robust solution in the long term. I may look into creating a small installer to bundle the shared DLL if the project grows.

Thanks again for the helpful insight!

[rdc_hirohara]

I also appreciate Wolf's insight — his suggestion is the cleanest long-term solution from a design perspective.
But I’ll accept SelimDissem’s answer since it directly solved the issue in the current setup.