Revit 2014 addin gets loaded twice when using LoadAddIn() method

[Anonymous]

Hi, 

I have an Addin that updates another Addin and then it loads the updated Addin with the new method LoadAddin()  the API loads the addin two times. Is that a known issue?

Thank you

Marc

[TripleM-Dev.net]

Hi,

Any updates on this one?, facing same issue.

In order to AutoUpdate the addin I thought of using LoadAddin in a Loader Addin, which in turn can update the dll

before loading the actual addin (with LoadAddin) if needed.

However the Addin gets loaded twice (Ribbon and DockPanel issues) which can be circumvented, but I rather have the LoadAddin only load once.

Best regards,

Michel

[jeremytammik]

If you have an add-in loaded, and it creates a user interface for itself, and then load another add-in that recreates the same user interface, it sounds completely logical to me that the user interface is duplicated.

If you absolutely must support that scenario, you must find a way to remove the first user interface before creating the second one.

Maybe the UIApplication Dispose method can help?

https://www.revitapidocs.com/2020/e6297962-5639-88c2-d673-79c8cc030757.htm

[jeremytammik]

Dear Michel,

Thank you for your query.

I found the answer to the previous case and edited it for publication here.

I hope this will help you as well:

Answer: I do not see the problem you describe.

I can reload a newer version of the existing add-in without duplicating its UI.

You can solve this as follows:

• Unzip the two add-in projects RevitAddin1 and RevitAddin2 in the attached archive test.zip
• Build RevitAddin1
• Place RevitAddin1.addin in C:\ProgramData\Autodesk\Revit\Addins\2014
• Place RevitAddin1.dll in C:\Temp\RevitAddin1\RevitAddin1\bin\Debug
• Build RevitAddin2
• Place both RevitAddin2.addin and RevitAddin2.dll in C:\Temp

Result: You can see "Command RevitAddin2" after the "Command RevitAddin1" is launched.

NOTE: Please make sure the ClientId in the add-in manifests are not conflicting.

• C:\ProgramData\Autodesk\Revit\Addins\2014
• C:\Users\<user name>\AppData\Roaming\Autodesk\Revit\Addins\2014

public Autodesk.Revit.UI.Result Execute(
  ExternalCommandData commandData,
  ref string message,
  Autodesk.Revit.DB.ElementSet elements)
{
  UIApplication app = commandData.Application;
  UIDocument uidocument = app.ActiveUIDocument;
  Document document = uidocument.Document;
  char[] _parenthesis = new char[] { '{', '}' };
  string tag = "ClientId";
  string filename = "C:/Temp/RevitAddin2.addin";
  try
  {
    XmlDocument doc = new XmlDocument();
    doc.Load(filename);
    XmlNodeList nodes = doc.GetElementsByTagName( tag );
    foreach( XmlNode node in nodes )
    {
      Guid g = Guid.NewGuid();
      string newText = g.ToString().Trim( _parenthesis ).ToLower();
      node.InnerText = newText;
    }
    doc.Save(filename);
    app.LoadAddIn(filename);
  }
  catch(Exception ex)
  {
    message = ex.Message;
    return Autodesk.Revit.UI.Result.Failed;
  }
  return Autodesk.Revit.UI.Result.Succeeded;
}

Response: Thanks for your help.

Your example worked fine. There is a difference between how you loaded the add-in and how I loaded it.

You keep the RevitAddin2.dll and RevitAddin2.addin file in a different folder than Revit Addins folder (c:\temp\ folder). I was copying only my add-in DLL inside the %appdata%\Autodesk\Revit\Addins\2014 folder and then loading the add-in file from a network location.

I think Revit was loading first the add-in trough the LoadAddin() method and then it was loading the add-in again because it was inside the %appdata%\Autodesk\Revit\Addins\2014 like a new add-in. You are keeping all files outside the %appdata%\Autodesk\Revit\Addins\2014 folder, that is the main difference.

I hope this helps.

Best regards,

Jeremy

[TripleM-Dev.net]

Hi Jeremy,

Thanks for the response.

I tried you're addin, these work as expected. But a IExternalCommand loads another IExternalCommand.

In my situation a IExternalApplication loads another IExternalApplication (not same assembly or id's).

Now for the tests:

1. Removed the loading of RevitAddin2.addin to my actual applicication addin

  -> this works, the application only loads once, so far so good

2. Changed the RevitAddin1 into a IExternalApplication, and let it load RevitAddin2.addin

   -> this works, the button for RevitAddin2 IExternalCommand is shown at startup.

3. Changed the RevitAddin2 also into a IExternalApplication, with a popup message.

   -> this loads twice.

I think this is a Bug or just a limitation for the LoadAddIn method, loading a IExternalApplication from another IExternalApplication will cause the loading IExternalApplication to be called twice.

Same result with LoadPackageContents method

IExternalCommand -> IExternalCommand (ok)

IExternalCommand -> IExternalApplication (ok)

IExternalApplication -> IExternalCommand (ok)

IExternalApplication -> IExternalApplication (loads twice)

All tested in R2018, this behaviour existed already in R2014

Any further thoughts or idea?

I can set a EnvironmentVariable on first load to check against, and if already set stop executing the rest of the code in IExternalApplication.OnStartup preventing the creation of duplicate Ribbontabs/panels. 

(don't know if this creates other problems...)

Or just stick with manual update of addin.

Ps. I'm using R2015-R2019 (R2020 still to do)

My addin also doesn't use ApplicationInitialized or so, it can be loaded mid-session even with documents already open. All per-document variables are created as needed.

Best regards,

Michel

[NonicaTeam]

Thanks for your posts!

We had the same issue and had to also use an environment variable as a work around. 

Hopefully this gets fixed as some point

[jeremy_tammik]

This will not be addressed in any way unless we submit a change request to the development team. I suspect nobody has done so yet. I also suspect that if we do submit such a change request, the development team will very kindly explain to us the intended use of the system and why the behaviour we observe is by design. Therefore, if you have a working solution for your specific situation using an environment variable, the most effective way forward for all of us is probably to leave it the way it is. Don't fix a working system. Congratulations on finding an efficient workaround.