Building Ribbon Tabs while using Addin-Manager

[Anonymous]

I wonder if anyone else has had this kind of problem.

I am using the add-in manager to help me debug Revit .net applications and commands.

One of the things I am doing is adding Ribbon tab/panel/button combinations.

(I have tried it both in the startup() of the application, and also by making an external command for the purpose of ribbon-building).

The problem that I seem to have is that when I create a button on the ribbon, I have to supply it with the assembly to use.  I have been using Assembly.GetExecutingAssembly to put the path on the assembly reference, and this does work.  The problem is that when the add-in manager is used to re-load, it puts the new assembly in a different temporary location and the button on the ribbon no longer points to the current re-built assembly.

As a result, I get this sequence:

There are two commands - one for building the ribbon, and one to do an actual task (I will call it 'task_command')

1. Don't load the add-in when Revit starts.

2. Use Add-in Manager to run a command to build the ribbon panel and add a button pointing to the assembly and "task_command".

3. I can click on the button and it runs the task_command fine.

4. In Visual Studio, change the program to modify task_command and re-build.

5. Go back to add-in manager and run the task_command.  This shows the new modified behaviour.

6. Click on the ribbon button for task_command, and it shows the old behaviour.

In the long run, I expect to simply build the ribbon once on startup, and the buttons will point to a stable assembly location.

But - for developing and debugging, I find this frustrating.

Perhaps I am just missing a more sensible way to set up the debugging environment.

thanks in advance for any help on this...

[Anonymous · Accepted solution]

Try using GetCallingAssembly()

[Anonymous · Accepted solution]

Or GetAssembly (typeof (YourAddinClassGoesHere) )

[Anonymous]

Thanks for your suggestions, Scott.

I tried both GetCallingAssembly and GetAssmbly(typeof...).

They both work as well as the GetExectuingAssembly, but unfortunately with the same limitation.

I guess they are all referring to the assembly path at the time when the button is created - not at the time when the button is clicked.

So any time the add-in manager is used to reload the .dll in a different place, it becomes obsolete.

I will keep looking for an alternative to keeping buttons current with the add-in manager.

Abba

[jeremytammik]

Dear Abba,

Oh dear, sorry to hear that did not help. 

Looking forward to hearing what alternative method you come up with.

Thank you!

Cheers,

Jeremy

[Anonymous]

I see your problem now, sorry,  my suggestions were based on my assumption that AddIn Manager was masking the get assembly call. I've never used AddIn Manager so was unaware that it copies and renames the assembly each time its loaded. in that case, couldn't you just check if the command button exists then remove it and create a new one at each call to OnStartup()?

[Anonymous]

Hi Scott - thanks for your contribution.

I have been trying to do exactly what you are suggesting - i.e. to 'remove'
the command button and make a new one. (In fact, I am making a whole new
Tab/Panel/Button), but I cannot seem to find a way to delete these ribbon
elements.



The "remove" method seems to take a tab off the ribbon, but it still seems
to be there, preventing me from creating another tab with the same name
(changing it's name and title doesn't seem to help!) Do you know how to
actually wipe out a ribbon element?



In the final working system, the OnStartup() method will clearly work, since
the buttons won't exist and the program will not be changing.

While testing, I want to be able to recompile and run things without closing
and restarting the revit session. This is what the addin manager lets me
do.

It seems to work except for the ribbon button issue.



Is there a better way to be able to debug/modify a program without
restarting revit?

[jeremytammik]

Dear Abba,

Several people have reported various solutions to debug and modify a program without restarting Revit:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#5.49

Please let us know if you get one of them to actually work  🙂

Thank you!

Cheers,

Jeremy

[Anonymous]

try using the functionality of adWindows.dll (namespace Autodesk.Windows) to find and remove the existing command button. I've not tried to delete and recreate a button with the same name before so maybe it does still hang around even when using AdWindows, but its worth a try I guess., for testing purposes you could also just generate a random or incremental name for the button each time. sorry that's about all I've got. Only other suggestion I have is to debug the old-fashioned way like I do where I load Revit from the debugger, test, kill Revit, make changes, rebuild and try again. If your computer is quick enough that Revit Only takes a few seconds to load its not that painful.