Ich habe ein Sitecore / ASP.NET-Projekt, das ich entwickle. Heute habe ich versehentlich die "Clean" -Option im Lösungskontextmenü getroffen. Ich brauchte eine Weile, um herauszufinden, warum meine Seite hoffnungslos kaputt war. Es stellte sich heraus, Visual Studio ging voran und löschte mehrere erforderliche Assemblys aus dem Verzeichnis \ bin, die nicht Teil meines Projekts sind.
Wie kann ich verhindern, dass dies erneut passiert?
Das Seltsame ist, dass es NICHT alles gelöscht hat ... nur eine kleine Handvoll. Es hat viele hinterlassen, auf die mein Projekt nicht direkt verweist. Das lässt mich fragen, was genau dieses Feature tun soll? Gibt es eine Art Dateiflag, die ich einstellen kann? Keine der Dateien ist schreibgeschützt. Wenn Sie an Details interessiert sind, wurde Folgendes gelöscht:
Sitecore.Analytics.dll
Sitecore.Client.XML
Stimulsoft.Base.dll
Stimulsoft.Report.dll
Stimulsoft.Report.Web.dll
Stimulsoft.Report.WebDesign.dll
Telerik.Web.UI.dll
UPDATE : Sie wissen was ... Ich denke, was mich hier wirklich interessiert, ist, WARUM Visual Studio die meisten Dateien belässt und nur diese löscht.
Die richtige Antwort auf Ihr Problem hängt davon ab, wie Sie auf die Assemblies verweisen und wie Sie sie in Ihre Projektausgabe aufnehmen.
Die Ordner bin und obj , die von einem Projekt generiert werden, werden am besten als "Ausgabeordner" betrachtet. Diese Ordner sollten nur Dateien enthalten, die vom Projekt-Build erstellt wurden.
Wenn Sie ein Projekt säubern oder neu erstellen, werden alle zwischengeschalteten und kompilierten Dateien aus diesen Ordnern gelöscht.
Sie sollten sich sicher sein, dass dies geschieht.
Sie können diese Ordner wiederherstellen, indem Sie den Build-Prozess jederzeit ausführen. Wenn Sie Dateien direkt zu diesen Ordnern hinzugefügt haben, wird der Zweck dieser Ordner aufgehoben und Sie sollten überdenken, wie Sie diese Dateien hinzufügen.
Die bevorzugte Methode, kompilierte Assemblys zu referenzieren, besteht darin, sie irgendwo in Ihren Quellordnern hinzuzufügen. Von dort aus können sie so einfach wie jede andere Datei zu einem Versionskontrollsystem hinzugefügt und von Projekten, die von ihnen abhängen, referenziert / kopiert werden. In meiner Arbeit haben wir einen Ordner "Bibliotheken", der zahlreiche Baugruppen von Drittanbietern enthält, die von mehreren Projekten in unserer Lösungshierarchie referenziert werden.
Versuchen Sie, einen Quellbaum wie diesen zu verwenden und zu sehen, ob er für Sie funktioniert:
Platzieren Sie die DLLs in einem anderen Verzeichnis. Sie werden sie wahrscheinlich nicht als Teil des Projekts wollen. Verweisen Sie die DLLs aus dem neuen Verzeichnis. Beim Kompilieren werden die DLLs in das Verzeichnis bin kopiert.
Ich arbeite mit vielen Projekten und behalte ein bin-Verzeichnis im Stamm meiner Projekte, um Drittanbieter-Dlls genau aus diesem Grund zu speichern.
Beispiel Verzeichnisstruktur:
%Vor%Dies ermöglicht allen Projekten, einen bekannten Referenzort für DLLs von Drittanbietern zu haben, ohne die DLL in jedes Projekt kopieren zu müssen.
Wenn Sie an einem Team arbeiten, sollten Sie sich alle auf eine Standardverzeichnisstruktur für Ihren Code einigen. Das wird dir viele Kopfschmerzen ersparen.
Stellen Sie im Falle von Sitecore sicher, dass Sie die Eigenschaft der Referenz (Sitecore.Kernel, Sitecore.Client, etc) festlegen: 'Lokal kopieren' = false.
Ich glaube, wenn Sie diese Dateien in ein anderes Unterverzeichnis als bin setzen, entfernt Visual Studio sie nicht. Sie können das neue Unterverzeichnis dennoch zu einem Teil Ihrer Einrichtung machen.
Nun, ich werde weitermachen und meine eigene Frage beantworten, denn es scheint die einfachste Antwort zu sein. Ich habe die betreffenden Baugruppen als schreibgeschützt gekennzeichnet. Jetzt werden sie nicht gereinigt.
Ich wundere mich immer noch, warum die meisten anderen nicht gelöscht werden.
Tags und Links asp.net visual-studio sitecore visual-studio-2005