Home

Problem with dependency that depends on older version of other dependency + GAC

benoitbenoit

We have a library that depends on System.Memory 4.5.5 (assembly version: 4.0.1.2) and at the same time have dependency to System.Runtime.CompilerServices.Unsafe 4.7.1 (assembly version: 4.0.6.0). Both of them are in GAC.
Unfortunately when we run that library in LINQPad and use AsSpan() method it tries to load System.Runtime.CompilerServices.Unsafe with assembly version: 4.0.4.1. And it result in a crash with FileNotFoundException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified..
I've tried implementing AppDomain.AssemblyResolve event and it seems to help in standard .NET executable but not in LINQPad.
I know that adding the assembly redirect will fix it. But I'm looking for a solution that won't require to add that redirect because this library will be used by multiple clients in a lot of LINQPad scripts.So ensuring such manual step in all those places is not feasible.

· Share on FacebookShare on Twitter

Comments

  • benoitbenoit

    Maybe there is some way to tell LINQPad that our library depends on 4.0.6.0 version of System.Runtime.CompilerServices.Unsafe and it would automatically add necessary binding redirects?

    · Share on FacebookShare on Twitter
  • JoeAlbahariJoeAlbahari

    Presumably you're using LINQPad 5? Does it help if you add explicit references to the latest versions of the System.Runtime.CompilerServices.Unsafe and System.Memory, either directly to the query or to your library (in the same folder)? This should make LINQPad generate binding redirects.

    · Share on FacebookShare on Twitter
  • benoitbenoit
    edited January 5

    Yes, I'm using LINQPad 5. I forgot to mention that, sorry :blush:.
    Adding the references explicitly to the script helps, it creates the redirects in the script's config file.
    I cannot add them to my library in the same folder as that library is in GAC.

    Our library is targeting environments with SharePoint so we need to be in the GAC and also our dependencies.
    We've dealt previously with similar issues by creating publisher policy "assemblies" that redirect via GAC.
    Unfortunately this is a library that we don't have access to SNK so we cannot generate those policy redirects.
    I've managed to make it work in IIS and SharePoint jobs by implementing AppDomain.AssemblyResolve that "redirect" the library. I've checked that it also works in simple console app.
    The console app also detected that redirects are need during the compilation and generated those redirects but it is working even with them removed.

    We're just having problems with LINQPad scripts. We use them quite often for some ad-hoc things and not ad-hoc things :). And it is not feasible to tell everybody to manually add those assembly redirect to their LINQPad.configs or to add reference to System.Runtime.CompilerServices.Unsafe directly to each script referencing our library.

    I'm implementing the workaround that catches FileNotFoundExceptions in every place we're using AsSpan as there is not much yet. But I hope to find better solution without that handling and without completely abandoning the usage of System.Memory library.

    · Share on FacebookShare on Twitter
  • JoeAlbahariJoeAlbahari

    Have you thought about using the 'Save as code snippet' feature? Then it will only require a few keystrokes to add the library plus the dependencies in one go.

    · Share on FacebookShare on Twitter
  • benoitbenoit

    I haven't used that feature before. I will probably use it more often now, but this is not a solution for this problem at this moment.
    If our library would be v1 and first time used by people in LINQPad then we could provide a guide with the snippet attached. But this library is old. And now in newly developed version I wanted to use AsSpan but this is causing issues. And I think that those snippets could have also became out of date with newer versions of the library. We would probably need to distribute it as Nuget package from the start but there was no Nuget when this all started :smiley:.
    I hoped that given this description it would be possible to get a fix in newer version but I understand that this is corner case to a corner case :). So I'll need to try to find a workaround.
    Maybe it's related to LINQPad 5 also supporting .NET 4.6? I've seen in Release Notes of the latest update that future versions will only support .NET 4.7.2 and 4.8. And I've read on Nick Craver blog that .NET 4.7.2 and later had some fixes around binding redirects. But on the other hand I have .NET 4.8 installed on my devbox where this happens.

    Thanks for you time and suggestions :smile:.

    · Share on FacebookShare on Twitter
Sign In or Register to comment.