Wie kann ich eine Anwendung compilieren, die auf einem Netzlaufwerk liegt?

Hallo,

ich kann seit ich meine programmdaten auf deinem Netzlaufwerk speichere, meine Programme nichgt mehr Compilieren da er mir immer folgende fehlermeldung ausgibt:

Fehlermeldung:
Die Datei "form_main.resx" konnte nicht verarbeitet werden, weil sie sich im Internet oder in der Zone eingeschränkter Websites befindet oder die Webmakierung aufweist. Entfernen sie die Webmakierung, wenn sie diese Dateien verarbeiten möchten.

Was kann ich machen damit diese meldung nicht mehr kommt?

MfG Daniel S.

Am besten immer nach der englischen Fehlermeldung suchen, hier z.B. "Visual Studio error file could not be processed internet restricted zone":
Couldn't process file resx due to its being in the Internet or Restricted zone or having the mark of the web on the file (m.E. die beste Antwort ist bzgl. "Visual Studio -> Tools -> Options -> Trust Settings").

habe ich bereits auch schon gesehen, aber bei mir geht das nicht

Dass Du Deine Programmdaten (während dem Entwickeln) auf einem Netzlaufwerk speicherst ist keine gute Idee und war es auch noch nie - und der Grund des Problems.
Das mögen die meisten Entwicklungstools unter Windows nicht, weil Windows Inhalte auf Netzlaufwerken besonders behandelt und erstmal von einer unsicheren Quelle ausgeht.

Langfristig vermeidest Du das, wenn Du einfach - wie üblich und empfohlen - von Deinem direkten Laufwerk aus programmierst.

Das Trusten über die Dateiaktion (File Properties) ist der übliche Weg des Fixes.
Dein Vorgehen jedoch der Grund; der im Zweifel immer wieder kommt.

es ist völlig normal dass man Programmdaten auf einem Netzlaufwerk speichert.
Wozu gibt es NAS, Clouds usw.
Aber das ist kein Problem, man muss nur sein Netzlaufwerk zu den trusted Quellen hinzufügen und schon funktioniert das mit Windows hervorragend.

Windows-Suche: "internet option"
man wird zum richtigen Dialog kommen,
dort zum Reiter "Sicherheit" und "Lokales Intranet" auswählen.
Dann den Button "Sites" anklicken
Dann den Button "Erweitert" anklicken
und im Eingabefeld eintragen:
file://IPadresse_des_Netzlaufwerks
(unten bei Sicherheitsüberprüfung darf kein Haken sein).
OK und fertig.
Ab sofort kann man von seinem Netzlaufwerk problemlos arbeiten.

viele Grüße
Harry

es ist völlig normal dass man Programmdaten auf einem Netzlaufwerk speichert.
Wozu gibt es NAS, Clouds usw.

Ironischerweise für viele Dinge; aber nicht für diesen Anwendungsfall.

Eine Cloud hat extreme Vorteile in Sachen Kollaboration, Skalierung, Verfügbarkeit, Kosteneffizient etc. Aber es gibt einen Faktor, der sowohl für die NAS und für die Cloud (Remote) gilt, der nicht direkt erfüllbar ist, und das ist: Latency.
Und welcher Faktor ist für das direkte Entwickeln von Software und den Umgang mit Quellcode-Dateien einer der wichtigsten Faktoren überhaupt? Tja, doof: Latency.
Der Faktor Latency ist auch der, wieso es für so viele Cloud-Architekturen einen hybriden Ansatz gibt; durch die Edge-Implementierung versucht man den Latency-Impact (und die Bandbreite) zu optimieren bzw. gering zu halten.

Für das Thema hier: die Latency zum Quellcode-Speichermedium ist hauptverantwortlich dafür, dass eine Entwicklungsumgebung schnell ist, dass Quellcode schnell getestet werden kann und der Entwickler Code effizient entwickeln kann.
Daher wirst Du auch in jedem Performance-Guide von Entwicklungsumgebungen (zB in den MSDocs Verbessern der Leistung, wenn Visual Studio langsam ist) auch einen wichtigen Punkt finden: entwickle Deinen Code auf einer SSD.

