Skip to content

IFileSystem moved to a separate nuget, creating a dependency hell in my project #1337

Description

@borisf94

Describe the bug

I have an issue with a project I work on,
My project depends on a third party that uses TestableIO ver 22.
My project also depends on another third party that uses TestableIO ver 21.

In the build directory I have ver 22.
When trying to execute code that uses ver 21 I get an exception:

System.TypeLoadException: 'Could not load type 'System.IO.Abstractions.IFileSystem' from assembly 'TestableIO.System.IO.Abstractions, Version=22.0.15.0, Culture=neutral, PublicKeyToken=96bf224d23c43e59'.'

To Reproduce
Steps to reproduce the behavior:

  1. Create a console app.
  2. Reference TestableIO ver 22.
  3. Reference any third party that depends on ver 21 (I use https://www.nuget.org/packages/Azure.Bicep.Core)
  4. Instantiate a class from the older ver (in my case I've instantiated BicepCompiler)
  5. Run the project to see the error.

Expected behavior
The change from ver 21 to 22 should be seamless.

Suggested solution
For this to work seamlessly, we can utilize the TypeForwardedToAttribute

This way clients of ver 21 will still be able to find IFileSystem that moved to its new location.

Activity

  1. vbreuss commented on Sep 12, 2025

    @vbreuss
    Member

    I never used the TypeForwardedToAttribute. How would I go about adding this?

    Would I have to publish a new v21 version with this information or would I have to add this attribute to the a new v22 version?
    If it helps, I am open for a pull request, @borisf94

  2. borisf94 commented on Sep 12, 2025

    @borisf94
    ContributorAuthor

    Hey @vbreuss,

    Thanks for your attention :)

    I've created a PR: #1338

    The change is required in v22 assemblies. Once the code compiled against v21 runs with v22, it will try to resolve IFileSystem from TestableIO.System.IO.Abstractions.dll then it will find that the type was redirected to Testably.Abstractions.FileSystem.Interface.dll and will be able to resolve it from there.

  3. vbreuss commented on Sep 13, 2025

    @vbreuss
    Member

    @borisf94 : I released a pre-release version v22.0.16-pre.1. Can you check if this solves your dependency problem or if you need to redirect more interfaces?

  4. borisf94 commented on Sep 13, 2025

    @borisf94
    ContributorAuthor

    Thanks @vbreuss. checked the version, the IFileSystem related error is gone. But it seems I'm indeed missing more classes :(
    Could you please hint on the interfaces and classes that were moved?

    There is this PR: #1196

    Please let me know if there were other files as well. Will post a new PR to add those.

    Thanks

  5. borisf94 commented on Sep 13, 2025

    @borisf94
    ContributorAuthor
  6. vbreuss commented on Sep 14, 2025

    @vbreuss
    Member

    @borisf94 : The list in #1340 looked complete.
    I merged this PR and created a new pre-release version v22.0.16-pre.2. Can you check if this solves your dependency problem?

  7. borisf94 commented on Sep 14, 2025

    @borisf94
    ContributorAuthor

    Hurray! The issue solved for me 👍

    Thanks @vbreuss will you be publishing a stable version anytime soon?

  8. vbreuss commented on Sep 14, 2025

    @vbreuss
    Member

    Great to hear, @borisf94!

    will you be publishing a stable version anytime soon?

    Of course, v22.0.16 is already published 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type: bugIssues that describe misbehaving functionality

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions