In case someone finds this useful, I will give a brief, somewhat frustrated account of what I have found.
1. I am trying to have a methodology where I can develop routines/interfaces and test without repeatedly restarting revit.
2. To do this, I have found the 'add-in manager' works pretty well.
3. Each time I 're-run' a command from the add-in manager, it creates a new .dll in a temp folder (with a unique name).
4. I have a routine that builds ribbon panels/buttons and links them to command functions, by specifying the DLL and command name.
5. The next time I re-run a command, add-in manager makes a new (different) copy of the dll, which is now different from the dll connected to the ribbon button.
I tested this by having the command print out the name of the 'calling' and/or 'executing' dll. At this point running the command from the button shows one .dll name, and running it directly from the add-in manager shows a different name. This was unwelcome, but at least seemed logical - each one is running the .dll that was 'current' at the time the 'invoker' was created.
6. So I figured that I need to re-build the button, so that it links to the latest (temp) version of the .dll. But I could not do this since the button already exists. Renaming the button/panel, etc did not seem to let me recreate it. So I figured, I had to delete the button and make a new one, which would be linked to the 'latest' .dll. That was the reason for the query about deleting ribbon elements.
Now here is where it gets wierd:
When it seemed imposisble to delete panels/buttons, but easy to hide them, I figured I would just keep creating a new panel with its own name each time I reload the command. (e.g. make panel0 the first time. Next time, make panel1 and hide panel0. etc.) My expectation was that each of these buttons would be linked to its own version of the dll, and the one that is visible would be linked to the latest 'temp' dll created by the add-in manager.
(Keep in mind this was not meant as a final solution but an experiment to figure out what is going on!)
When I did this, I found that **all** the buttons seemed to run the very first .dll, and the add-in manager ran the latest one. This seemed odd. Just to make sure each button really was what I expected, I put a different name on each button (which reflected the temp folder name based). So now, each button shows the name of the 'version' that was current when the button was created and linked to the dll.
The odd thing is that even though the buttons show different titles, they all seem to run the same .dll. And it is not the 'current' one that is run from the add-in manager.
So at that point, I have concluded that I don't understand how the buttons are linked to the routines they invoke. I have pretty much given up on trying to do ribbon-building with the add-in manager. I will just re-run individual commands from the add-in manager, and go back to building the ribbon with the 'startup' of the application. The ribbon will then get obsolete while using the add-in manager, but will be fine for users when things are loaded in the normal way (from .addin manifests).
You may think I have lost my mind in doing all this, but I am expecting to be debugging things on some large models and I really want to be able to work on things without restarting Revit.
It generally bugs me when I don't understand what is going on. This crazy exploration has not really helped. For the moment, I have given up on this.
If anybody can explain how the .dll is linked to the button, or how it is found when you click the button, I would love to know. ( I suspect there is probably some kind of 'search')
Sorry for writing such a long-winded explanation of this, but I get the feeling that some people are still looking for a nice environment for editting revit programs without restarting all the time. And hopefully, with the ability to manipulate ribbon panels in the process.
In case this long post discourages others from reply to my posts - I promise to keep things brief in the future.
Abba