Hi all!

Can anyone please answer this question?

I want to now if it's possible to use the oldversion of .dll file (which it should do) when redirecting to new version.

The error I get is down below:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl
y 'Version_One, Version=2.0.0.0, Culture=neutral, PublicKeyToken=a2af2b43a05a77c
6' or one of its dependencies. The located assembly's manifest definition does n
ot match the assembly reference. (Exception from HRESULT: 0x80131040) ---> Syste
m.IO.FileLoadException: Could not load file or assembly 'Version_One, Version=1.
0.0.0, Culture=neutral, PublicKeyToken=a2af2b43a05a77c6' or one of its dependenc
ies. The located assembly's manifest definition does not match the assembly refe
rence. (Exception from HRESULT: 0x80131040)
   --- End of inner exception stack trace ---
   at MainProgram.Program.Main(String[] args)
Press any key to continue . . .

The app.config file is this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>

        <assemblyIdentity name="Version_One" culture="neutral" 
                          publicKeyToken="a2af2b43a05a77c6"/>
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
        <publisherPolicy apply="no" />
      </dependentAssembly>


      <probing privatePath="version_control;version2;bin2\subbin;bin3"/>


    </assemblyBinding>
  </runtime>



</configuration>

Please help! And yes, I have added .snk on the Version_One class library project folder, so that I could generate the public key.

Does this have to do with the latest version not having backward compatibility? I'm really lost unfortunately :(

Thanks!

Edited 3 Years Ago by khiemkim.xuan

It would be better to use pure reflection and late-binding (don't include it as part of your references)

It will make your program much more difficult to write (unless you use the exact same interfaces between all the versions).

Switching versions on the fly is going to be more difficult, but possible.

You could, I suppose, use System.AddIn but it's quite poorly documented.

Take very good care with your design.

Edited 3 Years Ago by Ketsuekiame

maybe. but lets consider the problem that I have submitted. for me it seems to force all strong assemblies old versiob to the latest. which means the old version is now useless.

aha, I see. So there is no way to make sure to use old version at all?

so when you're making a new version of a program. you ship .dll file + the app.config to the old version of the program and since it's strongly named defined in the program. The strongly named assembly versions that was for example version 1.0.0.0 will have to force to redirect to 2.0.0.0 and you have to have the 2.0.0.0 version .dll and if you don't, the program will crash because you have the old version

(as the exception I got from what I explained first).

Edited 3 Years Ago by khiemkim.xuan

Yes pretty much, the metadata with the assembly will include certain values telling it what version of files are required.

It may be possible to to override this setting by linking the assembly reference and under the properties tab, set "Specific Version" to false.
But unless you use AppDomains and late-binding, you cannot switch between different versions of libraries.

Honestly, I don't understand why you would need to include an old assembly in a more modern executable. Surely, if you've shipped the more modern exe you would also send the more modern library with it (that includes the backwards compatible calls?

This article has been dead for over six months. Start a new discussion instead.