idea Remove Addin from user instead of deleting .esriAddinx in ArcGIS Pro Ideas

Remove Addin from user instead of deleting .esriAddinx

Anonymous User — Wed, 13 Jul 2022 14:29:26 GMT

I have an Addin that is used across the organization (50+ people). I used the shared folder because:

Designating a well-known folder on a network drive is a convenient way for many people in a workplace to use the same add-ins.

However, if one person decides to delete the Addin from their Pro using the 'Delete this Add-in' button, it deletes the the underlying .esriAddinx file, as indicated in the Managing Add-ins documentation.

If you use the Add-In Manager to delete an add-in that is loaded from a well-known folder on a network drive, the .esriAddInX file is permanently deleted, just as it would be if you used Windows Explorer to delete the file from its location on disk.

There is nothing stopping curious users from deleting the esriAddinx file. This is a huge problem because the Addin is now broken for everyone else and for future users until the esriAddinx file is restored. The 'Delete this Add-in' should just remove it from the users Pro addin list and not delete the underlying .esriAddinx file.

Re: Remove Addin from user instead of deleting .esriAddinx

DuncanHornby — Sun, 24 Jul 2022 18:14:56 GMT

Just an idea, don't know if it will work. But in Windows File Explorer navigate to the AddIn folder and set the properties of the file to be read-only. That might stop accidental deletion? At least give it ago?

Re: Remove Addin from user instead of deleting .esriAddinx

Anonymous User — Mon, 25 Jul 2022 13:30:45 GMT

Thanks for the suggestion, I set it as read only but it still deletes the esriAddinX file. If it did work, I'd still ask for esri to fix this because why would you let one person be able to break the Addin for everyone else?

Re: Remove Addin from user instead of deleting .esriAddinx

DaveFullerton1 — Tue, 02 Aug 2022 21:42:03 GMT

@KoryKramer could you tell us if users deleting the .esriAddinX file is this the intended functionality? We have had this happen too.

Re: Remove Addin from user instead of deleting .esriAddinx

KoryKramer — Wed, 03 Aug 2022 20:46:17 GMT

Hi @DaveFullerton1 the development team is looking into this report and we'll keep you updated through statuses on this idea. As for "intended", that could be interpreted in different ways. I'd say that currently things are working as designed but what is being reported here is not an intended outcome so we're investigating how to improve the design. Thank you!

Re: Remove Addin from user instead of deleting .esriAddinx

Anonymous User — Thu, 04 Aug 2022 13:41:25 GMT

@KoryKramerThank you (and the dev team) for looking into this. I've had to restore the esriAddinX file a couple times (and send more emails instructing people not to do it, but that just seems to make them want to do it more) since posting this.

Re: Remove Addin from user instead of deleting .esriAddinx

Anonymous User — Thu, 17 Nov 2022 13:27:54 GMT

I was looking at alternatives and going the sharing route for deploying these add-ins and see that we can 'share' our add-in to AGOL- but nothing about sharing it our Portal. I don't need to share it to the world, just to our organization. I was hoping that going the shared route would stop the deleting of the .esriAddinX and make it easier for me to manage. @KoryKramer Do you know if there are plans for supporting add-ins in Portal?

Re: Remove Addin from user instead of deleting .esriAddinx

KoryKramer — Thu, 17 Nov 2022 15:29:53 GMT

@Anonymous User I found this https://enterprise.arcgis.com/en/portal/latest/use/supported-items.htm

Re: Remove Addin from user instead of deleting .esriAddinx

StefanDieters1 — Wed, 08 Feb 2023 04:24:12 GMT

We have the same situation, with 2 groups of users Pro 3 (developers testers) and Pro 2.9.5 (users). To my horror I found that I could delete an esriaddinx file from a shared directory.

The ability to delete the esriaddinx file is not needed as this is an admin function, can be done through the windows file system. An an alternative behavior is just not show incompatible add-ins in the Add-In Manager. Pro 3 and Pro 2.9.5 already can detect compatible addin files.

Our solution

We have set-up multiple permission groups around our common folder that contain the addin (ArcMap and Pro) files. Our ICT set this up. Normally this stops unauthorized deletion (windows blocks Pro 3/2.9.5). I was able to delete the add-in file because I was the owner. Dumb !

Easy way?

As an extra precaution I have now set each esriaddinx file to be read-only (Windows 10 properties dialog).

This works and block Pro 3 and 2.9.5 from deleting an add-in esriaddinx file.

Check it out on your set-up.

Re: Remove Addin from user instead of deleting .esriAddinx

SimonSchütte_ct — Wed, 08 Feb 2023 13:09:16 GMT

