Plugin Assembly Fullnames Must be Unique

09/05/2020 Ryan Perry Comments 0 Comment

The Problem

When registering a plugin on the Common Data Service, the Plugin Registration Tool errors:

Plug-in assembly fullnames must be unique (ignoring the version build and revision number).

The detailed error log mentions a PluginAssemblyService, but doesn’t give much further indication as to what is causing the error. You’ve double checked the name of your assembly. It is identical. What gives?

The Helpful Bit

The answer is rooted in a core .Net concept: Strong Named Assemblies. The assembly must be strongly named and the fully qualified strong name must match. This is mentioned, but not explained thoroughly in Microsoft’s plugin walkthrough step, Sign the Assembly.

The fully qualified strong name consists of 4 parts, ALL of which must match.

The Text Name: This is the name of the DLL file. Chances are, if you copied your .cs file between solutions, the solution, and project filename may be different. Even if renamed, the DLL produced may still differ, based on project settings, which you can update in the project properties. But, you already checked this, right?
Version Number: The 4 parts, 1.0.0.0, are Major.Minor.Build.Revision. Per the error, the last two: Build and Revision can differ, but the major and minor version numbers must match. This is because of the potential for breaking changes that may occur to other dependent components if you release a major update with breaking changes, which is one of the key criteria for a major version increment. If you incremented your plugin version from 1.0.0.0 to 1.1.0.0, it must be re-registered.
Cultural Information: Most likely you haven’t changed this, but in your project settings, you can target an assembly for a specific culture, such as having return values in a different language or format. For versioning reasons, this must match.
Public Key Token: This is the 2nd likely culprit and is automatically generated using your project signature key when you compile your plugin. More on this below.

Checking for a Match

You can check the strong name values on the registered plugin via the plugin registration tool by selecting the plugin, properties:

The same information for your new assembly can be seen in your project properties, or by right clicking the .dll file in windows explorer, except for the Public Key Token, which you can retrieve via the Visual Studio Command Prompt command:

sn -T <AssemblyName>

My Public Key Token Doesn’t match. Why?

Before you first registered the plugin, you were required to sign it, using a strong name key file (.snk), referenced in your project properties under ‘signing.’ This file is used to generate the Public Key Token. If you moved code between solutions, chances are you created a new .snk key file.

Even if you used the same password and name for the .snk file, the internal keys generated will be different. Your password protects the keys contained in the file, but it used as a key itself. But, but may still have the old snk file somewhere, possibly with the exact same filename. If so, simply copy it over, update your project settings to use it and recompile. Problem solved. You can get back to work.

I Lost my Original Key File. Now What?

Use another lock & key. Create a new plugin registration using the new DLL. If this is a standalone plugin, dependencies won’t likely be an issue. For a custom workflow activity, you will need to recreate the steps in any workflows that reference it. Unfortunately, other plugins you have generated with the lost key will also need to be updated.

Can I Make a New Key?

The strong name is implemented primarily for version control so that dependent pieces of code don’t break if you update your plugin. While the Public Key Token sounds like a solid security measure, according to Microsoft:

“Do not rely on strong names for security. They provide a unique identity only.”

So, how does it work, and can you get around it?

In short, unlikely. The .snk file used to sign the assembly contains a public and private key. When you compile the plugin, the assembly contents are hashed. This compile-time hash is encrypted using the private key and stored within the assembly manifest, as are the public key & public key token. At runtime, the encrypted hash is decrypted using the public key. The plugin is again hashed and the two hashes are compared to verify the contents were not changed.

The public key & token are both always public. If you happen to have another DLL that was generated using the same .snk file, (IE if you export a solution containing the existing plugin), you can use ILDASM to extract the full public key, and insert it into your new DLL, along with the public key token. The plugin assembly tool might be fooled, but at run-time, the plugin likely won’t work because the DLL was generated using a different private key.

Next time, be sure to keep track of your key file.

Conclusion

To deploy a plugin, the strong name, consisting of the name, public key token, major & minor version number, and cultural info must all match. If you prematurely incremented your version, you may be able to revert the version number. If your token doesn’t match due to having used a different key, you can recompile with the old key, if you have it. Otherwise, create a new registration.

Reference Material