2012-03-07 11 views
6

Mamy zainstalowane Visual Studio 2010 SP1 i Async CTP (odświeżanie SP1).MSBuild nie znajduje asynchronicznych wymaganych referencji

Rozwiązanie z projektami, które używają async/await słów kluczowych buduje OK podczas kompilacji z VS IDE. Również po zbudowaniu z devenv /build "Debug" solution.sln wszystko jest w porządku.

Jednak msbuild @commands.rsp solution.sln raporty:

File.xaml.cs(123): error CS1993: Cannot find all types required by the 'async' modifier. Are you targeting the wrong framework version, or missing a reference to an assembly? 

commands.rsp wygląda następująco:

/nologo 
/p:Configuration=Debug 
/m:3 
/fileLogger 

Wszelkie wskazówki?

+0

Czy umieścisz swój plik commands.rsp? – KMoraz

Odpowiedz

4

Proszę odnieść się do dyskusji tutaj: http://social.msdn.microsoft.com/Forums/uk-UA/async/thread/3d491cb0-a19f-4faf-80a6-5fd05e4e06db

Są 2 punkty mają być wyjaśnione, aby lepiej zrozumieć problem:

  • Środowisko: czy instalować side-by-side VS11 z VS 2010 + Async CTP?
  • Twój projekt: czy posiadasz XAML z kontrolkami użytkownika i "clr-namespace" w twoim projekcie?

będę cytować wstępny zawarcia przez SERware z dyskusji na forum MS:

myślę, że ma do czynienia z rzędu, w którym XAML wystaje skompilować zespoły, odnosząc się do klasy samej biblioteki. W tym przypadku moduł ładujący XAML próbuje skompilować te klasy, zanim odniesie się do biblioteki Async CTP. Zatem słowo kluczowe "asynchroniczne" nie jest rozpoznawane.

Osobiście mam zamiar sprawdzić, czy możliwe jest, aby podzielić zespół w celu rozwiązania kolejność zestawiania zależnościami w XAML

Dodano po dalszych badań: Jak już się dowiedzieliśmy, wyjaśnienie jest jeszcze bardziej rozczarowujące: platforma .NET 4.5 (wersja beta) zastępuje .NET 4.0. Poza tym sygnatury typów związanych z asynchronizacją/oczekiwaniem zostały wewnętrznie zmienione. Dlatego nie ma możliwości użycia jednocześnie VS 2010 + AsyncATP i VS11 Beta. - Yuri S. 2 min temu

+0

Po pierwsze, tak, mam zainstalowany VS11. Jednak mój kolega z pracy tego nie robi i miał te same błędy. W drugim punkcie, wszystkie asynchroniczne/oczekujące wywołania w naszym przypadku są w ViewModelu, więc nie mają odpowiednika xaml (mój przykład błędu jest mylący, ponieważ i tak nie miałem naszego w przewijaniu wstecz i to było to, ten sam opis błędu i kod) –

+0

Jak się dowiedziałem, wyjaśnienie jest jeszcze bardziej rozczarowujące: .NET 4.5 (Beta) zastępuje .NET 4.0 Poza tym sygnatury typów asynchronicznych/oczekiwania zostały wewnętrznie zmienione . Dlatego nie ma możliwości użycia jednocześnie VS 2010 + AsyncATP i VS2011 Beta. –

0

Sam zostałem przez to trafiony iz różnych powodów nie mogę uaktualnić projektów do .NET 4.5, więc musiałem opracować obejście.

Ponieważ jest to tylko problem dla projektów XAML, które mają deklarację xmlns wskazującą na siebie, jestem w stanie używać asynchronizacji we wszystkich innych projektach, do których się odwołuje. Oznacza to, że moja architektura nadal wykorzystuje asynchroniczne/oczekiwane i jest przygotowana na przejście do .NET 4.5 później.

Ale w projektach XAML, których dotyczy problem, po prostu ręcznie wdrażam (słabo) oczekuję na rzeczy wykonywane przez kompilator.

więc kod, który był to czysty przed:

try 
{  
    var foo = GetFoo(); 
    foo.DoStuff(); 
    var data = await foo.GetDataAsync(); 
    bar.WorkOnData(data); 
} 
catch (Exception ex) 
{ 
    // Logging, throw up a popup, whatever... 
    HandleError("Failed to get data", ex); 
} 

Teraz staje się w ten sposób:

var foo = GetFoo(); 
foo.DoStuff(); 
var getDataTask = foo.GetDataAsync(); 
getDataTask.ContinueWith(t => 
    { 
     if (t.IsFaulted) 
     { 
      // Logging, throw up a popup, whatever... 
      HandleError("Failed to get data", t.Exception); 
      return; 
     } 
     if (t.Status == TaskStatus.RanToCompletion) 
     { 
      bar.WorkOnData(t.Result); 
     } 
    }); 

Nie idealne, oczywiście, i to jest dokładnie rzecz, która async/await został stworzony w celu rozwiązać. Ale działa to jako krótkoterminowe obejście, przynajmniej dla prostych zastosowań await.