Deleting Addins is definitely too simple, there is not even a notification "Do you really want to delete..."

I think a good solution would be an option to disable Addins
- Once a Add-In is disabled, show the delete Button.
- Instead of the "Delete this Addin Button", rename the button to "Remove this Addin"
- By Default "Remove this Addin from Addin list", optionally have an option to "Delete the source Addin file"

Re: Remove Addin from user instead of deleting .esriAddinx

AndrewQuee — Thu, 09 Feb 2023 06:20:26 GMT

Pro should definitely show (greyed out) add-ins that are not compatible from shared folders, and that they are not being used. This information can be provided to admins as required for further action.

Being able to delete them (and so easily) should not be possible by the average user when the explicit function of the feature is, "...a convenient way for many people in a workplace to use the same add-ins." I doubt very much that 'many people' would find it convenient to discover that their add-in had been quickly and invisibly removed by someone, making it unavailable to everyone.

I further note that this is not the same behaviour ArcMap exhibits when it is loading add-ins from a shared folder.

Managing file/folder permissions to get around this is an effective hack, but it's still a hack imho.

Re: Remove Addin from user instead of deleting .esriAddinx

Bud — Thu, 09 Feb 2023 12:01:48 GMT

Could you ask your network administrator to change your users’ folder privileges from read/write/delete to read-only? (for that specific folder)

Re: Remove Addin from user instead of deleting .esriAddinx

AndrewQuee — Fri, 10 Feb 2023 01:10:19 GMT

Sure, and we have. It still doesn't address the issue of what happens if someone who does have permission does a whoopsie, or if the folder permissions are changed for some reason beyond our control (this has happened to us in the past). We have also had users arbitrarily added to our domain group without our permission or consultation...

To me the analogy is having two D's on your car gear select. One is Drive and the other is Destroy. As as long as you use the first, it's fine. Choosing the second one instantly destroys the transmission without warning (perhaps as a security procedure to stop car theft). Adding protective guards around accidentally using the other D-gear seems counterproductive to... not having it at all. Which is why it does not exist outside a Mad Max movie.

I just don't understand the design of this feature, especially when Pro is touted as an enterprise level tool for multiuser-GIS organisations.

To further explain our position, we use addin customisations to deliver business-critical functionality and productivity tools to ~60 users, while the tools are available to the entire organisation (~1000 staff). While the tools are currently protected as Bud suggested, the default behaviour of one person detonating the custom tools for everyone seems... unwise.

Re: Remove Addin from user instead of deleting .esriAddinx

Anonymous User — Fri, 10 Feb 2023 03:56:57 GMT

Thanks to everyone that gave a thumb and their thoughts to this. It would be a very useful feature to be able to turn addins off and on without having to delete them, uninstall them, or remove the folder they are in and then add them, install them, or add folder again when needed. As a developer, I wouldn’t knowingly/expectantly put my user/consumer into a situation where they need to manage folder permissions as a precaution against a small (relatively speaking) function of my software.

Along with the on/off switches, it would be nice to get a separation between the Pro projects used for development, and normal use projects. The development addins stick with every project until the dev folder is removed… It should be a temporary instance of Pro that lives as long as the visual studio process runs it, and only the finished release version addins be in the ‘normal use’ Pro projects. Bugs me when I open a project for other work and I see the addins that I am still developing. Hope that makes sense and probably another idea.

Thanks for the support in getting this idea traction and hopefully fixed.

Re: Remove Addin from user instead of deleting .esriAddinx

KoryKramer — Fri, 10 Feb 2023 19:07:05 GMT

Hi all,

I just talked through this with a colleague and I'd like to get some feedback on the following. The Make administrative settings part of the add-in documentation discusses how to distribute add-ins in the manner that you're referring to.

