I have been developing an AddIn for Revit versions since 2016. Every year I upgrade the addin to work with the next verison, and sometimes implement new features or discontinue those that are not used or have been duplicated elsewhere. My firm (Architecture) has been using Revit 2020 now for about a year, and mostly we have had no issues with the AddIn. But since about 6 moths ago each new computer does not run the addin correctly. Apparently what happens after install the IT guys open Revit and click the "always load" if it comes up, and then close out. But after that when the user runs Revit my add in is not there. In the journal file I see an error that the addin is duplicated:
DBG_INFO: The addin file -MyAddIn.addin- in all user folder is duplicated.:
and I'm guessing this means the GUID is conflicting with another addin, but all of the machines get the same setup, so why would this happen only on a few? I am not able to duplicate this error on any of the machines I have access to, so trying to understand what I can do to fix this.
Solved! Go to Solution.
I have been developing an AddIn for Revit versions since 2016. Every year I upgrade the addin to work with the next verison, and sometimes implement new features or discontinue those that are not used or have been duplicated elsewhere. My firm (Architecture) has been using Revit 2020 now for about a year, and mostly we have had no issues with the AddIn. But since about 6 moths ago each new computer does not run the addin correctly. Apparently what happens after install the IT guys open Revit and click the "always load" if it comes up, and then close out. But after that when the user runs Revit my add in is not there. In the journal file I see an error that the addin is duplicated:
DBG_INFO: The addin file -MyAddIn.addin- in all user folder is duplicated.:
and I'm guessing this means the GUID is conflicting with another addin, but all of the machines get the same setup, so why would this happen only on a few? I am not able to duplicate this error on any of the machines I have access to, so trying to understand what I can do to fix this.
Solved! Go to Solution.
Solved by Sean_Page. Go to Solution.
It is deployed manually . . . a server location with a shorcut to the local add in location "%ProgramData% . . . etc" along with the dll and manifest. Drag onto the shortcut and voila . . . installed. I use the community version of VS and there is not a good way to create a proper installer.
So I realized that the deployment we now use actually puts the add in in two locations, the first of which is a deprecated location according to the docs: "C:\Program Files\Autodesk\Revit [Version]\AddIns" I think what is happening is that the addin fails to load from that location, but the GUID is identical to the other place it is (same as the shortcut folder above) which then fails because it is a duplicate. Removing the manifest from the deprecated location fixes the issue, but it will not work if it is only in that location either. So I need to get the IT guys to fix the deployment setup.
It is deployed manually . . . a server location with a shorcut to the local add in location "%ProgramData% . . . etc" along with the dll and manifest. Drag onto the shortcut and voila . . . installed. I use the community version of VS and there is not a good way to create a proper installer.
So I realized that the deployment we now use actually puts the add in in two locations, the first of which is a deprecated location according to the docs: "C:\Program Files\Autodesk\Revit [Version]\AddIns" I think what is happening is that the addin fails to load from that location, but the GUID is identical to the other place it is (same as the shortcut folder above) which then fails because it is a duplicate. Removing the manifest from the deprecated location fixes the issue, but it will not work if it is only in that location either. So I need to get the IT guys to fix the deployment setup.
Sorry, I meant to reply to you but seem to have posted a solution instead. Yours is accepted as you do indicate the root of the problem being the installation method (as part of a deployment, but incorrectly implemented).
Sorry, I meant to reply to you but seem to have posted a solution instead. Yours is accepted as you do indicate the root of the problem being the installation method (as part of a deployment, but incorrectly implemented).
Can't find what you're looking for? Ask the community or share your knowledge.