DLL looking for wrong version RRS feed

  • Question

  • Hello, 

    I have developed a class that uses WinSCPnet.dll in Visual Studio 2015. While troubleshooting why it was looking for the wrong dll, I added the Nuget for it, getting the most recent version. The version we are using is actually a few before that, so I uninstalled the latest (using Nuget) and installed the version I want. Now, when it runs, it is looking for the newest version.

    System.IO.FileLoadException: Could not load file or assembly

    'WinSCPnet, Version=, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf'

    or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

    (Exception from HRESULT: 0x80131040)

    I have tried searching the registry, gacutil /u (which ran successfully and removed the dll but I still get this message), cleaned the project and rebuilt, deleted everything in bin and obj and rebuilt - what am I missing?


    • Edited by Randy Sims Wednesday, October 30, 2019 1:06 PM
    Wednesday, October 30, 2019 1:00 PM

All replies

  • Check this link at stackoverflow

    and check if the winscp.dll version in you bin folder matches the one printed here ( I just added the action stable nuget package to a project on my pc and the dll is version (the packa version completely differs from that version).

    Wednesday, October 30, 2019 2:22 PM
  • In general when you install an assembly it tends to put a binding redirect in your config file. So I'd start with checking your app's config file to see if there is a binding redirect which tells the runtime to redirect to the higher version. You might just do a global grep on your solution for the DLL as this might find other places.

    Secondly there may be a dependency somewhere you didn't know about. In general when you try to uninstall a NuGet package it will tell you about a dependency issue but I don't think it does that if you downgrade.

    If that still doesn't resolve the issue then use Fuslogvw to see the runtime bindings that are being used.

    Michael Taylor http://www.michaeltaylorp3.net

    Wednesday, October 30, 2019 2:24 PM
  • It is the correct version in the bin folder, the packages folder, and the reference in the .csproj file. But somehow, I think something in my computer's settings must be crossing it up with the other version. If I use the dll referenced in a different project, it will also look for the wrong dll, as well.

    Randy Sims If my answer has helped you, please click "Mark as Answer."

    Wednesday, October 30, 2019 2:56 PM
  • I did a search of all contents in that directory and didn't find any references to It only had references to the dll I actually wanted. I also checked out the .csproj file, the bin folder, obj folder, solution package folder, and still if I found something, it was the version I wanted, not

    Fuslogvw didn't show anything at all for this dll. I am trying to see it in there by running the tests in my project (which are failing with the same error), but nothing is showing up.

    Randy Sims If my answer has helped you, please click "Mark as Answer."

    Wednesday, October 30, 2019 2:59 PM
  • Did you look in your configs for a binding redirect? If you're using the SDK format note that by default it will not modify your config file directly but the generated file sitting in the output directory.

    Did you enable fusion logging before using the viewer? You should be seeing log entries for all the assemblies.

    Michael Taylor http://www.michaeltaylorp3.net

    Wednesday, October 30, 2019 3:54 PM
  • fusion log should display why the load failed.
    you did enable "Log bind failures to disk" and refreshed after the error happened?

    Wednesday, October 30, 2019 4:34 PM
  • Hi Randy,

    Thank you for posting here.

    For your question, you have encountered a problem with the dll version mismatch.

    Based on my search, this link may be helpful to you.

    Could not load file or assembly 'WinSCPnet' or one of its...

    Note: This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; Therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet.

    Hope this could help you.

    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, October 31, 2019 6:43 AM
  • I was going to say it's been one of those weeks, but guess it's been longer!

    Here are the results from the fuslogvw.

    I checked the machine.config and no reference found to WinScp.

    Same for vstest.executionengine.x86.exe.config.

    It wants that assembly, but no idea where to look!

    *** Assembly Binder Log Entry  (11/9/2019 @ 8:31:49 AM) ***
    The operation failed.
    Bind result: hr = 0x80131040. No description available.
    Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable  C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 14.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe
    --- A detailed error log follows. 
    === Pre-bind state information ===
    LOG: DisplayName = WinSCPnet, Version=, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf
    LOG: Appbase = file:///C:/Repos/GitHub/hwbi-ksp-sshrelay/KSP_SSHRelay/KSP_SSHRelay_Tests/bin/Release
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = vstest.executionengine.x86.exe
    Calling assembly : (Unknown).
    LOG: This bind starts in default load context.
    LOG: Using application configuration file: C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 14.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe.Config
    LOG: Using host configuration file: 
    LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
    LOG: GAC Lookup was unsuccessful.
    LOG: Attempting download of new URL file:///C:/Repos/GitHub/hwbi-ksp-sshrelay/KSP_SSHRelay/KSP_SSHRelay_Tests/bin/Release/WinSCPnet.DLL.
    LOG: Assembly download was successful. Attempting setup of file: C:\Repos\GitHub\hwbi-ksp-sshrelay\KSP_SSHRelay\KSP_SSHRelay_Tests\bin\Release\WinSCPnet.dll
    LOG: Entering run-from-source setup phase.
    LOG: Assembly Name is: WinSCPnet, Version=, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf
    WRN: Comparing the assembly name resulted in the mismatch: Minor Version
    ERR: The assembly reference did not match the assembly definition found.
    ERR: Run-from-source setup phase failed with hr = 0x80131040.
    ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

    Randy Sims If my answer has helped you, please click "Mark as Answer."

    Saturday, November 9, 2019 1:52 PM
  • I saw these, unfortunately it didn't help.

    And the website is read only, now - no new forum posts.

    Randy Sims If my answer has helped you, please click "Mark as Answer."

    Saturday, November 9, 2019 1:55 PM
  • Ok, the pre-bind log specifies that your code is explicitly looking for the fully qualified assembly name version 1.6.5. So somewhere in your solution structure somebody is referencing that assembly explicitly. However the version that is ultimately getting found is 1.3.5 and since it is not the same version and there isn't a runtime redirect it fails.

    Tracking this down should be pretty straightforward. Just to clarify this happens with your app and the test harness right? It isn't just the test that fails?

    I'd like to start from baseline just to eliminate any intermediary changes you might have made. You can skip this if you are confident you haven't made any changes. Uninstall the package from your solution using Package Manager. If there are any other packages that rely on this (and hence are pulling in the wrong version) then it will fail. Then go to the Packages folder that is in your solution folder (I'm assuming you are using packages.config) and delete that directory. I find that restarting VS helps if it is locked. Clean the bin/obj directories. Verify that there is no copy of this DLL anywhere in the solution at this point using Windows Explorer. Grep your project files and configs for any mention of `WinSCPNet`. Remove any you find.

    Rebuild your code. You should be getting errors about any code that references this assembly missing. Go back to Package Manager and install the 1.3.5 version that you are expecting. Then build. Go to the output directory and verify the correct version is there. Rerun your app. If it fails then go to the output directory and open each assembly in ILDisassembler or Telerik's Decompiler. Go to the References nodes and look for any dependencies on WinSCPNet. For each dependency look at the version #. When you find the assembly referencing the wrong version that is the culprit. 

    Michael Taylor http://www.michaeltaylorp3.net

    Saturday, November 9, 2019 7:03 PM
  • skimming the page Downloading and Installing WinSCP .NET Assembly
    there is an additional winscp.exe called via remoting (and may I add my personal opinion that this looks a bit messy).
    Maybe you somehow got the wrong exe called which uses the different version?

    Saturday, November 9, 2019 7:32 PM