If I only set up a well known folder from a shared network location (my understanding from the original idea and ensuing discussion is this is how you're all setting up your add-ins):

Then we get the behavior described; i.e. the add-in is recognized under "My Add-Ins" and the user has the ability to delete it.

However, if I follow the instructions referenced above to make the add-in available through the admin workflow, it is recognized under "Shared Add-Ins" and the user is not able to delete it.

Hopefully this will help many if not all of you. Does this method work for your organizations? If not, can you let us know why not?

Thank you!

Re: Remove Addin from user instead of deleting .esriAddinx

Anonymous User — Sun, 12 Feb 2023 03:08:53 GMT

Thanks @KoryKramer for the follow up.

The admin method- Every pc that will load these addins will need to have this registry edited? I don't think this is a viable solution for several reasons.

1. We'd have to track this to ensure that one doesn't slip through a crack; and all it takes is one. PC rebuilds, new installs, personnel moving, does this key persist across version updates, or would it need to be set again, (like how the conda environments used to be). ... It's not making the installation and management of the software product easier.

2. Lets say the addin is mysteriously deleted. That means either one pc isn't keyed, or it was deleted from the folder- There is no way we can tell. I am now spending hours++ checking every pc for this key and the damage is already done. As much time and effort we put into keying every pc, it didn't prevent it from being deleted but still required more time and management.

3. Changing the folder permissions seems like a more stable (one point of contact) solution since it is done once on the folder, and not on every pc that is running Pro addins. But it is still modifying the system in response to a bad functionality of a program...

4. Using the same folder permissions vs. every pc point of failure- esri can solve this issue for every single one of their users by changing the functionality of that button to just remove it from the user configuration and not delete it from disk. They can solve this issue without their users needing to maintain additional folder permissions or per pc registry edits.

5. Why is the person 'deleting' the addin from their Pro project in the first place? To remove it from their Pro configuration. Why then does it delete the addinx for everyone else? Developers (at least myself) are (probably) more likely to delete the addinx and all of its accompanying dlls/ toolboxes, etc.,. through windows explorer. If that button was named 'Remove', and it simply removed the addin from the user, its purpose would be achieved.

6. Delete only deletes the addinx and nothing (dlls, toolboxes, stuff) else. We (developers) don't use Pro to delete these files if we are replacing them or moving their location- we use windows explorer so I'd venture to say that the 'delete' is useless for us in that regard.

Edit to add to 6: This is like having a 'remove' button for shapefiles that achieves the task by deleting the .shp file, leaving the .dbf, .shx, .xml, .prj, .cpg, .sbn behind.

That's all I got time for today- Hopefully others will include their perspective.

Re: Remove Addin from user instead of deleting .esriAddinx

KoryKramer — Fri, 10 Feb 2023 20:41:09 GMT

Great additional details/context, @Anonymous User Thank you.

Re: Remove Addin from user instead of deleting .esriAddinx

DaveFullerton — Sat, 11 Feb 2023 05:32:53 GMT

I have to say that the idea of the user deleting the source file is so very counter-intuitive that it just should not be done. First of all, the users certainly won't have any reason to want to do that. They don't understand it in the first place. Second, I think that unless you put big exclamation points in the documentation, many developers might not actually understand that this is what is going to happen. We are smart people, but it is hard to ingest something that doesn't make sense, doesn't seem to have a purpose, and is unprecedented. I think the question here should be, "Why is it designed this way?" If you could tell us why it might be useful to us, then we might be able to give you our full perspective on the issue. As it is, yes, we are able to use the registry setting, and we prefer to use the registry setting for many of our in-house add-ins that we want all users to have installed. But we would still like to be able to allow the users to choose to add and remove other add-ins as they see fit by adding or removing a path to a shared location in the Add-in Manager. We don't have a lot of people in our organization that have admin rights anymore, so doing everything through the registry is not ideal. And having users each have their own copy of the add-in file (double-click install) is not going to be good when it comes to migrating to a new major release. There we will see breaking changes, so we want to have a centralized repository of all add-ins in order to see what needs to be fixed before the upgrade.

Re: Remove Addin from user instead of deleting .esriAddinx

AndrewQuee — Tue, 14 Feb 2023 05:51:21 GMT

Thanks @KoryKramer for investigation and clarification of how it should work. I did not know you could configure it as an admin add-in. I confirm to you Kory we are doing it the former way as part of user configuration.

Great comments all round. Our ICT is not okay with us registry hacking (especially not for clients) so I don't think this will work for us. We do deploy with the awesomely acronymed MSSCCM-AC (Microsoft System Center Configuration Manager Application Catalog) so it possible that a .reg could be queued into an installation script. Not sure if that has changed now Pro no longer uses .msi and just has an .exe.

This still has all the disadvantages @Anonymous User eloquently detailed. In addition we have raised similar questions with ICT before and they said it was extremely difficult to know where to put the registry node/keys due to a mix of hardware and software (mobile/desktop/virtual, different OS', etc) requiring excess scripting and support on their end. The documented registry edit looks stable to me though.

Re: Remove Addin from user instead of deleting .esriAddinx

Anonymous User — Mon, 13 Mar 2023 16:25:21 GMT

I think we need the ability to disable the 'global' install of addins. Pro is largely per project, (eg, connections, folders, servers, etc) but addins are not. @SimonSchütte_ct has a great idea being able to turn them off and on depending on the needs. The issue is we have a server that shared between several departments. There is one install of Pro on that server. If there is an addin used for syncing public works data to their third party software, our Health department's projects by default load that addin. They could see the login info for the third party software so this is also a security issue.