I’m trying to get a bunch of the Microsoft.Extensions.* libraries in Unity and I’ve found it would work fine in a small quick project, but complains when I started separating them into different folders. It builds, but the editor complains:
The above errors do not seem to prevent a successful build, and the build demonstrates the libraries are working successfully.
I have found that the editor doesn’t report errors if all the assemblies are within the same folder:
Above is good! No errors
Above is bad, and the editor isn’t happy.
Both projects produce a build fine, but I’d rather get rid of the errors and enable the assemblies to be nested in their own folder - as I am making them modular through Unity’s packages.
I have the exact same problem. Initially I thought it was because of the Package manager but in reality it has to do with the separation by folders. In that thread I have a bug report and in successive posts a couple of examples in a very simple project.
We are using UPM internally for our code base and this is stopping us completely.
I added a better log message explaining what the issue is, hoping to get that included in the 2019.3 release. That it works when in the same folder is puzzling since it should be the same. But our team handling mono is notified.
I used dotPeek to add all the assemblies, and compare the version that are referenced. Other tools can do the same I guess, ilspy is also a good tool
@HaraldNielsen What I understand is that you aren’t going to fix my original issue and instead you see going to “break” what works if they are in the same folder.
In this case the supposed “fix” it’s going to result in more problems for us…
We hoped you will fix the original issue that prevented us to have assemblies in different folders…
On a traditional console, wpf or asp you can have higher dependencies like >= 1.0.0 for example and they are the same assemblies that I’m manually adding to Unity.
@bdovaz we are going to give a much more descriptive error so you can understand why you are getting these errors, and how to fix it. Right now you need to use external tooling for finding out why. You can disable our validation, and the error that we give also states that so the user can choose to ignore it, but that could lead to runtime errors.
On traditional application the same rule applies, but you can override these bindings so it will load another version than what its compiled against (How the Runtime Locates Assemblies - .NET Framework | Microsoft Learn), we dont support this, but you can make a feature request supporting it in the runtime.
Thanks but the ideal solution as I said below is to be able to configure bindingRedirects as in a traditional application.
What validation are you talking about? How can I disable it? What consequences can it have?
This would be the real solution.
Think that since Unity supports .NET 4.x and .NET Standard 2.0 it is very common in projects that are not games to do integrations that require libraries and in Nuget we have an immense amount of very popular packages to use with Unity. In that case is when we find conflicts that a “Package A” can have a dependency of >= 1.0 of “Package B” and “Package C” one of >= 1.1 of “Package B” and with the bindingRedirects we could solve it, otherwise it would be impossible.
Of course I’m talking about processing a “Publisher Policy File” (bindingRedirects) when compiling in both Editor mode (hitting play) and Player mode (published build like an *.exe).
Scripting: Emit error when validating assembly references for strong named assemblies. (1196416)
But this “correction” does nothing but annoy us because before it did not emit the error and it worked, now I understand that it is not going to work.
Could you take a look to see if we can create a “Publisher Policy File” (bindingRedirects) so that we can manually manage all this as it is done in Visual Studio?
@bdovaz yes its true that the error will also result with dll’s that did not give any errors before (because they where in same directory), but we added this error anyway because the information is valuable (This is not the first time we got an bug because of strong named assemblies and version mismatch). And you can choose to turn of the validation directly on the plugin, in its inspector.
I also agree that we should do the Publisher Policy File / bindingRedirects, its the correct thing to do, and would give a lot of value. Already talked with the VM team about about it.
@HaraldNielsen many month later I recently got a reply on case 1193928 and but I’m told they’re not capable of reproducing it and they immediately closed it.
The explanation they give me is very absurd. They tell me that the 12.x version of assembly B (Newtonsoft.Json) is not the version that assembly A (Microsoft.Extensions.Configuration.Json) expects, which is 11.x. But it is precisely because I reported it that this error only occurs when they are in different folders and not in the same one.
It is a behavior that has to be homogeneous because if it depends on the hierarchy of folders it has to be a bug.
Besides, it should support policy files to make a bindingRedirect and definitely fix this inconsistent behaviour.
