(08.05.2010 17:02 )rolfk schrieb: [ -> ]Der Geschwindikeitsgewinn liegt im Bereich von 1 bis 2 % ist also absolut unrelevant.
Ja, da bringt es im Zweifel mehr, bei kritischen (oder allen) VIs das "Allow debugging" auszuschalten.
Nicht zu verwechseln mit der Buildoption "Enable debugging". Die wirkt sich nicht auf die einzelnen VIs aus.
(10.05.2011 11:50 )NWOmason schrieb: [ -> ]Kurz gesagt: Gar nicht.
Hi, danke erstmal für die Antwort.
Ich nutze die Full Version. Dass man den AppBuilder braucht war schon klar, sorry für die unklare Ausdrucksweise :-)
Hätte mich nur interessiert, obs auch Alternativen gibt. Da dem wohl nicht so ist werde ich mir früher oder später den AppBuilder holen müssen....
Mich würde interessieren welche Einstellungen man genau machen muss wenn man
eine VI durch den App Builder laufen lässt.
Wir brauchen diesen um es in ein externes Programm einzubinden.
Ich versuche mich gerade an den Shared Librarys, weil die .NET Interop Assembly nachrangig sind.
In den Einstellungen "Source Files" füge ich dazu testweise eine ganz billige VI ein (Input int -> increment -> Output Int.
Nur verstehe ich bei Define VI Prototype die Einstellungen nicht ganz.
Dazu kommt, (nicht im Zielprogramm) dass im IL DASM immer "falsche CLR-Header" dies ist aber, so hat es die LBVF-Suche ergeben, weil ich eben keine! .NET Assemblys erstelle.
Also welche Variablen ich wie zuweise.
Gibt es sonst noch irgenwelche relevanten Einstellungen
(ausser include Headers bei Advanced & remove etc.bei Additional Exclusions) die der Grund sein könnten
warum mein externes Proggi die .dll nicht laden möchte?
Gruß
P.S.:
Leider kann ich mit einer detailliierten Fehlermeldung nicht dienen:
Code:
DLL kann nicht geöffnet werden
Zeile: 48, Spalte: 100