Packaged release bootstrapper fails on mono #1901
Comments
glopesdev
added
bug
|
It's somewhat surprising you get to the |
|
Yup, everything works fine with the bootstrap UI, the start screen and main editor. The build kind title text also displays correctly which shows that we are loading the right assembly version. I mentioned this elsewhere but for completion here I also tested running the repackaged binary built on Linux on a Windows environment and it works fine there too, which suggests there might be a route to get a single repackaged binary that works cross-platform. |
This was actually a red herring. The real difference is the presence of In a more typical .NET app it contains a binding redirect for <?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Resources.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>This is done because the type reference embedded in resources is hard-coded to 4.0.0.0, and the resource loader extension junk relies on that to redirect the type reference to the appropriate assembly at runtime. For Bonsai I'm relying on our Easiest workaround for now is to distribute We could also try to establish a best practice of ignoring the entire Bonsai workspace directory and explicitly un-ignoring files like |
|
TL;DR: Fixed it #1902 So this exception comes from here: RuntimeResourceSet.cs:200 Emphasis on the Turns out that Mono loads the assembly more than once, and that the .NET Runtime (Mono or otherwise) loads a new assembly every time you call the (This is something that has burned Bonsai before it turns out: a0b3f9e) Basically we were trying to use Fix was pretty simple, just have to cache the result: #1902 |
Also added copying the NuGet.config to the repack output directory for ease of testing. Fixes bonsai-rx#1901
|
As an aside I'm not totally sure why the binding redirect fixes it. Mono actually has observably different load behavior compared to .NET Framework in general. For example, the following prints AppDomain.CurrentDomain.AssemblyResolve += (_, args) =>
{
if (args.Name != "Whatever")
return null;
byte[] assemblyBytes;
using (Stream s = File.OpenRead("ClassLibrary1.dll"))
{
assemblyBytes = new byte[s.Length];
int readLength = s.Read(assemblyBytes, 0, assemblyBytes.Length);
Debug.Assert(readLength == assemblyBytes.Length);
}
Assembly result = Assembly.Load(assemblyBytes); ;
Console.WriteLine($"Resolving '{args.Name}' to {result.FullName}");
return result;
};
Assembly a1 = Assembly.Load("Whatever");
Assembly a2 = Assembly.Load("Whatever");
Console.WriteLine(ReferenceEquals(a1, a2));I imagine that the binding redirect (perhaps combined with the strong name) causes it to not do the redundant resolve for some reason. |
Also added copying the NuGet.config to the repack output directory for ease of testing. Fixes bonsai-rx#1901
Running the latest packaged release of the bootstrapper on Linux mono fails with the below stack trace. Compiling the project from source with
dotnet buildis successful however, so the suspicion is this might be possibly related to ILRepack and embedding ofSystem.Resources.Extensions.The current workaround is to build from source.
The text was updated successfully, but these errors were encountered: