I have a C # assembly with several Nuget dependencies that are produced as an artifact from the TFS assembly. The resulting assembly has two different versions of the same assembly, which is included in the list of links to which it refers. I would like to understand how this happens, because I am not sure of the consequences and I do not think that this was possible in the first place. So far, I have not been able to reproduce the problem in any minimal example.
To develop, I have Company.Product.A.dll, which, according to .NET Reflection, Mono.Cecil, dotPeek, and ILSpy, references both Company.Product.B.dll 1.0.0.0 and Company.Product. B.dll 1.0.2.0 for example
// The list of referenced assemblies below contains two versions of Company.Product.B.dll
Assembly.LoadFile(@"C:\Company.Product.A.dll").GetReferencedAssemblies()
- The base .csproj for Company.Product.A.dll has the only link to Company.Product.B.dll 1.0.2.0 and the corresponding link from the Nuget package to the same version.
- The assembly of Company.Product.A.dll depends on another assembly, which also refers to Company.Product.B.dll (I'm not sure if this is important, but I'm suspicious that this might have something to do with the problem, if another the assembly refers to an older version of Company.Product.B.dll).
- I am not aware of starting ILMerge malarkey during the build process, but I am still considering this just in case.
- The build server produces clean builds every time.
- Neither the root assembly nor the two versions of the dependent assemblies have a strong name.
- It seems that there is no negative result of a reference to a false assembly; A product that uses assemblies works as intended.
ILDasm ( , _8 ):
.assembly extern Company.Product.B
{
.ver 1:0:2:0
}
.assembly extern Company.Product.B as Company.Product.B_8
{
.ver 1:0:0:0
}
- , , ?