nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Add-ins that share same custom library

RyanCoodey

We have some standard library projects that are shared among multiple different add-in projects. As I have been bouncing back and forth getting these different add-ins ready to go into production, I realized that when I would make a change to one of the libraries, and then recompile a specific add-in, it would crash at runtime saying it couldn???t find the method or something of that nature. It seems that it is using the DLL from another add-in it has loaded already.

1) Is there a way to tell it to use the DLL that is bundled within its own add-in?
2) If I increment the build version number on each DLL with each test deploy will it then use the right one? This doesn't seem to work 😞

Is there any easy way to not have to re-deploy all our add-ins when just wanting to update one with a small tweak/update in a shared dll?

Thanks a lot for any info.

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

RyanCoodey

Yep, just signing the assembly with a strong name key fixes the problem... don't even have to change the version number on the assembly.

Thanks for all your help Richard!

RyanCoodey

Hmmm, you have to use a strong name to use versioning... I wonder if all I need to do is sign the assembly and provide a strong name key... I'll try that out and report back.

RyanCoodey

There are many options.
You might try changing the version of the shared code and then have the assembly which references the shared code set the properties on the reference to indicate that it is version specific.

Unfortunatly you can not set the Specific Version flag when the reference is to another project. Suppose I could compile the assembly and reference that, not ideal though. Not sure if this will work either...

There are many options.
Create a different assembly for each project, i.e. share the actual underlying C# files but have a different Visual Studio project which builds a different assembly.

Again, not ideal, but should work...

There are many options.
Literally install the shared assembly in the GAC (I understand why XCopy is easier).

Kinda defeats the appeal of add-ins in my opinion if we go this approach.

I'll see what I can come up with... thanks!

RichardWatson

There are many options.

You might try changing the version of the shared code and then have the assembly which references the shared code set the properties on the reference to indicate that it is version specific.

Create a different assembly for each project, i.e. share the actual underlying C# files but have a different Visual Studio project which builds a different assembly.

Literally install the shared assembly in the GAC (I understand why XCopy is easier).

RyanCoodey

Sounds like your problem might be your approach to shared code. For example, I think that if the sharedcode assembly is already loaded from a previous add-in then it will not reload. Perhaps the references should be Version Specific?

I agree, this is exactly the problem... and this is what I am trying to work out. I have tried incrementing the referenced assemblies build number, and the add-in project is referencing this new version number... but it still seems to use the older assembly from one of the other add-ins... Am I missing something? I don't need to give the assembly a unique filename, say with the build number in it, do I (that would be a bit annoying to manage)?

Thanks a lot for all the help so far Richard!

RichardWatson

I have not written any add-ins but read the following this morning:

Add-Ins are installed by simply placing them in a folder, and uninstalled by
deleting the file from the folder. Add-Ins cannot rely on special setup steps
or steps which would require administrator privileges on the machine
(including any sort of COM registry, or registration within the GAC).

Sounds like your problem might be your approach to shared code. For example, I think that if the sharedcode assembly is already loaded from a previous add-in then it will not reload. Perhaps the references should be Version Specific?

RyanCoodey

Thanks for the reply Richard!

The add-ins are being delivered by placing the .esriAddIn file on a network share. The users have this share location set in their registry's "AddInFolders" key.

The assemblies are deployed inside each of the .esriAddIn files, so if the assembly is used in several different add-ins (shared), then it is zipped into both add-in packages. They are not registered and not in the GAC. We just want to do an xcopy like deploy...

I have never used "fusion log viewer", I will check it out.

Thanks a lot!

RichardWatson

How are you delivering your add-ins?

Let's assume that you have the addin1, addin2, and sharedcode assemblies. Where are they physically placed/delivered on the system?

What behavior do you want? Do you want to deliver multiple versions of the sharedcode assembly?

Are your assemblies in the GAC?

There are many ways to share DLLs. What you are essentially asking is how does .NET resolve assembly references. There are a bunch of articles that you can Google on for that. One hint is you can use the fusion log viewer (fuslogvw) to see what it is doing.

RyanCoodey

Any ideas anyone? Thanks!

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.