Zmuszony do odbudowy Depedencje projektu w Visual Studio 2012

Question

Niedawno uaktualniono do VS.NET 2012 i zacząłem napotykać na bardzo frustrujący problem podczas debugowania.

Projekt A ma odniesienie do projektu B. Kiedy edytuję Projekt B, spodziewam się, że akcja budowania/debugowania Projektu A wykryje zmianę w Projekcie B i automatycznie uwzględni ją podczas kompilacji Projektu A. (To jest właśnie kwestia zależności projektu.) I to było dokładnie to, co działo się w VS 2010.

Ale tak się nie stanie w 2012 roku. Rzeczywiście, nawet jeśli bezpośrednio zbuduję Projekt B, Projekt A tego nie wykryje. zmień, chyba że I odbuduje projekt A.

Teraz jestem zmuszony do wyraźnego zbudowania Projektu B, a następnie powrotu do Projektu A i jawnej przebudowy go dla modyfikacje w Projekcie B, które należy uwzględnić.

Myśli?

Answer 1

Czy ustawiłeś projekty zależności w swoim rozwiązaniu?

Możemy ustawić je od:

kliknij prawym Roztwór podstawowy> Ustawienia-> projekt Zależności

Nawiasem mówiąc, czy zbudować rozwiązanie w Visual Studio IDE lub przez polecenie MSBuild?

Jeśli używasz msbuild do budowania projektów, powinieneś dodać atrybut DependsOnTargets do swoich plików projektu.

Więcej informacji można znaleźć na stronie:

http://msdn.microsoft.com/en-us/library/ms366724.aspx

Answer 2

3rd ustęp wydaje się wskazywać na nieporozumienia z pracą way zależności. Przebacz mi, jeśli się mylę.

Jeśli projekt A ma zależność od projektu B, projekt budowlany B nie wymusi przebudowy projektu A. Projekt budowlany A powinien jednak sprawdzić zmiany w projekcie B i odbudować B automatycznie, w razie potrzeby.

Projekt A w tym przypadku jest projektem nadrzędnym lub głównym. Budowanie rodzica sprawdzi wszystkie projekty, od których zależy i odbuduje je, jeśli są przestarzałe. Zawsze budowanie elementu nadrzędnego automatycznie budowałoby nieaktualne zależności, a następnie tworzony byłby projekt nadrzędny, zbierając wszelkie nowe zmiany w zależnościach.

A 
\ 
    B 
    |\ 
    C D 

W tym przykładzie, jeśli B miałoby zależności, to one również zostałyby zbudowane. Jeśli jawnie zbudowałeś B, jego zależności C i D byłyby sprawdzone i przebudowane, ale nie A.

Jeśli jawnie zbudowałeś A, najpierw C i D zostałyby sprawdzone i odbudowane w razie potrzeby, potem B, wreszcie A.

Answer 3

Myślę, że szukasz serwera ciągłej integracji (CI). Element CI może być skonfigurowany do monitorowania repozytoriów źródłowych i wyzwalany do budowania zespołów docelowych po zatwierdzeniu nowych zmian w bazie kodu.

W przeciwnym razie, jak wspominali inni, zależności projektowe mogą zostać użyte do odbudowania zestawów referencyjnych.

Answer 4

Jedną z możliwych przyczyn tego są zablokowane pliki .suo. Zobacz moją odpowiedź na to pytanie:

Visual Studio 2012 not building dependent projects

Answer 5

Miałem podobny problem przed, a przyczyną było to, że A jest odniesienie do B był regularnym odniesienia (do pliku DLL), raczej niż „Projekt referencyjny ". Ta sytuacja z pewnością wyjaśniłaby zachowanie, które widzisz. Aby sprawdzić, spójrz na ProjectA.csproj w edytorze tekstu i sprawdź wszystkie elementy <Reference> i <ProjectReference>, aby upewnić się, że są one takie, jakie Twoim zdaniem powinny być.