Exe ohne die Entwickungsumgebung testen

Wenn ich ein kompiliertes Programm auf demselben PC teste, auf dem das Programm entwickelt wurde, dann kann es vorkommen, daß sich das kompilierte Programm nicht mit einkompilierte Bibliothekselemente aus der Entwicklungsumgebung besorgt, ohne das man das merkt. Am eigentlichen Einsatzort kommt dann das böse Erwachen
Da ich zum zum Testen nicht die ganze Hardware auf einem anderen PC installieren wollte, kam mir die Idee, den Programmpfad c:ProgrammeNational InstrumentsLabVIEW 8.2 während des Tests vorübergehend durch Umbennenung zu verstümmeln.
Leider schlug der Versuch fehl, das Verzeichnis ist schreibgeschützt. Dieser läßt sich zwar entfernen, aber irgendein im Hintergrund laufender Dienst (oder was weiß ich) stellt den Schreibschutz sofort wieder her.
Was kann man dagegen tun? Oder kennt jemand eine bessere Methode, das Programm so zu testen, als wäre die Entwicklungsumgebung nicht vorhanden? Oder sind vielleicht meine Befürchtungen gegenstandslos und die EXE stiehlt sich niemals Dateien aus der Entwicklungsumgebung?
Ludwig

' schrieb:Oder sind vielleicht meine Befürchtungen gegenstandslos und die EXE stiehlt sich niemals Dateien aus der Entwicklungsumgebung?
Ludwig

100%ig sicher bin ich mir nicht, aber ich hab das noch nie erlebt. Ich hab schon mehrere Applikationen erstellt, die ausschließlich mit der LabVIEW Runtime Engine auf einem Rechner laufen, auf dem keine LV Entwicklungsumgebung insalliert ist. Wenn man die *.exe baut werden normalerweise alle DLLs, die benötigt werden in das data-Verzeichnis kopiert und für Hardware, etc ... muss man sowieso den DAQ installieren.

Wenn du es wirklich unabhängig testen willst empfehle ich einen Testrechner oder VMware(?) ...

Ich empfehle auch VMWare, ich teste alles damit. Es gibt eine kostenlose 1-jahres Lizens dafür. Es ist wirklich eine tolle Sache.

Gruss, Eugen

Vielen Dank für Eure Antworten, es hat mir weitergeholfen.
@eugen
Sehr gute Idee, ärgerlich ist nur, daß ich da nicht selbst darauf gekommen bin..
@i2dx
Beim Test hat sich jetzt herausgestellt, was der Fehler war: Der Applikation Builder hatte sich geweigert, die Bibliotheksdatei lvdaq.dll mit in das Programm hineinzunehmen.
Dazu muß ich aber sagen, daß ich ein vor drei Jahren mit alten DAQ-Treibern erstelltes Programm aufgmotzt habe, die alten Treiber aber beibehalten habe. Damit LV8.2 damit überhaupt funktionierte , hatte ich das komplette Verzeichnis "Daq" aus einer anderen LV-Version in das Verzeichnis vi.lib von LV8.2 hineinkopiert. In diesem Verzeichnis befindet sich auch die oben genannte fehlende Bibliotheksdatei.
Richtig erklären kann ich mir's zwar immer noch nicht, aber vielleicht hängt der Fehler damit zusammen, daß das gesamte Verzeichnis Daq in LV8.2 gar keine legale Existenzberechtigung hat.
Jedenfalls habe ich einfach lvdaq.dll mit in das Verzeichnis gepackt, in dem sich die EXE befindet, und es funktioniert. Wenn ich das jetzt weiß, kann ich natürlich auch den Compiler anweisen, diese Datei mit hineinzunehmen, wenn er das freiwillig nicht tut.
Gruß Ludwig