Precompiled Assembly Exception: Google.Protobuf

[FruitJuice]

What is the current behaviour? When importing gRPC, or any other packages containing gRPC throws error that there are multiple Google.Protobuf assemblies and it doesn't know which to choose.

Please provide the steps to reproduce, and if possible a minimal demo of the problem: You can manually drag the .DLL of Google.Protobuf into project as a plugin, or install another package containing it and will throw errors. Have tried manually, through a unitypackage and with npm. Example add this package to the project and will get errors. https://github.com/oshoham/UnityGoogleStreamingSpeechToText

What is the expected behavior? That Yarn Spinner uses only it's bundled Google.Protobuf Assembly, that if any other ones are added to the project it won't try to use them.

Please tell us about your environment:

• Yarn Spinner Version: 1.2.0 - develop
• Unity Version: 2019.3.12f1

Other information The specific error. The errors it mostly links to are in the VoiceOver scripts, which I think are still in the develop branch and hasn't been released to master.

PrecompiledAssemblyException: Multiple precompiled assemblies with the same name Google.Protobuf.dll included for the current platform. Only one assembly with the same name is allowed per platform.

[FruitJuice]

Don't think it could be solved by YarnSpinner. Or at least not really sure how. Would need to try and make it so that the library has another name inside YarnSpinner so it wouldn't conflict with other packages/projects. Don't really think that's feasible? Or I definitely don't feel I know enough to do that.

[FruitJuice]

Looking at it more, I do think maybe it's something needed to fix within YarnSpinner but I'm not very familiar with how to configure libraries and dependencies. The reason why I think it's a YarnSpinner problem is because if the DLL Google.Protobuf is placed inside the YarnSpinner Folder in Runtime, other packages and scripts don't detect it and run their own version of Google.Protobuf.

However YarnSpinner will conflict with any other instance of Google.Protobuf within the a project. If anyone knows any tips or ways to go about it would appreciate it, would try contributing to YarnSpinner.

[Haapavuo]

I am quite sure that this is a duplicate to: https://github.com/YarnSpinnerTool/YarnSpinner-Unity/issues/19

[xsduan]

One idea is to use OpenUPM's Nuget proxy, which was added a while back: https://openupm.com/nuget/#using-uplinked-unitynuget

This ~~could also~~ would need to apply to YarnSpinner itself but I assume it's already taken care of

[desplesda]

We're continuing to look into this, and right now the best approaches we have are:

1. Use a tool like ILRepack to merge our dependencies into an isolated DLL that won't conflict with any other DLLs, or
2. Remove our dependencies entirely.

Option 2 would be preferable, but is currently unrealistic. Option 1 is doable, but challenging (and has some drawbacks of its own, like duplicated code.)

For now, we'll document an officially endorsed workaround and release that as part of 2.0, and I'll defer this issue to a post 2.0 release.

[Sygan]

So I've stumbled upon this issue trying to install Yarn Tool in my project. In my case, this happened with a different .dll file - System.Runtime.CompilerServices.Unsafe.dll

I had a conflict between Yarn and my internal package that has some core scripts for all of my projects. The fix for this is actually pretty simple and if you do this for libraries that you're using nobody else should have these problems. I'm gonna show this in my package example.

What you need to do is first change the file names of the .dll you're including to something unique i.e. instead of System.Runtime.CompilerServices.Unsafe.dll use Yarn.System.Runtime.CompilerServices.Unsafe.dll.

Then you need to disable them from being Auto Referenced. Uncheck the "Auto Reference" field in the inspector for each of your libraries.

Finally, in your Assembly Definitions, you need to select "Override References" and set all of these libraries manually.

This should fix these issues if somebody is using a different package that hasn't implemented this fix. From looking at some of the official Unity packages they are doing exactly the same, so I think it's as close to the official solution as possible.

[bremea]

Hey, I'm having this issue as well. Was an official workaround ever documented?

[aecanales]

Ran into the same issue as @Sygan (with the same .dll actually!) and solved it with your instructions. Thanks for the detailed explanation!

[desplesda]

I've implemented the following changes:

• All dependency DLLs that we ship (that is, any DLLs that aren't YarnSpinner.dll or YarnSpinner.Compiler.dll) are now renamed to have a Yarn. prefix. That is, Google.Protobuf.dll is now Yarn.Google.Protobuf.dll, and so on.
• The meta files for all these renamed DLLs have been updated to make them not auto-referenced.
• Reference overrides have been set up for YarnSpinner.Unity.asmdef and YarnSpinner.Unity.Editor.asmdef to make them refer to the renamed DLLs.
• The 'Update Yarn Spinner DLLs' action, which compiles the Yarn Spinner core libraries and submits a pull request to update the Unity project, has been updated to automatically rename the dependency DLLs before creating the PR.

It looks like everything is working ok - the samples are working fine, playmode and editmode tests are passing. I'm happy to call this one done; if we get reports of anything breaking, it's straightforward to roll this change back.

@Sygan, thank you very much for such a detailed diagnosis and fix! This would have been a lot harder to solve without your contribution.