Hi - I'm just trying to get something looked at by ESRI support :-s and it would be fantastic to get some other confirmation/denials on the issue I've found. It seems that any AddIn which contains folders (i.e. there is some kind of folder structure within the Install area of the add in file) will fail to load up in ArcMap 10.4. It's always been fine in previous versions, and I even noticed that the standard MapCenter AddIn hasn't got folders in since version 10.4 - and always has had up to 10.3.
Attached is an extremely minimal (68kb) AddIn/procedure to show the problem. If anyone developing AddIns and using/moving to ArcMap 10.4 could just try this out on your own AddIn for some extra confirmation I'd be extremely grateful. Just add a folder inside the "Install" bit of your AddIn (can be empty) and see if it fails after the next upgrade....
This happens with both Java and .NET addins.
Yes, I increased the version number in config.xml and restarted ArcCatalog to get it to update (the esriaddin file is just a ZIP file, so you can open it up and change things). I keep meaning to get to grips with Python generally, but time slips away...
Although the .addin is just a zip, I thing the script to create the .addin file does more than just zip it...at the very least it tells where the files are to be unzipped. If you run the .addin file after modifying the ".zip", does it add your new folder to the addin install folder? If not, then just adding it to the zip doesn't work.
not that this is the same Python AddIn: How can I package/deploy a custom lib with my python addin? It was my attempt to use different folders at one time, and my conclusion/solution (before anyone responded). Edit: for convenience, adding conclusion here
"I just moved them to the folder with my other scripts (i.e. addin\Install\scripts in my case). Since my tool scripts do not specify a folder, it appears it first looks in the current folder of the calling script, before or if it doesn't find it in the \lib folder. In any case it worked for this addin. "
i have a PowerPoint file loaded somewhere on how I usually go about making the Python addins. It may have been included on the previous like I sent.
If if you still having issues with you addins and ArcGIS 10.4, I would start up a support ticket.
So, interestingly, if I take my Java AddIn files (the output before it's packaged into a ".esriAddIn" file) and use the Python script "makeaddin.py" to actually create the package - it works. The working and non-working esriAddIn files contain *exactly* the same thing (they are just ZIP files with a specific structure inside). This leads me to believe that there is some difference in the file/folder encoding or some other low level ZIP-reading mechanism which has changed in version 10.4. It's hard to work out as the contents of the AssemblyCache look exactly the same. So I have a sort-of solution (use the Python script to pack the file) but if anyone else sees this issue and finds a real solution (i.e. some specific ZIP file encoding settings that work) then I'd be happy to hear it - we have an automated build system set up and integrating Python into it is a bit of a pain.
I would say this is definitely worth reporting to tech support.
Hard to say is it is a bug or "as designed"...maybe it is necessary for use with Pro? As I probably mentioned already, Python .addin files are not, although I think the toolbox tools will work...although some tweaks might be necessary for Python 3.x.
glad you found a work-a-round anyway. You may want to mark this thread as "assumed answered" unless you want to leave it open in case anyone else wants to jump in.
So for anyone who finds this thread in the future, here's my real solution....
What with my theory about the ZIP format and ESRI pushing the new(ish) ArcGIS Pro - which is purely .NET - I made the assumption that all or part of ArcMap 10.4 has been re-developed using .NET. I looked into the ZIP support in .NET which, as it turns out, has almost always been terrible. So I tried building the .esriAddIn file (a ZIP file) using a fairly old-fashioned way (where you only store files and not folders, but the file names include a full relative path - it's up to the program reading it to work out what the folders are and to honour the structure) and it worked.
In Java/Ant builds you can do this by adding the filesonly="true" attribute to the ZIP task and making sure the file encoding is UTF-8 (it is by default). I'm assuming that addin files created using a .NET builder will work anyway, as they'll be using the same system to write that ArcMap uses to read. The Python builder works, so it must be using a "files only" format by default.