Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2023.0.1 requires exact Microsoft.Bcl.AsyncInterfaces version #1287

Closed
mus65 opened this issue Jan 3, 2024 · 11 comments
Closed

2023.0.1 requires exact Microsoft.Bcl.AsyncInterfaces version #1287

mus65 opened this issue Jan 3, 2024 · 11 comments
Milestone

Comments

@mus65
Copy link
Contributor

mus65 commented Jan 3, 2024

I noticed that #1268 introduced a dependency to an exact version of Microsoft.Bcl.AsyncInterfaces (8.0.0) . I assume this was a copy&paste mistake from the SshNet.Security.Cryptography dependency. Please changes this to a minimum version (>= 8.0.0), otherwise projects using SSH.NET will run into issues when trying to upgrade to a newer Microsoft.Bcl.AsyncInterfaces release.

@darkoperator
Copy link

seems I hit an issue with this in Posh-SSH

@mus65
Copy link
Contributor Author

mus65 commented Jan 4, 2024

@darkoperator doesn't look like the same issue. This issue is about the too strict version constraint which would cause nuget restore failures if other projects depend on another Microsoft.Bcl.AsyncInterfaces version. Your issue seems to be about the dependency itself missing.

@darkoperator
Copy link

ok, sadly my module is broken because of this dependency on PS 7, it is one weird bug I can not figure out so sticking with the previous nugget for now

mus65 added a commit to mus65/SSH.NET that referenced this issue Jan 5, 2024
This technically fixes 2 different issues:
- previously SSH.NET would require exactly(!) version 8.0.0, which would
  cause issues in the future if e.g. a project using SSH.NET would
  try to update to version 9.0.0. In this case the constraint on the
  exact version would cause NuGet to refuse to upgrade to 9.0.0 (sshnet#1287)
- PowerShell Core seems to have problems with Version 8.0.0, therefore
  downgrade the requirement to 1.0.0 (see darkoperator/Posh-SSH#558)
mus65 added a commit to mus65/SSH.NET that referenced this issue Jan 5, 2024
This technically fixes 2 different issues:
- previously SSH.NET would require exactly(!) version 8.0.0, which would
  cause issues in the future if e.g. a project using SSH.NET would
  try to update to version 9.0.0. In this case the constraint on the
  exact version would cause NuGet to refuse to upgrade to 9.0.0 (sshnet#1287)
- PowerShell Core seems to have problems with Version 8.0.0, therefore
  downgrade the requirement to 1.0.0 (see darkoperator/Posh-SSH#558)

I had to re-enable AutoGenerateBindingRedirects, otherwise there is a
FileLoadException with net462 in one of the tests. I don't know why this
was disabled in 3ecbd10 .
WojciechNagorski pushed a commit that referenced this issue Jan 5, 2024
This technically fixes 2 different issues:
- previously SSH.NET would require exactly(!) version 8.0.0, which would
  cause issues in the future if e.g. a project using SSH.NET would
  try to update to version 9.0.0. In this case the constraint on the
  exact version would cause NuGet to refuse to upgrade to 9.0.0 (#1287)
- PowerShell Core seems to have problems with Version 8.0.0, therefore
  downgrade the requirement to 1.0.0 (see darkoperator/Posh-SSH#558)

I had to re-enable AutoGenerateBindingRedirects, otherwise there is a
FileLoadException with net462 in one of the tests. I don't know why this
was disabled in 3ecbd10 .
@mus65
Copy link
Contributor Author

mus65 commented Jan 5, 2024

Fixed by #1288

@WojciechNagorski WojciechNagorski added this to the 2024.0.0 milestone Feb 22, 2024
@WojciechNagorski
Copy link
Collaborator

This issue has been fixed in the 2024.0.0 version.

@ThatBrianK
Copy link

ThatBrianK commented Oct 29, 2024

Hi, I just wanted to chime in and say that this fix actually broke the library I had built. I now get an error:

Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or
one of its dependencies. The system cannot find the file specified.

I do not get this error with 2023.0.1 but with any higher version I do. I tried 2 tricks I could find online but neither of them worked.

  1. check "auto-generate binding redirects
  2. adding an App.config file containing the following:
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" /> </dependentAssembly> </assemblyBinding>

I'm not really sure where to go for help. Thanks!

@mus65
Copy link
Contributor Author

mus65 commented Oct 29, 2024

This does indeed look like missing binding redirects. There is no text on 2. , did you forget to paste it?

The fix depends on your application. For modern .NET, the binding redirects should always be automatically generated unless you explicitly disable them. For legacy .NET framework it can be more complicated.

@ThatBrianK
Copy link

ThatBrianK commented Oct 29, 2024

thanks, I forgot to enclose it as Code.
I'm using .NET Framework 4.8.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" /> </dependentAssembly> </assemblyBinding>

@mus65
Copy link
Contributor Author

mus65 commented Oct 29, 2024

Looks correct in general. Are you using a web application? In that case this must be in web.config, not app.config IIRC. Other than that, hard to tell without a minimal repro...

@ThatBrianK
Copy link

Thanks for responding! It's not a web application. The only thing of note is that it's a class library used as a plugin with another application. I've tried both including and omitting the Microsoft.Bcl.AsyncInterfaces.dll file alongside the Renci.SshNet.dll file in the same directory as my dll but it did not make a difference

@mus65
Copy link
Contributor Author

mus65 commented Oct 29, 2024

The binding redirect needs to be on the application using the library, not the library itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants