Deploy & Install: Manifest ClientId

We talked about the Revit manifest file in detail and analyzed what may affect its integrity before. It is obvious that the manifest property or attribute AddIn Type, Assembly, and FullClassName cannot have any typos, but wait, what about the ClientId?

The same, it cannot have less or more characters or any typos. If the following invalid ClientId (please note the last small tiny x thing) is provided to any AddIn manifest:

The Invalid Format AddInId error message will show up when Revit parses the manifest file:

It is easy to understand as the ClientId is a kind of GUID and has to follow its rules.

OK, so far so good.

Now another case, the ClientId is good but it appears in two different places either in a single manifest file or different, what will happen?

Revit will complain about Duplicated AddInId like follows:

Another situation, if two Applications have different good ClientId but point to the same namespace and class name of a single good assembly as the following files indicate:

<?xml version="1.0" encoding="utf-8"?>
<RevitAddIns>
<AddIn Type="Application">
  <Assembly>C:\Temp\RevitAddinTest\bin\Debug\RevitAddinTest.dll</Assembly>
  <FullClassName>RevitAddinTest.ExtApp</FullClassName>
  <ClientId>5ad0b84c-b30b-46fb-b9ff-f4bb4a907509</ClientId>
  <Name>RevitAddinTest</Name>
</AddIn>
</RevitAddIns>

<?xml version="1.0" encoding="utf-8"?>
<RevitAddIns>
<AddIn Type="Application">
  <Assembly>C:\Temp\RevitAddinTest\bin\Debug\RevitAddinTest.dll</Assembly>
  <FullClassName>RevitAddinTest.ExtApp</FullClassName>
  <ClientId>5ad0b84c-b30b-46fb-b9ff-f4bb4a90750a</ClientId>
  <Name>RevitAddinTest</Name>
</AddIn>
</RevitAddIns>

How does Revit deal with it?

Revit will load the same assembly and register the same Application twice! The tricky part is that when the same Ribbon Panel is going to be created and added to the Revit Ribbon twice, an error saying that the panel with the name already exists will come up:

What is the real problem here? Is there anything wrong with the Ribbon Panel creation and registration code in the good single assembly?

No likely. Why does the assembly have to bother to detect whether it is being loaded twice or more by the same Revit and create different ribbon panels if true?

OK. If we have to answer YES, is there a provided mechanism for the assembly to know if it is being loaded multiple times into the same Revit session? Oh, no. Maybe this mechanism has to be invented by the assembly itself.

Again, what is the real problem here then?

It is with the separation of the ClientId (AddInId as metioned by the UI) and the Assembly/FullClassName. Obviously, the ClientId is trying to identify the full Assembly path + FullClassName of the Application or Command, but in fact they are pretty the same things. As we know, as far as COM objects are concerned, they have both an application id (pretty much the same as the Assembly + FullClassName here in the Revit manifest) and a class GUID, each of which can find the matching other part. Since they are all coded in the COM source internally rather than specified in a text/xml file externally and the access to both of them is very limited in the outside world, the chance to mix them up is very slight, unlike the Revit manifest situation we are talking about here.

In addition, the manifest addin ClientId is most likely created dynamically by installers and the same manifest deployed onto different systems. This will make the same Assembly+FullClassName have different ClientId on different computers or even on a single one but for different installs or users.

Then can it still be called GUID?

It can still be GU but not ID!

Any suggestions?

Sure. From the API side, does it not seem better to force the ClientId (supposing it is really necessary) to be specified in assemblies for each Application/Command class like what we do to the TransactionMode and the RegenerationOption?

In this way, it is safe, consistent, and real GUID. And the ID will never be lost.

From the programming perspective, considering the established fact, is it not a good practice to generate a manifest including the ClientId automatically only once for each Application/Command creation and keep the ID and file along with the Visual Studio project?

During installation, the same manifest file can be deployed to different users, systems and computers. Of course, the assembly path still needs to be updated dynamically by the installer during installations.

RevitAddinWizard can help do so, more specifically its project wizard, Application Manifest Creator and Command Manifest Creator item wizards, AddIn Register, and Revit Manifest Organizer. The Detect Duplicate feature of Revit Manifest Organizer can help check the manifest files as specified in a folder for duplicates including but not limited to ClientId.

Deploy & Install: Revit Application Addin Manifest

Deploy & Install: Revit Command Addin Manifest

Deploy & Install: Revit Addin Roaming Folders

Deploy & Install: The Registry of Revit 2011

Deploy & Install: The Registry of Revit 2012

Deploy & Install: Where Are Revit Products Installed

Deploy & Install: Manifest Navigator of RevitAddinWidget

Deploy & Install: RegEdit Launcher of RevitAddinWidget

Deploy & Install: Revit Locator of RevitAddinWidget

Deploy & Install: Manifest Encoding

Deploy & Install: Manifest Loading

Deploy & Install: Manifest ClientId