Die geänderte Windows-Systemuhrzeit ist jetzt falsch

950
gh0st

Ich habe in Visual Studio 2013 gearbeitet und an bestimmten Terminen Code für die Ereignisbehandlung getestet. Ich änderte die Windows-Uhr auf 1/1/2016, kompilierte Code in Visual Studio (speziell ein Webprojekt, das ich technisch so veröffentlicht habe) und schob die Dateien in meine Entwicklungsumgebung.

Nach dem Test habe ich meine Systemuhr auf das aktuelle Datum zurückgesetzt und die Codierung fortgesetzt. Wieder veröffentlicht und jetzt stelle ich fest, dass einige der Dateien, die ich seit der letzten Änderung geändert habe, immer noch ein Datum der letzten Änderung vom 1.1.2016 aufweisen. Wenn ich jetzt die Änderungen in dev stecke, weiß ich nicht, dass die Datei geändert wurde und die Änderungen, die ich im Code vorgenommen habe, niemals widerspiegeln.

Wie kann ich das Kompilieren so korrigieren, dass es mit dem aktuellen und korrekten Datumszeitpunkt kompiliert wird?

Ich habe versucht, den Ordner zu löschen, in dem die Veröffentlichung verschoben wird, um zu glauben, dass die aktuelle Systemzeit korrekt verwendet wird. Dies ist jedoch immer noch nicht der Fall.

0
Im Allgemeinen ist es gefährlich, das Datum Ihres Systems zu ändern. Möglicherweise treten später noch mehr Probleme mit Ihrem System auf. - Ich würde versuchen, alle Quelldateien zu "berühren", damit sie das aktuelle Datum erhalten. Nicht sicher, ob Windows über ein Tool verfügt, das einem "Touch" von * nix entspricht. Aganju vor 8 Jahren 2

2 Antworten auf die Frage

2
Frank Thomas
  1. Reinigen Sie Ihre Lösung
  2. Erstellen Sie die Lösung neu
  3. Löschen Sie alle Dateien im veröffentlichten Bereich
  4. Erneut veröffentlichen .

In neueren Versionen von Visual Studio gibt es die Option, alle Dateien im Rahmen des Veröffentlichungsvorgangs zu löschen, zumindest beim Veröffentlichen von Dateisystemen.

Bei der Bereinigung werden die vorhandenen Binärdateien für Ihre Quelle gelöscht. Dies sollte sich auf alle Dateien beziehen, die während der Änderung der Systemzeit erstellt wurden.

Rebuild wird alle Binärdateien von Grund auf neu kompilieren. Diese neuen Dateien sollten die aktuelle Systemzeit widerspiegeln. Vermeiden Sie in einer Randnotiz die Verwendung der regulären Build- Option, da Dateien, die seit ihrem letzten Kompilieren neuer oder unveränderter Code sind, nicht geändert werden.

Durch das Löschen der veröffentlichten Dateien und das erneute Veröffentlichen werden schließlich die neu erstellten Binärdateien ohne die alten Versionen mit durcheinandergebrachten Zeitstempeln exportiert.

Hier finden Sie einige Erläuterungen zu den Unterschieden zwischen Build, Rebuild und Clean: http://www.codeproject.com/Articles/663453/Understanding-Clean-Build-and-Rebuild-in-Visual-St

Bearbeiten: Diese Schritte funktionieren für die meisten VS-Projekttypen, jedoch nicht für herkömmliche ASP.Net-Webforms-Apps, da Aspx-Dateien sowohl Quelle als auch Inhalt aus der Perspektive des Compilers sind und daher nicht während des Builds ersetzt werden.

Selbst nach dem Bereinigen, Wiederherstellen, Löschen des Bereitstellungsordners und anschließender erneuten Bereitstellung der Dateien wird immer noch ein Änderungsdatum der Systemuhr angezeigt. In einem anderen Versuch habe ich die gleichen Schritte ausprobiert und auch "die Website neu aufgebaut". gh0st vor 8 Jahren 0
In welchen Dateien wird der falsche Zeitstempel angezeigt? sind sie Code-Dateien oder Inhalte? Frank Thomas vor 8 Jahren 0
Ungefähr 98% meiner `bin`-Dateien (Codedateien, .aspx.cs`) und` .aspx`-Dateien in Ordnern, die ich geändert habe, als die Zeit auf 1/1/2016 geändert wurde. gh0st vor 8 Jahren 0
Ahh, OK, das ist scheiße. Es gibt keine gute Möglichkeit, die ASPX-Dateien zu korrigieren, da sie während des Kompilierens nicht ersetzt werden, es sei denn, Sie werden mit nicht aktualisierbaren Assemblys vorkompiliert. Dadurch werden nur die veröffentlichten Ausgaben und nicht die Quelldateien selbst korrigiert. Sie müssen jede der Dateien manuell ändern oder Tools wie diese oder Powershell-Skripts verwenden, um sie zu beheben: http://dottech.org/104563/windows-review-smart-timestamp/ http: //blogs.technet .com / b / heyscriptingguy / archive / 2012/06/01 / use-powershell-to-modify-file-access-time-stamps.aspx Frank Thomas vor 8 Jahren 0
Ich bin nicht zuversichtlich, dass eine Änderung des geänderten Zeitstempels in den Bereitstellungsdateien meine Situation vollständig lösen wird. Wenn ich jetzt die Zeitstempel für diese Dateien ändere, kann dies vorübergehend gelöst werden. Wenn ich aber in ein paar Stunden erneut baue, werden diese Dateien möglicherweise mit dem ungültigen Datum erneut vom Build ** überschrieben. gh0st vor 8 Jahren 0
Sie ändern die Daten in den Dateien Ihrer Lösung selbst, nicht die veröffentlichten Kopien. Löschen Sie die veröffentlichten Dateien und veröffentlichen Sie sie erneut. Dann haben Sie keine Dateien mit schlechten Daten. Frank Thomas vor 8 Jahren 1
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/33293/discussion-between-gh0st-and-frank-thomas). gh0st vor 8 Jahren 0
0
gh0st

Visual Studio war Copying all files to temporary location below for package/publish:. Ich habe den temporären Speicherort gelöscht und dann erneut bereitgestellt. Nach Abschluss des Projekts wurde das aktuelle Datum in den Änderungsdatumattributen der Datei gefunden.

Ich bin froh, dass es funktioniert hat. Wo ist dieser temporäre Bereich, den Sie entdeckt haben? Frank Thomas vor 8 Jahren 0

Verwandte Probleme