Office shared Add-ins does not load if the assembly name is same

I was working on a case where customer was trying to create two shared add-ins for Microsoft Word. However, only one of those add-ins gets loaded and the other one fails. Later, we found that the reason why this is failing is because the assembly name of both add-ins were same.

When we create a shared add-in for Office, Visual Studio uses “Project1” as the default assembly name for the add-ins. When .NET CLR tries to load the assembly, it fails because an assembly with the same assembly is already loaded. This is because .NET is not able to differentiate between both the assemblies.

There are multiple ways to solve this issue. Some of them are discussed below:

• Use different names for the assemblies
• Use different .NET Framework runtime
• Sign the assembly with strong name key

Changing the assembly name or the .NET framework helps to solve the issue. However, both these options may not be feasible all the times. Hence, the recommended way to resolve this issue is to sign the assembly using a strong name.