Hier ist das Beste, was ich mir vorstellen kann. Es funktioniert, aber es gibt einige Schritte, die Sie möglicherweise nicht ausführen möchten.
Im Wesentlichen besteht die Technik darin, die Dateien Ihres Projekts beim Ausführen der Anwendung auf "Nur Lesen" zu setzen und sie dann wieder auf schreibbar zu setzen, sobald Ihre Anwendung beendet ist.
In VS2k8 können Sie die Datei jedoch standardmäßig nur schreibgeschützt bearbeiten. Sie müssen zuerst die Einstellung "Bearbeiten von schreibgeschützten Dateien zulassen" in Tools & gt; Optionen & gt; Umwelt & gt; Unterlagen.
Zweitens müssen Sie der Registrierung den folgenden Schlüssel als DWORD hinzufügen und den Wert auf 1 setzen:
%Vor%Dieser still funktioniert nicht vollständig. Was Sie dann tun müssen, ist, Ihre Quellcodeverwaltung für dieses Projekt auf Visual Source Safe zu setzen. (& lt; - das ist der Schritt, von dem ich annehme, dass er dir nicht gefallen wird.)
Starten Sie VS2k8 neu.
Wenn Sie an dieser Stelle festlegen, dass eine Ihrer Dateien schreibgeschützt ist, werden Sie sehen, dass Visual Studio diese Datei überhaupt nicht bearbeiten kann. Wenn Sie es versuchen, wird die Ausnahmemusik Ihres Computers abgespielt.
Um Ihre Dateien beim Ausführen der App schreibgeschützt zu machen, legen Sie einen Post-Build-Prozess fest. Das ist einfach.
Schwieriger ist es, sie wieder schreibbar zu machen, sobald Ihre App fertig ist. Die einfachste Lösung ist wahrscheinlich eine Batchdatei-Verknüpfung.
Hey - Entschuldigung, ich kann dir nicht helfen, deinen Code komplett zu sperren - ich habe den gegenteiligen Wunsch: während des Debuggens das ganze UNLOCK zu lösen, aber ich kann dir bei deinem zweiten Problem helfen.
Ich schlage vor, dass Sie in Erwägung ziehen, das aktive Fenster vor dem Senden von Schlüsseln zu überprüfen, und wenn das aktive Fenster anders als Ihre Zielwebsite ist, unterbrechen Sie die Ausführung Ihres Tests, bis der Fokus dieses Fensters zurückgegeben wird.
Ich weiß, es ist nicht die Lösung, die Sie wollen, aber es würde wahrscheinlich nicht schaden, andere ähnliche Probleme zu vermeiden.
Viel Glück!
Adam
Ich habe mich gefragt, ob es eine Möglichkeit gibt, meinen Code beim Debuggen in Visual Studio 2008 vollständig zu sperren. Die Code-Dokumente werden automatisch gesperrt, wenn sie als 64-Bit-Anwendungen ausgeführt werden, was ich sehr bevorzuge. Allerdings mache ich die meisten meiner Programmierung Add-Ins für Excel, die 32 Bit ist. Das Ergebnis ist, dass, obwohl ich "AnyCPU" target, der VS-Host weiß, dass es in einem 32-Bit-Prozess ausgeführt wird und daher der Quellcode nicht gesperrt ist, während der Code in Visual gehostet ausgeführt wird Studio.
Ich kann Edit und Continue ausschalten, indem ich zu Tools & gt; Optionen & gt; Debugging & gt; Bearbeiten und fortfahren und dann das Kontrollkästchen "Aktiviert Bearbeiten und Fortfahren" deaktivieren. Dies sperrt den Code jedoch nicht vollständig. Dies verhindert zwar, dass Änderungen im Code im aktuellen Lauf ausgeführt werden, verhindert jedoch nicht, dass Mausklicks oder Tastenanschläge den Code tatsächlich ändern.
Auch beim Arbeiten mit 64-Bit-Anwendungen tritt dies nicht auf - der Code ist vollständig gesperrt. Ich bevorzuge es, den Code aus mindestens zwei Gründen vollständig zu sperren:
Ich kann beim Debuggen versehentlich eine Taste oder Ähnliches drücken, was ich definitiv nicht tun möchte. Es ist selten, aber es ist ein Problem.
Viele meiner automatisierten Tests steuern die Benutzeroberfläche über SendKeys. Beim Durchlaufen eines solchen Tests mit dem Debugger kann ich jedoch manchmal vergessen, dass einige der Aspekte SendKeys betreffen, was bedeutet, dass die Tastaturanschläge an die Visual Studio-IDE anstatt an Excel gesendet werden.
In Frage 2 oben schlägt der Komponententest fehl, was in Ordnung ist - mein Fehler - aber alle Tastenanschläge, die an das Codemodul gesendet werden und meinen Code zu zerstören, sind völlig inakzeptabel.
Hat jemand hier irgendwelche Ideen? Kann man den Code vollständig sperren, wenn er in Visual Studio gehostet wird, während er mit einer 32-Bit-CPU kompiliert wird?
Einige verwandte Beiträge zu diesem Thema, von denen jedoch keines direkt darauf eingeht:
Vielen Dank im Voraus für jede Hilfe oder Ideen ...
Mike
Hier ist ein Trick, den ich unter Visual Studio 2005 verwende (habe keine Chance, unter Visual Studio 2008 zu testen, aber es sollte funktionieren):
Die Codedokumente sollten gesperrt bleiben, selbst wenn ein Haltepunkt erreicht wird, und jeder Versuch, sie zu ändern, sollte ein Popup-Fenster mit der Aussage "Änderungen sind nicht erlaubt, wenn das nicht verwaltete Debugging aktiviert ist" auslösen >