2013-03-04 16 views
26

Mam następujący problem:Dlaczego System.Core nie ładuje się podczas dodawania obsługi kodowanego interfejsu użytkownika dla aplikacji Silverlight 5?

Próbuję dodać obsługę tworzenia zakodowanego testu interfejsu użytkownika dla aplikacji Silverlight 5 ([MSDN] [1]). Pierwszym krokiem jest odniesienie do zestawu Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll w projekcie Silverlight 5. Niestety, po odniesienie został dodany projekty zatrzymuje skompilować z wielu podobnych błędów:

>

Error 25 Cannot resolve reference assemblies. Please check the reference assemblies. Could not load file or assembly 'System.Core, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) ....\ErrorReportDialog.xaml 


Looks like System.Core 5.0.5.0 fails to load, okay, debugging assemblies loading with Fuslogw produces two interesting logs: 

First log: 

> Assembly Binder Log Entry (04.03.2013 @ 14:07:49) 
The operation was successful. 
Bind result: hr = 0x0. The operation completed successfully. 
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll 
Running under executable C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 
A detailed error log follows. 
=== Pre-bind state information === 
LOG: DisplayName = System.Core, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 
(Fully-specified) 
LOG: Appbase = file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/ 
LOG: Initial PrivatePath = NULL 
LOG: Dynamic Base = NULL 
LOG: Cache Base = NULL 
LOG: AppName = MSBuild.exe 
Calling assembly : System.Windows, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e. 
LOG: This bind starts in LoadFrom load context. 
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load(). 
LOG: Using application configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.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: System.Core, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 
LOG: Binding succeeds. Returns assembly from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Core.dll. 
LOG: Assembly is loaded in LoadFrom load context. 

Looks like System.Core, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e loads succesfully. 

But second log entry produces the following error: 

> Assembly Binder Log Entry (04.03.2013 @ 14:07:49) 
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 C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 
A detailed error log follows. 
Pre-bind state information 
LOG: DisplayName = System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 
(Fully-specified) 
LOG: Appbase = file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/ 
LOG: Initial PrivatePath = NULL 
LOG: Dynamic Base = NULL 
LOG: Cache Base = NULL 
LOG: AppName = MSBuild.exe 
Calling assembly : Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper, Version=10.0.30319.381, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. 
LOG: This bind starts in default load context. 
LOG: Using application configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.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: Redirect found in application configuration file: 2.0.5.0 redirected to 5.0.5.0. 
LOG: Post-policy reference: System.Core, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 
LOG: The same bind was seen before, and was failed with hr = 0x80131040. 
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80131040). 

Wygląda Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll próbuje załadować System.Core, Version = 2.0.5.0, Culture = neutral, PublicKeyToken = 7cec85d7bea7798e, ale jest przekierowywany do System.Core, Version = 5.0.5.0, Culture = neutral, PublicKeyToken = 7cec85d7bea7798e (już załadowany z 1. logu) i wciąż się nie udaje załadować.

Can anyone provide some insight on how to further debug this problem? I'm compiling Silverlight projects for AnyCpu platform. 


    [1]: http://msdn.microsoft.com/en-us/library/gg413374.aspx 
+2

System.Core, wersja = 2.0.5.0 to oczywiście problem. Starsza wersja zestawu, używana w poprzednich wersjach Silverlight. Nie zrobili tego dla VS2012, sprawdź to [wpis na blogu] (http://blogs.msdn.com/b/bharry/archive/2012/07/09/coded-ui-testing-support-for-silverlight .aspx). –

+0

Sprawdziłem to za pomocą VS2010 - przekierowanie z pliku machine.config tam nie działa. Tworzy błąd polegający na tym, że nie znajduje się SystemCore 2.0.5.0, ponieważ projekt odwołuje się do wersji 5.0.5.0. Dziwne, ponieważ używamy tej samej wersji samego .Net Framework. – Cortlendt

+0

@HansPassant: Czy uważasz, że dobrym pomysłem byłoby opublikowanie tego linku jako odpowiedzi? Wiem, że to nie jest doskonałe rozwiązanie, ale myślę, że to może być najlepsza opcja. –

Odpowiedz

1

Aby potwierdzić wersję System.Core wymaganych SilverlightUIAuthomationHelper wykonaj następujące czynności:

  1. znaleźć odwołuje SilverlightUIAuthomationHelper dll na dysku.
  2. załaduj go do dowolnego dezasemblera/reflektora - na przykład dotPeek lub Reflector.
  3. wersje kontrola zespołów przywoływanych - System.Core musi być 2.0.5.0 w wersji SilverlightUIAuthomationHelper

Możliwe rozwiązania:

  1. aktualizacja SilverlightUIAuthomationHelper do nowej wersji (link w komentarzu Hans Passant), która odnosi się do nowej biblioteki SystemCore (wersja 5.0.5.0)
  2. Ponieważ fuslogvw mówi, że przekierowanie z wersji 2.0.5.0 na 5.0.5.0 znajduje się w pliku konfiguracyjnym APPLICATION - spróbuj znaleźć i usunąć to przekierowanie (details here). Ale jest bardzo możliwe, że coś innego się zepsuje.