Editor assembly loading issues - "unloading broken assembly", "could not load signature"

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 attached a .zip file with both projects.

Can I do anything to prevent these errors?

 

I believe the build works correctly because all of the assemblies get moved to the same folder (Data/Managed), so there are no issues resolving them.

 

@Tautvydas-Zilys @JoshPeterson @joncham @jonas-echterhoff

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.

https://forum.unity.com/threads/err...on-which-folder-it-is-in.766583/#post-5113808

 

Any news on this @Tautvydas-Zilys @JoshPeterson @joncham @jonas-echterhoff ???

 

Case 1196416

Case 1193928

 

@Tautvydas-Zilys Did you get a chance to take a look at it?

 

https://issuetracker.unity3d.com/is...assemblies-depending-on-their-place-in-assets

 

Any news? It's been two months since this thread creation.

Can you reach that team @Tautvydas-Zilys ?

 

@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.

It should work...

 

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).

 

@HaraldNielsen I recently saw in 2020.1a16:

Scripting: Emit error when validating assembly references for strong named assemblies. (1196416)

https://issuetracker.unity3d.com/is...when-assembly-dependency-is-in-another-folder

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?

 

Ok, thanks.

Please, keep me updated with that feature.

I understand that this feature will also be evaluated before compilation inside editor and not only when publishing a build.

 

@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.

 

@HaraldNielsen @xoofx

Case 1193928
Case 1196416

I've tested in 2020.1.0b5 and it keeps failing, in fact, now it doesn't even work in the same folder anymore. I mean, it's broken even more. It used to at least work in the same folder, now it doesn't:

Same folder:



Different folder (UPM packages using @xoofx https://github.com/xoofx/UnityNuGet):



https://issuetracker.unity3d.com/is...when-assembly-dependency-is-in-another-folder

https://issuetracker.unity3d.com/is...assemblies-depending-on-their-place-in-assets

https://forum.unity.com/threads/err...es-depending-on-which-folder-it-is-in.766583/

 

@HaraldNielsen In 2020.1b it only works unchecking "Validate References" if it's in the same folder. On different folder it doesn't work even If I uncheck "Validate References".

It's someone working on bindingsRedirect feature? Estimated ETA?

 

Any updates on this?

 

I'm having the same issue in 2019.4.9f1. I used the workaround using the dlls in the same folder, and while I do get the following warning, it seems to work. Proper redirect bindings would be really nice though.

 

its been awhile, I also have this problem, was working until it didnt.

 

Thanks Harald, appreciate your efforts

I'm sure people consider this edge case but with the direction .NET is going I think Unity has to keep up to date within the dotnet ecoystem and play nicely there

I'm afraid for you that the next step is to get a nuget package system working. A few Unity packages already provide assemblies, either Unity has to keep track of their assemblies within all their packages, which may leave their hands tied, or add nuget support so that packages and project can negotiate versions nicely.

That would also make it better for package developers like myself. Playing with other packages and required assemblies is a nightmare at the moment. For example the ECS system brings in a different version of Newtonsfot Json, and also
System.Runtime.CompilerServices.Unsafe. I have a package for providing microsoft extesnsions logging, and another for NLog. The introduction of the assembly in ECS broke things for me

 

As I saw you are also targeting 2019.4.x LTS as well, I'm glad you care about those of us who are "tied" to the LTS versions.

 

This effects another open issue so linking that here as well.

https://issuetracker.unity3d.com/is...when-assembly-dependency-is-in-another-folder

 

@HaraldNielsen I have some doubts with that "new checkbox":

1. Would it fix the fact that dlls can be in different directories? I remember you mentioned something about a bug in Mono. This is what limits us a lot since we have converted to UPM packages and each one has its own dlls.
2. I understand that if we check that checkbox it will still validate the absence of a dependency anyway, right?

And finally any ETA on 2019.4.x LTS? Thanks!!!

 

I see that it's finally fixed in:

2021.1.0a2
2020.2.2f1
2019.4.17f1

@HaraldNielsen I have found a small bug in the editor and if I have configured the backend scripting in IL2CPP I get the checkbox disabled because I understand that this problem does not affect IL2CPP but in the editor uses Mono. To solve it I have had to change the backend scripting to Mono, disable the checkbox and put IL2CPP back.

Is there any way to remove this annoying warnings?

I tried this thread but it didn't work and I have no way to check if it is reading the app.config file or not:

https://forum.unity.com/threads/dependency-on-newtonsoft-json.814128/#post-5398014

 

@HaraldNielsen Case 1307810

What about this problem @HaraldNielsen ?? I remember that you played with app.config files and made some tests with them.

 

Ping @HaraldNielsen

 

In this case I meant this:

 

@HaraldNielsen Thanks for all your work on this issue; it has been very informative. What exactly is the location of the checkbox you described above? I don't see any checkbox referring to "Signed Version validation" in the Editor Preferences or Project Settings of my Unity 2021.3.10f1 project. I am using IL2CPP, so maybe the bug that @bdovaz mentioned above is related?

Also, how does all of this change when importing assemblies as packages, not assets? I am using the excellent, open-source UnityNuGet tool (built by a Unity dev as I understand) to import NuGet packages as UPM packages, and seeing the same mismatched assembly version errors. Unfortunately, I can't just uncheck "Validate References" on any of the UPM-imported assemblies (is that the checkbox we're talking about?) because these assemblies aren't under Assets/ so the checkbox is disabled (and wouldn't update the project for all collaborators anyway).

 

Ah nvm, I found the checkbox: "Project Settings > Player > Other Settings > Configuration > Assembly Version Validation (editor only)". The tooltip on this checkbox is also very nice, explaining that the option only affects resolution for Strong Named assemblies. This fixes my UPM import issue as well!