.NET / VS Compiler Fehler

Ich habe ein Problem das mich momentan zur Verzweiflung treibt.
Ich arbeite an einer recht komplexen und großen Solution im VS (16 Projecte und etliche tausend Zeilen Code).
Nun habe ich das Problem, dass sich einige Assemblies nicht mehr kompilieren lassen, sobald ich auch nur ein Zeichen in der Quelldatei ändere.

Der Kompiler schmeisst folgenden Fehler:
Unexpected error writing metadata to file 'C:\Src....dll' -- 'Access is denied. '

Nach einger Suche im Netz kam ich auf den folgenden Artikeln von MS KB843552. Ich musste lange bei Microsoft betteln um den Patch zu bekommen. Leider hat der keine Linderung gebracht. Meine cscomp.dll ist neuer als die im Patch...

Der Verzweiflung nahe dacht ich besonders schlau zu sein und das Projekt auf die Beta2 der VS2005 zu "portieren" (es war etwas Arbeit).
Das erschreckende Ergebnis: Auch in der Beta2 von kam der selbe Fehler!

Weiteres Nachfragen bei Microsoft kam zu dem Ergebnis, das ich 200€ zahlen solle, damit man sich dieses Problems anehmen könne!
Der Hinweis, das der Fehler noch im .NET 2.0 und VS2005 enthalten sei wurde "zur Kentnis" genommen... Was immer das heißen mag.

Es liegt auch definitv nicht an der konfiguration der Entwicklermaschine. Der Fehler kommt auf deutschem und englischem Windows XP (Professional) und unter englischem Windows 2003.

Ich bin ziemlich angefressen, da ich nun nach jeder änderung in einer Quelldatei das VisualStudio runterfahren, die gesperrten Dateien löschen und das VisualStudio neu starten muss.
Bei der grösse der Solution dauert das gerne mal 5 Minuten (Dual P4 mit 2,4Ghz). Das bremst meine Produktivität erheblich!

Kennt irgendwer dieses Problem? Hat irgendeiner eine Ahnung, wie man Microsoft davon überzeugen kann, das Bugs in teuer gekauften Produkten nicht gegen Geld gefixed werden sollten?

Hast du versucht nur deine Code Dateien in eine neue Solution zu kopieren (natürlich auch alle Resurcen etz) wenn ja tritt der Fehler dann noch immer auf?? Du kannst auch versuchen die Solutionin den # Developer zu laden und dann die #Develop Solution wieder zurück exportieren zu lassen

Hallo cadi!

Hatte ähnliche Phänomene bei ASP.NET Projekte. Das hatte zumindest bei mir die Ursache mit dem Windows-Index-Dienst.

Beim Erstellen eines neuen ASP.NET Projekts wurde in einen Temp-Ordner geschrieben, und sofort daraufhin gelesen. Da hatte sich aber zwischendrin der Index-Dienst an der Sache zu schaffen gemacht, und wollte indizieren. VS konnte dann nix mehr lesen -> Fehlermeldung.

Vielleicht ist es bei Dir ein ähnliches Problem?

Dann würde ich folgendermaßen vorgehen:

Rechts-Klick auf Arbeitsplatz -> Verwalten -> Dienste & Anwendungen -> Index-Dienst -> System -> Verzeichnisse

Dann ein neues Verzeichnis erstellen und dort mal das betroffene Verzeichnis eintragen und gleichzeitig den Index-Dienst auf "nein" stellen.

Vielleicht hilft Dir das?

Anbei sende ich mal ein Bild von der Einstellung im Index-Dienst (Win2000 engl.)...

Ciao
Norman-Timo

Hallo norman_timo,

ich hatte bereits einen ähnlichen Verdacht. Für mich war der Virenscanner der erste heiße Kanditat. Aber weder der Virenscanner noch der Indexserver ist der Verursacher.

Dagegen spricht auch, das die Datei solange offen ist, bis das VisualStudio geschloßen wird. Danach läßt sie sich problemlos löschen.

Eigenartig ist, das der Fehler auch dann noch auftritt, wenn nur da VisualStudio neu gestartet wird, die Datei aber vorher nicht gelöscht wird.

Und ich vergass den alternativen Compiler-Fehler zu erwähnen
error CS0016: Could not write to output file 'C:\Src....dll' -- 'The process cannot access the file because it is being used by another process. '

Die Ursache für die beiden Fehler scheint aber die selbe zu sein.

Arghn! Ich könnte den halben Tag lang fluchen (das ist etwa die Neustartzeit pro tag...)

Hallo cadi!

Hast Du doppelte Verweise, oder aber VS mehrfach offen? (Doppelter Verweis -> mehrere Projekte, die denselben Output erzeugen.

Wird die DLL tatsächlich von einem anderen Prozess benutzt, z.B. Win-Dienst? (dürfte ja eigentlich nicht sein, dann liesse sich die auch nach dem Schließen nicht löschen).

Hast Du mal versucht die betroffenen Projekte in einer separaten Solution in VS zu öffnen (also nur die .csproject in eine neue Solution einzubinden?) Tritt der Fehler dann immer noch auf?

Ansonsten ist mein Latein am Ende.

Ciao
Norman-Timo

Die einzelnen Projekte referenzieren sich nur untereinander (das allerdings relativ kreuz und quer).

Das lustige ist, das der Fehler ja während des Compilierens passiert, also nicht nach einem Debug-Run. Da könnte ich ja noch verstehen, das da was offen hängen bleibt.

Es handelt sich auch um eine Desktop-Applikation. Läuft also nicht innerhalb des IIS oder irgendwie als Service.

Der Fehler tritt auch nur auf, wenn ich die Projekte innerhalb der Solution kompiliere. Standalone geht alles prima. Der haken an dieser lösung ist nur, das dann ein umschalten zwischen Debug und Release zu einer echten herausforderung wird, da ja dann die References nicht mehr auf einen Projectoutput sonder eine konkrete DLL zeigen. (ok. man könnte Debug und Release DLL in ein und das selbe Verzeichnis schreiben..)

Was mich dann auch extrem stören würde ist das ich ca. 6 VS offen haben müsste um zu arbeiten und der praktische Right-Click -> Go to Declaration dann auch nicht mehr funktioniert...

Sehr verfahrene Situation....

Mein Vorschlag war zunächst nur als Fehlereingrenzung gedacht. Also gehe ich davon aus, dass irgendwie ein Querverweis Dir hier ein Strich durch die Rechnung macht.

Referenzierst Du eigentlich mit CopyToLocal = True oder False?

Ich arbeite normalerweise mit True, muss dann halt nach jeder DLL Änderung wieder neu referenzieren, aber solche Fehler entstehen dann halt nicht mehr...

Je nachdem was mehr Aufwand bedeutet...

Ciao
Norman-Timo