2016-03-31 4 views
0

Ich arbeite an einem Projekt, das Entwicklern von Drittanbietern eine API mit Vorlagenklassen zur Verfügung stellt, von denen sie erben können. Dieser Entwickler muss den Hauptprozess darüber informieren, dass er einen Typ erstellt hat, der von einer dieser Vorlagen erbt. Dazu ruft der Entwickler eine Funktion:Aufrufen externer Typen, die Dateien über den relativen Pfad aufrufen

internal Dictionary<string, Type> Templates = new Dictionary<string, Type>(); 

public void RegisterTemplate(string ID, Type template) 
{ 
    ... 
    Templates.Add(ID, template); 
    ... 
} 

Hinweis: RegisterTemplate ist Mitglied des Programms nicht von einer externen Bibliothek.

Funktionen in dem Typ ein Entwickler bietet in dieser Funktion relative Pfade wie "Audio/somefile.wav" oder "Models/somefile.vox". Der Fremdentwickler kompiliert ihre vererbenden Klassen in eine DLL und legt sie in einem vom Programm getrennten Ordner ab, um später vom Programm importiert zu werden.

Wenn das Programm die oben fett gedruckten Funktionen aufruft, wird der zugeordnete Pfad relativ zu dem Programm sein, das den Typ aufruft, oder relativ zu der DLL, von der der aufgerufene Typ stammt?


Zur Klarstellung: eher als die relativen Pfade des ausgeführten Assembly oder DLL, ich bin in Bezug auf die Pfade innerhalb der DLL, wie so genannten sprechen:

File.Open("Audio/somefile.wav"); 

Wenn diese Code wird von einer Funktion innerhalb der DLL aufgerufen, und der Typ, der diesen Code enthält, wird von Code in meiner ausführbaren Datei aufgerufen, wird dieser Pfad relativ zu der ausführbaren Datei, die den Type aufgerufen hat, oder der DLL, die den aufgerufenen Typ enthält?

+0

Sind die DLLs auch in C# geschrieben? – Fruchtzwerg

+0

@Fruchtzwerg Mein gesamter Code ist in C#. Der Third-Party-Code kann eine beliebige .NET-Sprache ihrer Wahl sein, vorausgesetzt, dass er in eine verwaltete Bibliothek wie C# kompiliert wird. – TristenHorton

+1

@TristenHorton es ist nicht relativ zu ihnen.Es ist relativ zu ** Anwendung aktuellen Verzeichnis ** (überprüfen Sie Environment.CurrentDirectory) und es ist nicht gebunden an die Ausführung oder Eintrag Montageort (aber ** kann ** bezogen werden, um Montageort, nur nicht darauf angewiesen). –

Antwort

0

Dank an Fruchtzwerg und Adriano Repetti für ihren Beitrag;

Das Verzeichnis, auf das der relative Pfad bezogen ist, hängt von der Umgebung ab, nicht von der ausführbaren Datei oder der DLL, die sie aufgerufen hat. In diesem Fall wird die Current der Umwelt ist das Verzeichnis, das die ausführbaren in enthalten ist

Die Datei wird in diesem Fall geöffnet würde befinden. „C: /.../ Anwendungsverzeichnis/Sounds/somefile.wav“

0

Der Pfad hängt davon ab, wie Sie sie aufrufen.

Zum Beispiel

System.IO.Path.GetDirectoryName(Application.ExecutablePath); 

gibt den Pfad der ausführbaren Datei (auch wenn aus der DLL Aufruf),

System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location); 

würde den Pfad der DLL zurück.

Betrachten Sie diese discussion oder diese post für weitere Informationen und Beispiele.

Abhängig von MSDN ruft die File.Open() - Methode die Directory.GetCurrentDirectory() auf. Sie rufen also Dateien relativ zu Ihrer ausführbaren Datei auf.

+0

Ich fügte meiner Frage einige Klarstellungen hinzu; Ich frage in Bezug auf das Lesen/Schreiben einer Datei, und ob der zugehörige Pfad relativ zu der DLL ist, die den aufgerufenen Typ enthält, oder zu der ausführbaren Datei, die den Typ aufruft. – TristenHorton

+0

Danke! Ich habe meine Antwort bearbeitet. Hoffe ich habe es richtig verstanden. – Fruchtzwerg