Missing vcruntime140.dll / vcruntime140d.dll

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

Java: C/C++ über JNI einbinden

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:

Diese DllBridge wird dann in eine Headerdatei übersetzt:

Und diese Header-Datei dann in “das” C/C++-Projekt kopiert. An “das” Projekt kommt man wie folgt:

  • Visual Studio installieren; ich habe Visual Studio Community 2017 mit den Standardkomponenten genommen
  • Neues C++/Win32-Projekt anlegen, im Dialog unter “Anwendungseinstellungen” den Anwendungstyp “DLL” wählen
  • Ich habe das Projekt testweise MyDll genannt, die entstehende .dll heißt später genauso

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:

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.):

  • C:\Program Files (x86)\Java\jdk1.8.0_121\include
  • C:\Program Files (x86)\Java\jdk1.8.0_121\include\win32
  • C:\Program Files (x86)\Java\jdk1.8.0_121\include\win32\bridge
    PS Ja: Das ist ein 32-Bit-Java, weil ich letztlich eine 32Bit dll ansprechen will.

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

ö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:

  • Eine Klasse auf Java-Seite, die die dll lädt, sowie die nativen Methoden bereitstellt, und eine Klasse auf C++-Seite, die diese implementiert
  • Die C++-Klasse wird initialisiert, ihren Pointer gibt man in Form einer long an Java zurück (bzw. jlong, vgl. hier), vermutlich ist das die Speicheradresse
  • Über diese long kann Java dann das Objekt referenzieren
  • Braucht man das C++-Objekt nicht mehr, wird es deleted.

(via, längeres Beispiel, Danke Nils!)

Hier sieht das so aus:

Bzw. in C++:

Aufruf in Java dann:

Last but not least die andere Richtung, also C++ nach Java. Die Methode

lässt sich von C++ aus aufrufen über

Weiterführendes dazu hier.

hth

Windows Phone 8 Apps: Controls-Toolkit

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:

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

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 Phone 8 Apps: “The name MainViewModel does not exist in the namespace”

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?