Project PROJECT NAME ist nicht auf dem neuesten Stand. Fehlende Eingabedatei 'netframework, version = v4.0, profile = client.assemblyattributes.cs

8

Ich habe eine sln mit & gt; 50 Projekte, und vor kurzem, als ich zu VS2013 wechselte, wird jedes Mal, wenn ich F5 für einen Build drücke, alle Projekte neu erstellt, obwohl ich gerade einen Build durchgeführt habe. Die Diagnose zeigt, dass jedes Projekt als nicht aktuell mit dem folgenden Fehler markiert ist:

%Vor%

Ich habe diese Themen gelesen:

aber der Vorschlag besteht darin, der proj-Datei die folgende Zeile hinzuzufügen:

%Vor%

Ich habe es getan und es hat nicht funktioniert. Das Unterdrücken der Warnung als MS-Vorschlag funktioniert ebenfalls nicht, da das Projekt "nicht auf dem neuesten Stand" bleibt.

Ich verwende VS2013, C # und VB Projekte. Mit dem gleichen Projekt und VS2012 wird dieser Fehler nicht ausgelöst und die Projekte sind auf dem neuesten Stand.

Irgendwelche Vorschläge?

UPDATE Vielleicht ist es erwähnenswert, dass ich ein paar Build-Definitionen in der Lösung habe, in der alle Projekte für AnyCPU erstellt werden, außer einem: Ссылка

    
checho 22.12.2014, 11:34
quelle

1 Antwort

3
%Vor%

Nun, keine gute Idee, die das genaue Gegenteil des Problems, das Sie zu lösen versuchen, erreicht. Es zwingt MSBuild, die AssemblyAttributes.cs-Datei zu erstellen, Ihr Projekt muss zwangsläufig neu erstellt werden, da die Datei neu ist. Das Q + A, das Sie gefunden haben, adressiert ein vollständig anderes Problem, das waren C ++ - Programmierer, die versuchten, mit einer neuen Linker-Warnung in VS2010 zurechtzukommen. Sie hassen Warnungen, die aus dem Nichts von Dateien erscheinen, die nicht Teil ihres Projekts sind. Nun, nicht alle. Die markierte Antwort auf diese SO-Frage ist ziemlich böse, übrigens, dieser andere Typ hat eine viel bessere Antwort geschrieben:)

%Vor%

Es gibt ein Signal in dieser Nachricht, beachten Sie das Vorhandensein des Unterverzeichnisses in diesem Pfadnamen. Das ist eine große rote Fahne, sie ist nicht normal. Diese automatisch generierte CS-Datei befindet sich normalerweise im TEMP-Verzeichnis, nicht in einem Unterverzeichnis dieses Ordners. Sicherlich hat das etwas mit Ihrem wirklichen Problem zu tun.

MSBuild macht nichts Spezielles und verwendet einfach System.IO.Path.GetTempPath (), um den Ordnernamen zu generieren. Diese Methode ist auch nicht speziell, sie delegiert den Job einfach an die GetTempPath () winapi-Funktion. Die Diagnose besteht daher darin, dass auf dieser Build-Maschine diese OS-Funktion manchmal einen Odd-Ball-Pfad erzeugt und ein Unterverzeichnis des TEMP-Ordners auswählt. Und dass es nicht immer das selbe erzeugt, wodurch Ihre Projekte neu aufgebaut werden.

Es gibt mindestens eine gute Theorie für dieses Verhalten, die von Kommentator @Darran Rowe zu dieser Blogpost :

  

Nein, das sind Terminaldienste bei der Arbeit. Wenn Sie sich über Remote Desktop anmelden, legt Windows das temporäre Verzeichnis für die Anmeldesitzung auf %LOCALAPPDATA%\Temp\<session id>

fest

Ruft eine Glocke?

    
Hans Passant 27.07.2015 10:00
quelle