I've created my own API messages with the InterApp classes from the Code Library to send messages from my Automation Scripts to my elements. Since I have many scripts using the same calls, I'm trying to centralize those API messages in an Automation Library script.
Because my API messages classes are inheriting from the Message class, the Library script will have a link to the Code Library.
Now the problem is that my script that makes use of these API messages will complain that the Message class exists in multiple assemblies. The Automation class needs a reference to the Code Library because the classes are inheriting from the Message class while my script that makes use of the Automation Library needs a reference to the Code Library to be able to send those messages to my elements.
I'm wondering if there is a way to make this work without duplicating all my API messages in all the scripts, resulting in adapting many scripts when changes are made in the API messages.
Not an uncommon issue indeed. This can also happen when working with dlls. Project A uses dll1 and dll2. But dll1 also uses dll2.
In these cases the most common way to fix it is to only reference dll1 and consider dll1 to be an 'enhanced version' of dll2.
For the class library it's a bit more complex because of the code generation happening automatically through DIS for only the items getting used. That means you cannot really make a single Automation Library Script that represents an 'enhanced class library' to be re-used across all scripts. Because that Automation Library Script won't ever generate the full class library. So any script using your library would have only partial access to the code from the base class library.
You're trying to mix two different techniques to code-reuse and it's never going to be very pretty. The Automation Library Script is pretty much just using dll's in the background. If you want to use the class library in that code you would need to get it as a dll. Something that isn't truly supported as of yet and we'd like to avoid too many corner cases for doing this. (Note that there are plans for next year to look deeper into using NuGets and perhaps offering that as an option next to code generation.)
Currently your best bet will be to fully focus on the code generation technique (with all advantages and disadvantages). Making a community class library with your API, where you indicate it's using the base class library as a dependency. Then reference your community class library wherever you need to use it.
The advantage is that you get code-reuse but all your scripts are still completely stand-alone. Not needing any setup or extra dll's manually installed. They can run on any agent of your cluster and get moved about without issue.
The disadvantage is that if you change the API in the community class library to a new version, you'll have to go over every script to update them to use the new version of your API.