Jedną z metod jest rekompilacja wszystkich pakietów NuGet w celu użycia tej samej wersji Microsoft.Practices.ServiceLocation
. Na poziomie pragmatycznym to po prostu nie jest praktyczne: potrzebujemy łatwiejszej metody.
Lepszą metodą jest zastosowanie przekierowania wiązania zespołu. Działa to bardzo ładnie, jeśli interfejs jest taki sam. To rozwiązanie jest wypróbowane i przetestowane i jest uruchomione w produkcji w wielu firmach FTSE.
To właśnie app.config wygląda następująco:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Practices.ServiceLocation" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.2.0.0" newVersion="1.2.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Ustaw wersję docelową do tego, co już masz w wersji, która jest zazwyczaj 1.2.0.0
lub 1.3.0.0
.
Zestaw PublicKeyToken
musi pasować do zespołu docelowego. Można wyodrębnić go za pomocą polecenia:
sn.exe -T assembly.dll
przykład:
C:\test>"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\x64\sn.exe" -T C:\svn\lib\TargetDll.dll
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.17929
Copyright (c) Microsoft Corporation. All rights reserved.
Public key token is ac3efa7c033c2bd5
c:\test>
innych sposobów uzyskiwania PublicKeyToken
patrz Getting the PublicKeyToken of .Net assemblies.
Numer PublicKeyToken
nie zmienia się wraz z wersją zespołu, np. jest taki sam, jeśli zespół jest v1.0.0.0
lub v2.0.0.0
.
Ten facet wyjaśnił to doskonale, spójrz na [tę odpowiedź] (http://stackoverflow.com/a/28789578/2014112) !! – KnowGe