Vergleich des Forencodes via dotnet build hier auf meiner Maschine mit SSD, HDD und über die NAS:

SSD:
Time Elapsed 00:00:03.53
C:\source\MyCSharp\MyCSharpNET>

HDD:
Time Elapsed 00:00:32.06
F:\MyCSharp\MyCSharpNET>

NAS:
Time Elapsed 00:03:42.17
\nas\p\MyCSharp\MyCSharpNET>

HDD is Faktor 10 langsamer, NAS Faktor 70.
Das ist natürlich nicht für jedes Projekt in dem Faktorrahmen; und auch werden sich hier Maschine zu Maschine unterscheiden - aber zeigt die Effizienzunterschiede schon sehr.
Und jetzt starte den Build nicht nur ein mal am Tag, sondern 50 mal am Tag... 😉
Und Dinge wie Live-Unit Testing werden mit HDD / NAS-Builds quasi unmöglich.

Die technischen Gründe sind extrem simpel:

• SSDs liefern nativ so um die 60.000 IOP/s; Profi-SSDs mittlerweile auch 1 Million
• Eine NAS liefert so zwischen 100 und 500 IOP/s über das Netzwerk; Profi-Geräte hier durchauch auch im Bereich von 2000.
• Eine Cloud-VM so im Schnitt 1500; geht auch mehr, aber mit entsprechendem Geld dahinter.

Im Endeffekt kennt das Verhalten jeder, der mal Daten von Festplatte zu Festplatte kopiert hat oder von Festplatte zu Netzwerk; durch die geringere Bandbreite und die IOPs ist letzteres einfach viel viel langsamer - aber hat auch einfach einen anderen Zweck.
Doof ist jedoch, dass eine Entwicklungsumgebung die Quelldateien eben nicht lokal holt, sondern roh vom Speichermedium liest; wenn also die IDE immer über das Netzwerk auf den Quellcode zugreifen muss, und dann auch noch für jeden Build alles laden muss, dann wird das eben zwangsläufig langsam - by Design.
Wer mit älteren Visual Studio Versionen Projekte von Netzwerklaufwerken geladen hat, der hatte quasi ständig "Anwendung reagiert nicht"; weil VS damals das Laden offenbar im UI Thread hatte und entsprechend alles dauernd eingefroren ist.

Bei Netzwerk-basierten externen Speichermedien wie einer NAS oder einen CIFS-Laufwerk in der Cloud hat zusätzlich den Nachteil, dass eben über CIFS/SMB die Daten ausgetauscht werden; also einem Netzwerk-Protokoll, das ineffizienter wird, wenn die jeweiligen Dateien kleiner sind.
Und da Quellcode-Dateien meist klein sind, weil Textdateien, erreichst Du über das Netzwerk genau eines: langsamer und ineffizienter geht es nicht mehr.
Je größer ein Projekt ist, desto langsamer wirds. Daher arbeiten auch eher Hobby-Entwickler direkt auf einem externen Speichermedium als Profis; einfach weil Hobby-Entwickler in den aller meisten Fällen viel kleinere Projekte haben und diese Nachteile weniger spüren / es ihnen nichts ausmacht.

Cloud-Services (gibt ja nicht nur "die Cloud"), die mit Remote-Code arbeiten, arbeiten daher vor allem damit, dass der Quellcode lokal synchronisiert wird; wie eben zB. über Git.
Alle anderen Dienste, die quasi nur Laufwerke für Code angeboten haben, haben sich bis heute nicht durchgesetzt.

Selbst direktes Entwickeln in der Cloud, also zum Beispiel GitHub Code Spaces, ist eher so eine Nischensache bislang; es ist einfach "Coden im Browser "- und so fühlt es sich auch an. Es ist für mich so extrem weit weg von einer Experience wie in Visual Studio oder Visual Studio Code, dass es für mich, und offenbar für relativ viele, noch keiner Alternative ist; aber kenne auch einige, die mögen das.

Ist es also "normal", dass Quellcode auf einer NAS liegt und man damit direkt entwickelt? Nein.
Ist eine NAS oder eine Cloud für diesen Anwendungsfall gemacht? Nein.
Kann man es trotzdem machen? Klar.