.net version dependencies


  • Discourse touched me in a no-no place

    I have a small C# project I inherited. It creates an assembly that depends on several other ones, which are part of another product.

    I have version x.y of that project (all the DLLS are stamped something like 9.0.1.0.) One of my customers needs this DLL, but he has version 9.0.2.0 of the other product, and my DLL won't work on his system. I read--unless I misunderstood it--there's a way for me to specify a range of versions in my dependent DLLs, so that I don't have to build multiple versions of mine. Does anyone know how to make this work? Ideally I will work with 9., but 9.0. would probably be acceptable.



  • You might be able to get away with simply removing the version information from the reference in the project file.

    I'm having a similar problem: I updated to VS2013 U4, and suddenly all my references to Fakes broke, because apparently the version of Fakes was changed from 11.0.0.0 to 12.0.0.0. VS doesn't know what to do, suddenly.

    Removing the version entirely feels fairly unsafe, since it could use a version that is incompatible, though...

    ...And its still failing. This is bad.


  • Discourse touched me in a no-no place

    @Magus said:

    You might be able to get away with simply removing the version information from the reference in the project file.

    How do I do that?



  • @Magus said:

    You might be able to get away with simply removing the version information from the reference in the project file.

    How about just remapping the version using assembly binding redirection?

    http://msdn.microsoft.com/en-us/library/7wd6ex19(v=VS.100).aspx



  • I was doing it by opening the project file in notepad++ and removing the version and culture information. May still have to do other things to get it working in my case.



  • You can't fix it in the DLL, unless you build the new DLL with the old version number, but that's a bad idea.

    To do a global redirect of all applications using 9.0.1.0 to 9.0.2.0, create a publisher policy (use the link Ragnax provided to see how to). To make that one application use 9.0.2.0 instead of 9.0.1.0, tweak the app config, one again using the steps from Ragnax's link.

    In either case, you have to hope that 9.0.2.0 is actually compatible, or you'll get errors.


  • Fake News

    In your own .csproj's, drop in some SpecificVersion elements:

    <Reference Include="blah.blah.blah, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0123456789abcdef, processorArchitecture=MSIL">
        <SpecificVersion>False</SpecificVersion>
    </Reference>

  • Discourse touched me in a no-no place

    @Jaime said:

    create a publisher policy

    I'm reading that now, but, my file is a DLL loaded by a 3rd-party executable I have no[1] control over. Will that be a problem?

    [1] approximately, that is. It's a runtime.


  • Discourse touched me in a no-no place

    @lolwhat said:

    In your own .csproj's, drop in some SpecificVersion elements:

    It turns out, those are already there.

    Any other ideas what could cause my DLL to fail to load?

    The specific error is "Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly '[dll]" or one of its dependencies. THe located assemblhy's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)" when the executable starts up.


  • Discourse touched me in a no-no place

    Might I be able to do something like this, in the application.exe.config (this is code swiped from said file), to the DLL that my DLL can't load? (I suppose it's possible the two versions of the dependent dll are incompatible, but i'll need help from the vendor if that's the case.)

    <dependentAssembly>
       <assemblyIdentity name="Infragistics4.Documents.Core.v13.1" publicKeyToken="7dd5c3163f2cd0cb" culture="neutral" />
       <publisherPolicy apply="no"/>
       <bindingRedirect oldVersion="13.1.20131.2015" newVersion="13.1.20131.2089"/>    
       <bindingRedirect oldVersion="13.1.20131.2048" newVersion="13.1.20131.2089"/>      
    </dependentAssembly>


  • <Reference Include="blah.blah.blah, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0123456789abcdef, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> </Reference>

    Is what you're seeing.

    My suggestion was:

    <Reference Include="blah.blah.blah" />
    

    Which might work, but is really unsafe. It may also not help, because it may compile your dll with the version it finds in the GAC on your local machine and still require that version on the client machine.



  • @FrostCat said:

    Might I be able to do something like this, in the application.exe.config (this is code swiped from said file), to the DLL that my DLL can't load? (I suppose it's possible the two versions of the dependent dll are incompatible, but i'll need help from the vendor if that's the case.)

    That's the idea. I just re-read your scenario and it looks like your solution might be as simple as putting the DLLs you need in your app's folder. Then your DLLs won't interfere with the dependencies of the other program at all.



  • This is a much better solution than anything I've mentioned. You might be able to get away with just setting the reference to Copy (in it's properties).

    And at @FrostCat: I also deal with IG. They are a source of much anger.


  • Discourse touched me in a no-no place

    I might be able to do that. I'll have to try. It will boil down to having two different versions of those DLLs.

    I've asked the vendor if they can recompile for me, too.

    @Magus said:

    I also deal with IG. They are a source of much anger.

    Fortunately I don't actually have to use those controls--they're just there in the app.config.

    I've read all the posts here and I'm not sure I understand everything, so I might have more questions tomorrow/monday.


Log in to reply