Vista - Build errors whith two identical assembliey names

I have a project where I load some of my assemblies dynamically, I'm using
a venders product where he loads some assemblies dynamically. He loads two
assemblies that both share a common name; however have different public keys
and version numbers. I receive an error when I compile the my assembly (the
dynamic one) it tells me to us the vendors other version of the product,
Which is completely wrong since the items I need aren't even in that
assembly. I have tried both methods of loading his assembly dynamically
thru reflections, neither worked. One thing that did work around the
problem is that I added his dynamically loaded assembly into the GAC, after
I did this I was able to get past this error. Obviously this is a
deployment problem for us since it's not our product and we don't want to go
messing around with other peoples assemblies.

Alexander,

This is a problem for the supplier of the product as he has not rigth signed
his product.

Cor

"Alexander Llew Wykel" <Alexander.Wykel@xxxxxx> schreef in
bericht news:ACA60A74-BAE9-42B8-99AF-B29E649CD3FE@xxxxxx

Here is my reply from my vender:

Hi Alex,

that is impossible, ... i have not seen that thread as yet, but the
conclusion you say is wrong.

if you take a look at my assembky's identity, i.e. fom teh treelistview
install package of combobox, it will be like so:
Binarymission.BinaryComboBox, Version=2.1.257.<build>, Culture=neutral,
PublicKeyToken=5cb4c20959280c09

If you look up the identiy of the dll that is in your retail version install
of combobox, it will be like so:

Binarymission.BinaryComboBox, Version=2.1.257.<build>, Culture=neutral,
PublicKeyToken=5cb4c20959280c09

They will match completely, including the public token.

Also, if the signing was not correct, the CLR / run-time would not even load
it in teh first place - and will fail and throw FileLoadException, since its
compted assembly hash won;t match with the decrypted has of the assembly from
the assembly's digest.

The only issue in your setup is that two differnet versions of the combobox
dlls are being used in the same solution (albeit across different projects).

To prove this theaoy, run my demo application, and it will work fine with
the combobox.
if the signing was wrong, it is imppossible to work with teh demo and not
work with yours.

--
Alexander L. Wykel
AW Software Works



"Cor Ligthert[MVP]" wrote:

Ther Exact Error in Visual Studio is:

Target ResolveProjectReferences:
Target ResolveAssemblyReferences:
Consider app.config remapping of assembly "Binarymission.BinaryComboBox,
Culture=neutral, PublicKeyToken=5cb4c20959280c09" from Version
"2.1.257.37476" [] to Version "2.1.2769.2131" [C:\Program Files\Binarymission
Technologies Ltd\BinaryComboBox .NET Version 2.1 (for .NET
2.0)\Binarymission.BinaryComboBox.dll] to solve conflict and get rid of
warning.
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets :
warning MSB3247: Found conflicts between different versions of the same
dependent assembly.
Done building target "ResolveAssemblyReferences" in project
"AutoDeveloper.csproj".

--
Alexander L. Wykel
AW Software Works



"Alexander Llew Wykel" wrote:

Comments from the Software Vendor:

that is impossible, ... i have not seen that thread as yet, but the
conclusion you say is wrong.

if you take a look at my assembky's identity, i.e. fom teh treelistview
install package of combobox, it will be like so:
Binarymission.BinaryComboBox, Version=2.1.257.<build>, Culture=neutral,
PublicKeyToken=5cb4c20959280c09

If you look up the identiy of the dll that is in your retail version install
of combobox, it will be like so:

Binarymission.BinaryComboBox, Version=2.1.257.<build>, Culture=neutral,
PublicKeyToken=5cb4c20959280c09

They will match completely, including the public token.

Also, if the signing was not correct, the CLR / run-time would not even load
it in teh first place - and will fail and throw FileLoadException, since its
compted assembly hash won;t match with the decrypted has of the assembly from
the assembly's digest.

The only issue in your setup is that two differnet versions of the combobox
dlls are being used in the same solution (albeit across different projects).

To prove this theaoy, run my demo application, and it will work fine with
the combobox.
if the signing was wrong, it is imppossible to work with teh demo and not
work with yours.

Sundar

--
Alexander L. Wykel
AW Software Works



"Alexander Wykel" wrote:

Alexander,

I assume that you have set a reference, then I would clear those references
and set it new.

Cor

"Alexander Wykel" <awykel@xxxxxx> schreef in bericht
news61522CE-48E6-4A43-9358-67F24F03F626@xxxxxx

I tried everything beleive me.

This is the problem:

Target ResolveProjectReferences:
Target ResolveAssemblyReferences:

Consider app.config remapping of assembly "Binarymission.BinaryComboBox,
Culture=neutral, PublicKeyToken=5cb4c20959280c09" from Version
"2.1.257.37476" [] to Version "2.1.2769.2131" [C:\Program Files\Binarymission
Technologies Ltd\BinaryComboBox .NET Version 2.1 (for .NET
2.0)\Binarymission.BinaryComboBox.dll] to solve conflict and get rid of
warning.

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets :
warning MSB3247: Found conflicts between different versions of the same
dependent assembly.

--
Alexander L. Wykel
AW Software Works



"Cor Ligthert[MVP]" wrote:

Alexander,

This is for sure not my hobby, but dit you try the GACUtil already.

http://msdn.microsoft.com/en-us/libr...2c(VS.80).aspx

Cor


"Alexander Wykel" <awykel@xxxxxx> schreef in bericht
news:4DB76473-8C21-46BE-8CD2-B7D02D620549@xxxxxx

The GACUtility solved the problem but is not how the vendor's component
works, they dynamically load thier assemblies, There are two assemblies with
the same name. The vendor won't fix the problem.

--
Alexander L. Wykel
AW Software Works



"Cor Ligthert[MVP]" wrote: