Deine Visual Studio Anwendung beschwert sich über eine fehlende vcruntime140d.dll? Das “d” steht für debug, bitte als “Release”-Version kompilieren.
Deine Visual Studio Anwendung beschwert sich (nun) über eine fehlende vcruntime140.dll? Dann bitte das aktuelle Microsoft Visual C++ Redistributable Package installieren. Achtung: Ob x64 oder x86 entscheidet sich nicht an der Systemarchitektur, sondern an der Programm-Version! Also: Win32-Anwendung läuft nicht -> x86-Package installieren.
hth
Neulich musste ich eine DLL aus Java heraus ansprechen. Zur Wahl stehen JNI und JNA, wobei JNA “nur” ein Wrapper für JNI ist – und bei mir nicht funktioniert hat. In der Theorie ist JNI aber auch nicht schwer, allerdings legt Visual Studio einem mir Steine in den Weg. Ein Grund mehr, bei Java zu bleiben.
Der Java-Teil ist dann auch denkbar einfach:
|
1 2 3 4 5 6 7 8 9 10 |
public class DllBridge { static { // loads file MyDll.dll: System.loadLibrary("MyDll"); } // declare all functions you want to use as "native": public native String hello(String input); // ... } |
Diese DllBridge wird dann in eine Headerdatei übersetzt:
|
1 2 |
// erzeugt DllBridge.h; Achtung: ohne .java: $ javah DllBridge |
Und diese Header-Datei dann in “das” C/C++-Projekt kopiert. An “das” Projekt kommt man wie folgt:
Nachdem man die DllBridge.h in das Projekt kopiert und über Rechtsklick > Include In Project eingebunden hat, kann man ihre Methoden implementieren. O.g. Code erzeugt genau eine Methode Java_DllBridge_hello, siehe DllBridge.h. Deren Implementierung in der .c-Datei:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#include "stdafx.h" #include <jni.h> #include "DllBridge.h" // ! JNIEXPORT jstring JNICALL Java_DllBridge_hello(JNIEnv *env, jobject thisObj, jstring input) { const char *name = (*env).GetStringUTFChars(input, NULL); char msg[60] = "Hello "; strcat(msg, name); (*env).ReleaseStringUTFChars(input, name); MessageBoxA(NULL, msg, "", MB_OK | MB_SYSTEMMODAL); return (*env).NewStringUTF(msg); } |
Alleine die Importe und die korrekte Version von MessageBox herauszufinden, hat sicher eine Stunde gedauert 😡 Oh, Stichwort “Importe”: jni.h wird vom JDK mitgebracht, die entsprechenden Ordner muss man in VS bekannt machen. Das funktioniert nicht über einen Symlink, sondern über die Projekteinstellungen, indem man unter Configuration Properties > C/C++ > General > Additional Include Directories diese drei Verzeichnisse hinzufügt (Rekursion wäre ja auch zu einfach.):
Das Ganze sollte jetzt bauen (Build > Build solution, oder STRG+Shift+B) und eine <Projektname>.dll erzeugen, siehe Konsolenausgabe. Der Name der .dll muss dem im initialen Java-Code entsprechen.
Ein Aufruf von
|
1 2 3 |
DllBridge dll = new DllBridge(); String s = dll.hello("moto"); System.out.println("dll says: " + s); |
öffnet dann die MessageBox:
Sowie die erwartete Ausgabe auf der Konsole. Für reine C-Anbindung könnte man hier aufhören.
Interessant wird es nun, wenn man langlebigere C++-Objekte von Java aus referenzieren möchte. Idee:
(via, längeres Beispiel, Danke Nils!)
Hier sieht das so aus:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
@SuppressWarnings({"SameParameterValue", "unused", "WeakerAccess"}) public class DllBridge { static { System.loadLibrary("MyDll"); } private native long initNative(); private native void destroyNative(long ptr); private native void incrementCounter(long ptr); private long nativePtr; public DllBridge() { nativePtr = initNative(); } public void incrementCounter() { incrementCounter(nativePtr); } public void destroy() { destroyNative(nativePtr); nativePtr = 0L; } @Override protected void finalize() { destroy(); } } |
Bzw. in C++:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
#include "stdafx.h" #include <jni.h> #include "DllBridge.h" class DllBridge { private: int counter; public: DllBridge(); void incrementCounter(); }; DllBridge::DllBridge() { counter = 0; } void DllBridge::incrementCounter() { counter++; printf("increased counter to %d\n", counter); } JNIEXPORT jlong JNICALL Java_DllBridge_initNative(JNIEnv *env, jobject thisObj) { return (long) new DllBridge(); } JNIEXPORT void JNICALL Java_DllBridge_incrementCounter(JNIEnv *env, jobject thisObj, jlong ptr) { DllBridge* bridge = (DllBridge*) ptr; bridge->incrementCounter(); } JNIEXPORT void JNICALL Java_DllBridge_destroyNative(JNIEnv *env, jobject thisObj, jlong ptr) { // TODO? What about the DllBridge's counter? I want my garbage collector delete (DllBridge*) ptr; } |
Aufruf in Java dann:
|
1 2 3 4 5 |
DllBridge dll = new DllBridge(); dll.incrementCounter(); dll.incrementCounter(); dll.incrementCounter(); dll.destroy(); |
Last but not least die andere Richtung, also C++ nach Java. Die Methode
|
1 2 3 4 |
// in DllBridge.java: public void callback(String payload) { System.out.println("C++ says " + payload); } |
lässt sich von C++ aus aufrufen über
|
1 2 3 4 5 6 7 8 9 |
// might be env->GetObjectClass(thisObj) as well; use full qualified path if class has package: jclass javaClass = env->FindClass("DllBridge"); // syntax is "(parameter type)return type" (plus semicolon if not a primitive) // see https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#type_signatures jmethodID callback = env->GetMethodID(javaClass, "callback", "(Ljava/lang/String;)V"); // use CallStaticVoidMethod and pass javaClass, if static method is called env->CallVoidMethod(thisObj, callback, env->NewStringUTF("hi")); |
Weiterführendes dazu hier.
hth
Naiv, wie ich nun einmal bin, war ich davon ausgegangen, dass das Windows Phone SDK einen gewissen Satz an Standard-Komponenten mitbringt. Zum Beispiel einen DatePicker (wie man ihn im Kalender findet) oder einen TimePicker (wie im Wecker). So Sachen halt.
Falsch gedacht.
Dafür muss man das “Windows Phone Toolkit” von http://phone.codeplex.com/ installieren (Achtung: Die URL http://silverlight.codeplex.com/ ist für Windows Phone veraltet!). Anmerkung: Obwohl das sehr nach Silverlight klingt, kann man es auch mit C#-Anwendungen nutzen. Für mich war das nicht selbstverständlich.
Offenbar gibt es verschiedene Möglichkeiten für die Installation; ich habe NuGet verwendet. Das zuerst installieren, (s)eine Solution öffnen, dann unter Tools -> Libarary Package Manager -> Package Manager Console -> “Install-Package WPtoolkit” eingeben. Das Toolkit wird dann nur für diese Solution installiert – was wichtig ist, denn:
Um das Toolkit auch tatsächlich nutzen zu können (obwohl man es ja gerade eben sogar für genau diese Solution installiert hat), muss man nicht nur den entsprechenden Namespace zum Beispiel seiner MainPage.xaml hinzufügen:
|
1 |
xmlns:toolkit="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls.Toolkit" |
Sondern auch “eine Referenz” auf das im Namespace erwähnte “Assembly” hinzufügen. Und das ist schwierig, wenn man sich an die Anleitungen aus dem Internet hält (zum Beispiel diese oder diese). Denn erstens sieht man dort hin und wieder die veraltete URL http://silverlight.codeplex.com/, und zweitens findet man die Assembly-Datei Microsoft.Phone.Controls.Toolkit.dll nicht unter
C:/Program Files (x86)/Microsoft SDKs/Windows Phone/v7.0/Toolkit/Nov10/Bin/Microsoft.Phone.Controls.Toolkit.dll
sondern unter
Z:/pathtomyprojects/MyProject/packages/WPtoolkit.4.2012.10.30/lib/sl4-windowsphone71/Microsoft.Phone.Controls.Toolkit.dll
bzw. analog. Halt nicht an globaler Stelle, sondern lokal im Projekt. Wenn man das weiß, fügt man diese ominöse Referenz wie folgt hinzu:
Solution Explorer -> References -> Rechtsklick, “Add Reference…” -> Browse… -> Microsoft.Phone.Controls.Toolkit.dll aus dem Projektverzeichnis suchen.
Nun sollte man bsplw den TimePicker mittels
|
1 |
<toolkit:TimePicker /> |
nutzen können. Aber: Im Emulator sieht man, dass die Icons für Bestätigen und Abbrechen fehlen:
Das Internet sagt hier, hier und hier, dass man einen Ordner “Toolkit.Content” mit den PNGs “ApplicationBar.Cancel.png” und “ApplicationBar.Check.png” anlegen soll. Also Rechtsklick auf Projekt im Solution Explorer -> Add -> New Folder (ist nur aktiv, wenn der Emulator nicht läuft) -> “Toolkit.Content”. Bei mir gab es daraufhin aber die Fehlermeldung “Cannot add a link to the folder Toolkit.Content. There is already a file of the same name in this folder.” Tatsächlich kann ich den Ordner im Windows Eplorer sehen – und die erwähnten PNGs ebenfalls 🙁 Doch wo sind sie im Solution Explorer, und warum sehe ich sie im Emulator nicht?
Die Antwort auf die erste Frage lautet: Weil das ein weiterer scheiß Bug ist! Visual Studio muss offenbar nach der Installation vom Toolkit neu gestartet werden, dann sieht man plötzlich auch den Ordner. Die Antwort auf Frage 2: Man muss einen Rechtsklick auf jedes PNG machen, und “Include In Project” auswählen. Dann geht’s:
Windows 8 Pro frisch installiert, das Windows Phone SDK heruntergeladen, installiert und gestartet, quasi-leere Demo-App erstellt, “Emulator WVGA 512MB” gestartet – folgende Fehlermeldung (plus drölf weiteren) bekommen:
Error 1 The name “MainViewModel” does not exist in the namespace “clr-namespace:MyApp”.
Vermutung im Internet: Irgendwelche “Assemblies” seien nicht “korrekt” verlinkt. Aha. Kann sein, schließlich habe ich gar nichts verlinkt. Finde ich auch nicht nötig, um ein vorgegebenes Hello-World-Programm zu starten. Was für ein bekackter Bug soll das sein??
Lösung (Schritt 6, Achtung, extrem hässliche Seite): Das Projekt muss auf einer anderen Partitition als Visual Studio abgespeichert sein. WTF. Würde aber zu o.g. Vermutung passen – evt. kommt VS nicht mit relativen Pfaden klar?