none
Choosing arbitrarily? [No way to resolve conflict between...] RRS feed

  • Question

  • My question is what does it mean "Chooosing "..." arbitrarily?  Log4net is a strong named assembly being referenced by assemblies this assembly is referencing.  One such is a third party assembly that uses log4net and the another is our assembly that uses a modified version of log4net we built. Is it not the case that both version of the assembly get loaded by the runtime and will be used by the respective assemblies?  I would like to understand what this warning means...  I do understand that I "could" use a binding redirect in my app.config to cuase the runtime to load only one version, but I don't think I want that behavior.  

    No way to resolve conflict between "log4net, Version=1.2.420.20, Culture=neutral, PublicKeyToken=dc6c685ec476860e" and "log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905". Choosing "log4net, Version=1.2.420.20, Culture=neutral, PublicKeyToken=dc6c685ec476860e" arbitrarily.

    • Moved by Yi Feng Li Friday, August 19, 2011 5:13 AM CLR issue (From:MSBuild)
    Thursday, August 18, 2011 5:56 PM

All replies

  • Hi Dfurtney,

    Your question is more related to CLR, I'm moving this thread to Common language runtime forum for better support.

    Thank you for your understanding.

    Regards,

    Yi


    Yi Feng Li [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, August 19, 2011 5:12 AM
  • This error message (MSB3243) indicates that same assemblies which has different versions cannot be referenced at the same time, and you can choose any one of the two assembly as reference;

     

    As far as I know, what we can do is adding the bindingRedirect element in app.config file.

     

    I'm still investing on this issue, if I find any update, will let you know as soon as possible.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, August 19, 2011 7:26 AM
  • Thank you for looking into this for me, Eric.  I am not getting an error here or even a warning, just a message that it is coming from ResolveAssemblyReferences task.  I have a main assembly I'll call A that references two other assemblies B and C.  B refereences Log4net v1.2.420.20 and C references Log4Net v1.2.9.0.  Log4Net is strong named, the rest are not.  We have confirmed via process explorer that both versions of the Log4Net assembly are loaded into the process.  I have not yet confirmed they are both being used.   I actually want B and C to use their "own" versions of log4net, soo I don't want to do the bindingRedirect.  I suspect they are in fact both being used, but would like to understand how it is supposed to work and what the heck that" choosing ... arbitrarily" message means!

    By the way, as far as I know, I don't know of any problem this is causing, my applications seems to be working fine.   But I find the message unsettling and want to understand it.   

     

    6>ResolveAssemblyReferences:
    6> No way to resolve conflict between "log4net, Version=1.2.420.20, Culture=neutral, PublicKeyToken=dc6c685ec476860e" and "log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905". Choosing "log4net, Version=1.2.420.20, Culture=neutral, PublicKeyToken=dc6c685ec476860e" arbitrarily.

     


    David Furtney
    Friday, August 19, 2011 5:03 PM
  • You would use an alias name for each assembly.  This link describes how to do it from a command line build.

    http://msdn.microsoft.com/en-us/library/ms173212.aspx

    Visual Studio assigns a default alias of "global" to all referenced types.  This link describes how to use the "global" namespace alias name in your code.

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

    You can assign an alias name to a referenced assembly in the Visual Studio IDE, which would be the way to tell Visual Studio to modify its' compiler command line with a command line switch to use an alias name for a referenced assembly.  It is very simple to do.  I cannot find a link to it in the MSDN library, which means I got tired of looking for one.

    http://msdn.microsoft.com/en-us/library/s5zwxxdw.aspx  (I am not sure if this procedure is described in the MSDN library.  It should)

    Go to Solution Explorer.  Expand the References tab of your project so that you can see the list of referenced assemblies.  Click on the assembly that you wish to assign an alias name.  Now look in the Properties Window for the "Aliases" property.  Notice that the default value is "global".  Change it to anything that you wish.

    This can be done in C#.  I am not aware of a similar technique for VB.  The VB IDE does not display an "Aliases" property.

    Hope this helps.

    Rudy   =8^D

     


    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/



    • Edited by Rudedog2 Sunday, August 21, 2011 6:08 PM VB comments
    Sunday, August 21, 2011 6:01 PM
  • Thanks, Rudedog2.   This addresses a different issue - referencing two versions of an assembly from a single consumer assembly (A->B,B').   In my case, the issue is one level deeper (A->(B-L),(C->L') where L and L' are two versions of the same assembly.  The L assemblies are strong named.  B is compiled against L and is very happy.  Same for C and L'.  However, when I compile A, I get the warning.   I can't figure out the significance of the warning - especially the choosing one of them arbitrarily part.   I have confirmed that both assemblies are getting loaded into the process. 
    David Furtney
    Monday, August 22, 2011 4:43 PM
  • Does A reference any types in either assembly, L or L'? 

    Assembly A might have to reference one of the dependent assemblies if it tries to instantiate a type that is inherited from L or L', or consumes types in L or L'.  This scenario would cause A to need to reference assembly L.


    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/


    Monday, August 22, 2011 5:18 PM
  • No.   Might it have something to do with CopyLocal behavior?  Is that what it might be having to choose arbitrarily?  I turned on diagnostic build output:

     

    4> This reference is not "CopyLocal" because it conflicted with another reference with the same name and lost the conflict. (TaskId:145)

    4> There was a conflict between "log4net, Version=1.2.420.20, Culture=neutral, PublicKeyToken=dc6c685ec476860e" and "log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905". (TaskId:145)

    4> No way to resolve conflict between "log4net, Version=1.2.420.20, Culture=neutral, PublicKeyToken=dc6c685ec476860e" and "log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905". Choosing "log4net, Version=1.2.420.20, Culture=neutral, PublicKeyToken=dc6c685ec476860e" arbitrarily. (TaskId:145)

    It then has information on References which depend on log4net for both versions.

     

     


    David Furtney
    Monday, August 22, 2011 8:15 PM
  • Just for bits and giggles, what happens when you turn off CopyLocal?
    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/

    Monday, August 22, 2011 8:26 PM
  • I have created a project that I think should reproduce your issue as I now understand it.  I created 3 projects in one solution, and another class library in another solution.  The 3 project solution contains ClassLibrary1, ClassLibrary2, and a Console Application that references these two libraries.

    I began with a single project library called TypeLibrary, to serve as your log4Net.  The library contains one type definition.

     public class Reference { }
    

    I set a version number, compiled the project, and copied the dll and pdb files to a sub-folder in ClassLibrary1 named Libraries.  I modified the version number and the GUID, recompiled the project, and copied the dll and pdb files to a subfolder in ClassLibrary2 named Libraries.  I added a reference to these assemblies in each project.

    namespace ClassLibrary1
    {
      using TypeLibrary;
    
      public class Lib1_Class1
      {
      }
    
      public class Lib1_Class2
      {
        public Reference MyReference;
      }
    }
    
    /********************************/
    
    namespace ClassLibrary2
    {
      using TypeLibrary;
    
      public class Lib2_Class1
      {
      }
    
      public class Lib2_Class2
      {
        public Reference MyReference;
      }
    }
    

    Those are the contents of the ClassLibrary assemblies.  Below is the content of the Console Application that references those two libraries above.

      class Program
      {
        static void Main(string[] args)
        {
        }
    
        static void Without_TypeLibrary()
        {
          Lib1_Class1 l1 = new Lib1_Class1();
          Lib2_Class1 l2 = new Lib2_Class1();
        }
        static void With_TypeLibrary()
        {
          Lib1_Class2 l1 = new Lib1_Class2();
          Lib2_Class2 l2 = new Lib2_Class2();
        }
      }
    

    All projects built cleanly before I added the two static test methods.  I then verified that each ClassLibrary was referencing an assembly with the same name, but differed only in version number and GUID.  I even have CopyLocal set to true in both libraries.  All compiled cleanly.

    -------------------------------

    Let me diverge for a moment and point out something.  I originally had TypeLibrary part of a single 4 project solution.  Using the "Add Reference" wizard resulted in the libraries being overwritten with the latest version of the assembly in the Release folder of TypeLibrary.  In other words, there was no check for version number or GUID by the IDE.  It simply grapped a file with the correct name in the correct folder, and copied it to the output folders of each ClassLibrary. 

    Net result, each library was referencing the same assembly.  Since I had reversioned TypeLibrary, each ClassLibrary was referencing a new version of the assembly!  So, I copied versions to a seperate folder used the wizard to add those files.

    -------------------------------

    I then added the two static test methods, and it still compiled cleanly.  Each ClassLibrary was still referencing the proper version of their TypeLibrary assembly.  I am not able to reproduce your issue.  If I understand it correctly.  I went through this exercise in C#.

    Rudy   =8^D


    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/

    Monday, August 22, 2011 11:11 PM
  • Next Chapter.

    I added separate folders in the Console Application, and added the assemblies to each.  I then added a reference to TypeLibrary used by ClassLibrary1.  I ran the code in the Console Application, which simply called each of the above static methods and exited.  No problems.

    I then tried to add a reference to the TypeLibary used by ClassLibrary2 using the Add Reference Wizard again.  I was prevented from doing this because "a library with this name already exists."  So, I modifed the second method like this.

        static void With_TypeLibrary()
        {
          Lib1_Class2 l1 = new Lib1_Class2();
          Lib2_Class2 l2 = new Lib2_Class2();
          TypeLibrary.Reference reference = l2.MyReference;
        }
    

    I ran the program.  And amazingly, I had encountered no errors.  The type used in the Console application is from a different assembly than the one used for the property, MyReference.  This should not have been permitted.  Two type definitons are being used.

    Rudy   =8^D


    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/

    Monday, August 22, 2011 11:55 PM
  • Is your TypeLibrary strong named?  I think that is key to reproducing this.  Run time assembly binding behavior is different for strong named assemblies vs weak named.  I expect that both your references are being satisified by the same "weak" assembly and only that one is loaded by the CLR into your process.  

    Also, I am not quite clear what is the "GUID" you are talking about?  The ProjectGUID in the csproj?


    David Furtney
    Tuesday, August 23, 2011 12:28 AM
  • Strong name does not compile.  I just tested it and modified my post, but the server is hanging.  Yes, the project GUID.

    CS0012 tells me that one type is defined in another assembly.

    CS0029 tells me that I cannot convert from one type to another.

    warning MS83247 tells me conflicts found between dependent assemblies.

    I was trying to reproduce your reported error.  Close, but it is not loading the assembly all on its' own.

    Rudy   =8^D


    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/


    Tuesday, August 23, 2011 12:48 AM
  • Download my test projects and solutions here.

    https://connect.microsoft.com/VisualStudio/feedback/details/685119/type-safety-failed#details

    Rudy   -8^D


    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/

    Tuesday, August 23, 2011 12:56 AM
  • I changed your solution by strong naming the TypeLibrary assembly as V1.1.0.0, copying that version to all the "1" folders then rebuilt and signed as V1.2.0.0 and copied that to the "2" folders. I removed the reference to TypeLibrary from the CS_ConsApp_AssemblyAliases and commented out the usage of it.

    //TypeLibrary.Reference reference = l2.MyReference;

    When I build that, I get almost exactly what I am seeing.   Then I changed the Libn_Class constructors to create an instance (new Reference()) and also added both versions of TypeLibrary (1.1.0.0 and 1.2.0.0) to the GAC with gacutil.  This loads both versions of the TypeLibrary and runs fine.  -- So my question still stands -- what was chosen arbitrarily?  Changing the CopyLocal property of ClassLibrary1 and 2 makes no difference.

    ResolveAssemblyReferences:

    A TargetFramework profile exclusion list will be generated.

    No way to resolve conflict between "TypeLibrary, Version=1.2.0.0, Culture=neutral, PublicKeyToken=627cacb2406144e2" and "TypeLibrary, Version=1.1.0.0, Culture=neutral, PublicKeyToken=627cacb2406144e2". Choosing "TypeLibrary, Version=1.2.0.0, Culture=neutral, PublicKeyToken=627cacb2406144e2" arbitrarily.

    Consider app.config remapping of assembly "TypeLibrary, Culture=neutral, PublicKeyToken=627cacb2406144e2" from Version "1.1.0.0" [C:\Users\dfurtney\Downloads\CS_ConsApp_AssemblyAliases\CS_ConsApp_AssemblyAliases\CS_ConsApp_AssemblyAliases\Libraries1\TypeLibrary.dll] to Version "1.2.0.0" [C:\Users\dfurtney\Downloads\CS_ConsApp_AssemblyAliases\CS_ConsApp_AssemblyAliases\CS_ConsApp_AssemblyAliases\Libraries2\TypeLibrary.dll] to solve conflict and get rid of warning.

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3247: Found conflicts between different versions of the same dependent assembly.


    David Furtney

    Tuesday, August 23, 2011 2:53 AM
  • I created a test solution, which contains 4 projects,

    A --> Console application, reference to B and C (Copy Local set to True)

    B --> Class Library, reference to D (of version 1.0.0.0, Copy Local set to False)

    C --> Class Library, reference to D (of version 2.0.0.0, Copy Local set to False)

    D --> Class Library, strong-named (used to generate two versions of D.dll file)

     

    Project B's Debug folder looks like:

    Bin\Debug\

    1.0\

    D.dll (ver 1.0.0.0)

    B.dll

     

     

    Project C's Debug folder looks like:

    Bin\Debug\

    2.0\

    D.dll (ver 2.0.0.0)

    C.dll

     

    Project A's Debug folder looks like:

    Bin\Debug\

    1.0\

    D.dll (ver 1.0.0.0)

    2.0\

    D.dll (ver 2.0.0.0)

    A.exe

    A.exe.config (<probing privatePath="1.0;2.0"/>)

    B.dll

    C.dll


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, August 24, 2011 8:57 AM
  • When I run A.exe, the process throws an assembly binding exception, and fuslogvw tool shows me that

     

    *** Assembly Binder Log Entry  (2011/8/24 @ 16:39:37) ***

     

    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  D:\Projects\VS10\A\A\bin\Debug\A.exe

    --- A detailed error log follows.

     

    === Pre-bind state information ===

    LOG: User = ***

    LOG: DisplayName = D, Version=2.0.0.0, Culture=neutral, PublicKeyToken=add4889778bf1b1c

     (Fully-specified)

    LOG: Appbase = file:///D:/Projects/VS10/A/A/bin/Debug/

    LOG: Initial PrivatePath = NULL

    LOG: Dynamic Base = NULL

    LOG: Cache Base = NULL

    LOG: AppName = A.exe

    Calling assembly : C, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.

    ===

    LOG: This bind starts in default load context.

    LOG: Using application configuration file: D:\Projects\VS10\A\A\bin\Debug\A.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: Post-policy reference: D, Version=2.0.0.0, Culture=neutral, PublicKeyToken=add4889778bf1b1c

    LOG: GAC Lookup was unsuccessful.

    LOG: Attempting download of new URL file:///D:/Projects/VS10/A/A/bin/Debug/D.DLL.

    LOG: Attempting download of new URL file:///D:/Projects/VS10/A/A/bin/Debug/D/D.DLL.

    LOG: Attempting download of new URL file:///D:/Projects/VS10/A/A/bin/Debug/1.0/D.DLL.

    LOG: Assembly download was successful. Attempting setup of file: D:\Projects\VS10\A\A\bin\Debug\1.0\D.dll

    LOG: Entering run-from-source setup phase.

    LOG: Assembly Name is: D, Version=1.0.0.0, Culture=neutral, PublicKeyToken=add4889778bf1b1c

    WRN: Comparing the assembly name resulted in the mismatch: Major Version

    ERR: The assembly reference did not match the assembly definition found.

    ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

     

    Seems CLR always use the order we specified in the app.config probing element to look for assembly, the workaround here is: put the two versions of D.dll into GAC, and then A.exe will work, both B.dll and C.dll can use correct version of their dependency, the output of A.exe is:

     

    in ClassB's Run

    In ClassD's Test method, version is 1.0.0.0

    D, Version=1.0.0.0, Culture=neutral, PublicKeyToken=add4889778bf1b1c

    in ClassC's Run

    In ClassD's Test method, version is 2.0.0.0

    D, Version=2.0.0.0, Culture=neutral, PublicKeyToken=add4889778bf1b1c

     

    You can download the demo solution from here.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, August 24, 2011 8:57 AM
  • any update?


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, September 5, 2011 2:32 AM
  • I have nearly the same problem.

    I use two assemblies, cses.smtp.server.dll and SharpMimeTools.dll are using log4net.dll, one of it needs 1.2.10 and the other needs 1.2.0.

    Not only do I get the warning, but also I get an exception, no matter which version I use, I am always getting the opposite exception from the other library.

    Message=Die Datei oder Assembly "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821" oder eine Abhängigkeit davon wurde nicht gefunden. Die gefundene Manifestdefinition der Assembly stimmt nicht mit dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)

    I can not use GAC, because I am doing all this for Windows Azure, and need to deploy it to the Cloud.

     

    Tuesday, September 6, 2011 8:11 AM
  • Sorry, I did not receive any notifications on this thread until today.  I didn't see that you added the two versions of assembly D to the GAC.  During the build, did you not see the warning?
    David Furtney
    Tuesday, September 6, 2011 4:56 PM
  • If you don't use the GAC, I think you will have to use the app.config bindingRedirect trick recommended above.
    David Furtney
    Tuesday, September 6, 2011 4:58 PM