Projekt <NAZWA PROJEKTU> nie jest aktualny. Brakujący plik wejściowy "netframework, version = v4.0, profile = client.assemblyattributes.cs

Question

Mam sln z> 50 projektami, a ostatnio, kiedy przeniosłem się do VS2013, za każdym razem, gdy wciskam F5 dla kompilacji, odbuduj wszystkie projekty, mimo że właśnie wykonałem kompilację. Diagnostyka pokazać, że każdy projekt jest oznaczone jako nieaktualne z powodu następującego błędu:

Project <PROJECT NAME> is not up to date. Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework,version=v4.0,profile=client.assemblyattributes.cs 

przeczytałem te wątki:

• In Visual Studio 2010 why is the .NETFramework,Version=v4.0.AssemblyAttributes.cpp file created, and can I disable this?

• https://social.msdn.microsoft.com/Forums/vstudio/en-US/15d65667-ac47-4234-9285-32a2cb397e32/migration-from-vs2008-to-vs2010-and-netframeworkversionv40assemblyattributescpp?forum=vcgeneral

ale sugestią jest dodanie następujących elementów ng wiersz do pliku proj:

<Target Name="GenerateTargetFrameworkMonikerAttribute" /> 

Zrobiłem to i nie zadziałało. Wyłączenie ostrzeżenia jako sugestii MS również nie zadziała, ponieważ projekt pozostanie "nieaktualny".

Używam projektów VS2013, C# i VB. W przypadku tego samego projektu i VS2012 taki błąd nie jest zgłaszany, a projekty są aktualne.

Wszelkie sugestie?

UPDATE Być może warto wspomnieć, że mam kilka definicji budować w roztworze, w którym wszystkie projekty budują dla AnyCPU wyjątkiem jednego: http://screencast.com/t/fuw9k4IubN

Answer 1

<Target Name="GenerateTargetFrameworkMonikerAttribute" /> 

No nie, to dobry pomysł, który stanowi przeciwieństwo problemu, który próbujesz rozwiązać. Zmusza MSBuild do utworzenia pliku AssemblyAttributes.cs, nieuchronnie twój projekt musi zostać przebudowany, ponieważ plik jest nowy. Znalezione Q + A odnosi się do zupełnie innego problemu, , byli to programiści C++, którzy próbowali uporać się z nowym ostrzeżeniem dla łącznika w VS2010. Nienawidzą ostrzeżeń, które pojawiają się znikąd z plików, które nie są częścią ich projektu. Cóż, nie wszyscy. Zaznaczony odpowiedź na to pytanie jest dość SO zło btw, że inny facet pisał znacznie lepszą odpowiedź :)

Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework... 

Jest to sygnał w tym komunikacie zauważyć obecność podkatalogu \2 w tym nazwy ścieżki. To jest duża czerwona flaga, to jest normalna, to jest , a nie. Ten automatycznie generowany plik .cs zwykle znajduje się w katalogu TEMP, a nie w podkatalogu tego folderu. Z pewnością ma to coś wspólnego z twoim prawdziwym problemem.

MSBuild nie robi nic specjalnego i po prostu używa System.IO.Path.GetTempPath() do generowania nazwy folderu. Ta metoda również nie jest specjalna, po prostu przekazuje ją do funkcji winapi GetTempPath(). Dlatego diagnostyka polega na tym, że na tej maszynie budującej ta funkcja systemu operacyjnego czasami generuje nieparzystą ścieżkę, wybierając podkatalog folderu TEMP. I nie zawsze generuje to samo, co powoduje, że twoje projekty są odbudowywane.

Istnieje co najmniej jedna dobra teoria do tego zachowania, wspomniane przez commenter @Darran Rowe do this blog post:

No, this is Terminal Services at work. When you log in over remote desktop, Windows will set the temp directory for the logon session to %LOCALAPPDATA%\Temp\<session id>

Rings dzwon?