Upgrading TimeZoneConverter breaks TimeZoneNames

[jnyrup]

After upgrading TimeZoneConverter to v2.3.1 TimeZoneNames throws an exception

System.IO.FileNotFoundException: Could not load file or assembly 'TimeZoneConverter, Version=2.3.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

I guess this is because the assembly version of TimeZoneConverter is 2.3.1.0?

Repo:

ClassLibrary13.zip

[mattjohnsonpint]

Thanks, I'll look at this asap.

[mattjohnsonpint]

This appears to be a common problem with referencing .NET Standard projects from .NET Framework when there are version mismatches. See dotnet/standard#481. To workaround, I'll update TimeZoneNames to explicitly target 2.3.1 of TimeZoneConverter - but IMHO this shouldn't have to be the case.

[mattjohnsonpint]

Fixed by publishing TimeZoneNames version 3.3.1 that references TimeZoneConverter 2.3.1. Update both and you should be good. Hopefully the .NET team can address the larger issue.

[jnyrup]

Wauw, that was fast!
Thanks a lot.

[mattjohnsonpint]

As an alternative, you can work around this issue by manually adding an assembly binding redirect to your app.config or web.config (of the main application).

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="TimeZoneConverter" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.4.1.0" newVersion="2.4.1.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Substitute 2.4.1.0 for whatever version of TimeZoneConverter you have installed.

[mattjohnsonpint]

Need to get to the bottom of this. At minimum, need to find a way to force the above binding redirect to be installed into the consuming application. Anyone have any ideas about that?

[smourier]

Hi!

Now that a strong name has been set to TimeZoneConverter (3.0.0), the redirect trick doesn't work any more? Shouldn't you publish a new TimeZoneNames nuget? Or do you have a workaround?

Thanks for this great library anyway.

[smourier]

In the mean time, I've used a trick like that (the dll was there, loaded in the AppDomain, but it just cannot be redirected to by config, I guess because now it has a strong name and redirects don't support publickeytoken changes):

AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve;

private static Assembly OnAssemblyResolve(object sender, ResolveEventArgs args)
{
    if (args.Name.StartsWith("TimeZoneConverter,"))
        return ((AppDomain)sender).GetAssemblies().FirstOrDefault(a => a.GetName().Name == "TimeZoneConverter");

    return null;
}

[mattjohnsonpint]

@smourier - Yep. I'll be doing that soon. I want to get mattjohnsonpint/TimeZoneNames#50 completed first.

[mattjohnsonpint]

I've release TimeZoneNames 4.0.0, which is strongly signed and takes a dependency on TimeZoneConverter 3.0.0, which is also strongly signed. I believe this should enable all of the assembly redirection stuff properly, so I'm closing this issue for now. Please let me know if you still find any difficulties. Thanks.