Ist es üblich/angemessen, dass Komponenten von Drittanbietern das Dateisystem nicht dokumentiert verwenden?

Question

Ich habe zwei Drittanbieter-Komponenten für die PDF-Dokumentgenerierung verwendet (in .NET, aber ich denke, das ist ein plattformunabhängiges Thema). Ich werde die Firmennamen für jetzt herauslassen, aber ich werde sagen, sie sind nicht extrem bekannte Anbieter.

Ich habe festgestellt, dass beide Produkte undokumentiert Verwendung des Dateisystems machen (d. H. Put temporäre Dateien auf der Festplatte). Das hat ein Problem für mich in meiner ASP.NET-Webanwendung erstellt, da ich jetzt die Dateispeicherorte identifizieren und Berechtigungen für sie entsprechend festlegen muss. Da meine Webanwendung für den Identitätswechsel mit Windows-Authentifizierung eingerichtet ist, bedeutet dies im Wesentlichen, dass ich Schreibberechtigungen für einige Dateispeicherorte auf meinem Webserver zuweisen muss.

Keine große Sache, sobald ich herausgefunden habe, warum die Komponenten versagten, aber ... ich sehe das als ein Wartungsproblem. Was passiert, wenn wir unsere Server auf ein Betriebssystem aktualisieren, das einen der temporären Dateispeicherorte ändert? Was passiert, wenn der Anbieter den Speicherort der temporären Datei ändert? Unsere Anwendung wird "brechen", ohne eine Zeile unseres Codes zu ändern. Zugehörig, aber wenn wir diese Anwendung auf einer "frischen" Maschine (unabhängig von der Umgebung) aufstellen müssen, müssen wir über dieses Problem Bescheid wissen und die Berechtigungen entsprechend festlegen.

Unglücklicherweise bieten die Komponenten keine Möglichkeit, diesen temporären Dateipfad "konfigurierbar" zu machen, was zumindest etwas deutlicher machen würde, was unter den Abdeckungen vor sich geht. Dies ist

nicht wirklich eine Frage, die ich beantworten muss, sondern eher ein Kick-off für ein Gespräch darüber, ob, was diese Komponente Anbieter tun, ist angemessen, wie dies sollte für die Nutzer dokumentiert/mitgeteilt, usw.

Gedanken? Meinungen? Bemerkungen?

Answer 1

Zuerst würde ich fragen, ob diese PDF-Generierungstools für die Ausführung in ASP.NET-Anwendungen entwickelt wurden. Machen sie Behauptungen, dass dies etwas ist, das sie unterstützen? Wenn ja, sollten sie eine Dokumentation darüber bereitstellen, wie sie das Dateisystem verwenden und welche Berechtigungen sie benötigen.

Wenn nicht, dann verwenden Sie wahrscheinlich einen ungeeigneten Werkzeugsatz. Ich war hier und habe das getan. Ich arbeitete an einem Projekt, bei dem ein "wohlbekanntes Adress-Lookup-Tool" verwendet wurde, aber die von uns verwendete Version wurde für Desktop-Apps entwickelt. Als solches wurde es nicht geschrieben, um mit 100 Anfragen zu bewältigen - viele gleichzeitig - und es verursachte alle Arten von schwer zu wiederholenden Fehlern.

Answer 2

Alltäglich? Ja. Angemessen? normalerweise nicht.

Temp-Dateien sind eine der geeigneten Anwendungen IMHO, solange sie den richtigen% TEMP% -Ordner verwenden oder noch besser, verwenden Sie die integrierten Path.GetTempPath/Path.GetTempFileName-Funktionen.

In einer idealen Welt kommt jede Drittanbieterkomponente mit einer Code Access Security Beschreibung, die im Detail aufführt, was benötigt wird (und für welchen Zweck), aber CAS ist möglicherweise eine der meist ignorierten Funktionen von .net.

Answer 3

Schreiben von temporären Dateien würde nicht außerhalb der normalen Funktion irgendeiner Software betrachtet werden. Es sei denn, dass es Temp-Dateien an einen wirklich bizarren Ort schreibt, scheint dies eher etwas zu sein, von dem sie nie dachten, es zu dokumentieren, anstatt ihnen aus dem Weg zu gehen, um Ihnen Ärger zu machen. Ich würde einfach den Verkäufer kontaktieren, erklären, was Sie tun und fragen, ob sie Dokumentation zur Verfügung stellen können.

Auch Martin macht einen guten Punkt darüber, ob es eine App ist, die mit Asp.net oder einer Desktop-App laufen sollte.