I want to debug code written in C. Currently, Android Studio 1.2.2 does not seem to support JNI debugging.
Does Android Studio 1.3 RC 1 version support step over, step into as Java debugger?
Android Studio supports JNI debugging first time with 1.3 RC 1. See here
To get started using this feature, go to add native code.
Check this repository for Android NDK samples using the new Android Studio 1.3 preview C++ integration.
It is supported, but with limitations.
Limitations
First, the Android NDK support only works with the new experimental Gradle plugin for Android (which in turn requires Gradle 2.5).
While the new gradle plugin delivers some major performance improvements (and Android NDK build support), note that it also requires changes to the build file “DSL” (the way your build is described in your build.gradle files.) Not only will you need to modify your build.gradle files (a process we hope to automate before the plugin graduates from experimental to stable), but we anticipate making some additional incompatible changes along the way.
Second, note also that Android Studio has not yet been updated to fully handle the experimental plugin. This means that for example the Project Structure Dialog, and various quick fixes which automatically update the build data, do not work correctly. You’ll need to edit your build.gradle files manually to configure your projects. As another example, the various templates which update the build files (such as New Module), have not yet been updated.
Finally, there are still some known bugs in this build; when debugging with LLDB breakpoints do not always work on Windows; if you run into this, you can switch to GDB debugging as a temporary workaround.
Source: http://tools.android.com/tech-docs/android-ndk-preview
If your native code is wrapped as a library, you need to add this part to your app's gradle:
model {
android.sources {
main {
jniLibs {
dependencies {
project ":mynativelib" buildType "debug"
}
}
}
}
Related
I am a small software developer who builds a plugin-based app. Each plugin is its own assembly and references the main assembly like so:
Plugin 1 references nuget packages and Application Core.dll
Plugin 2 references nuget packages and Application Core.dll
At run time, the main assembly loads all the assemblies in its current folder and enumerates them for plugins. Right now, all my projects build to the same folder. I like doing that because I can just press F5 to run my solution in Visual Studio. This is also nice because I can just disable a project in the solution if I don't want to run that plugin.
Some plugins now require a specific version of a nuget package. For example:
Plugin 1 requires System.Net.Http 4.0.0 or above
Plugin 1 requires System.Net.Http 4.3.4 or above
When I build my project, sometimes plugin 2 builds first which means that plugin 1 or 2 will overwrite system.net.http 4.3.4 with version 4.0.0.
What is the best way for me to avoid overwriting DLLs with older versions but still have the ease-of-development that I'm used to?
One solution, which you may not like, is to stop using dynamic loading. If your app uses Plugin 1 and Plugin 2, make them NuGet or project references and let the build system figure out minimum versions of all common packages for you. You will also no longer need to change all the build output paths to get an easy development experience. Just use feature-flags/configuration to allow customers to choose the features they want, rather than adding/deleting dlls.
Another option is to keep each plugin in their own folders with all of their own dependencies and the main program loads plugins in different App Domains. this only works on .NET Framework, not .NET Core, but it does have the advantage that a plugin that crashes has less chance of crashing the whole app. the program may be able to detect a crashed plugin/app domain and unload it. But app domains are almost like using different processes and you have inter-domain communication issues (everything must be serialisable)
I'm going to create my first managed plugin for Unity (2018.2) using Visual Studio Community for Mac (7.6.11 build 9).
I've read the documentation but I think that the step-by-step instructions are not meant to be followed on Visual Studio Community for Mac.
As you can see in the screenshot below, I've created several projects using each and every library template available.
All of them compiled successfully to a DLL targeting versions of .NET framework that are incompatible with Unity.
The only project I could change the .NET framework version to match Unity's 3.5 is the one based on the Other > .NET > Library.
Everything works fine but I'd like to know if the assumptions, the process and the final result are correct. Can you tell me, please?
I don't know the difference between the "Class" and the "Class Library" option but you're supposed to use the "Class Library" option. This is not the main point of this answer.
Two future issues you haven't solved yet:
1. Referencing Unity's API.
If you ever have to use any Unity library or API in youir plugin such as Vector3, you need to add Unity's UnityEngine.dll to your library settings. If you don't, you will run-time exceptions.
Go to Project --> Add Reference ---> Browse ---> Browse Button
then select <UnityInstallationDirecory>\Editor\Data\Managed\UnityEngine.dll. You can now build your managed plugin. Since you're using Mac, this path is different on your OS. On Mac, this could be /Applications/Unity/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll. You just have to find where UnityEngine.dll is located.
2. Invisible stack trace
With your current setup, if you run into error with your managed plugin, the stack trace won't be there. You won't have the file names and line numbers and this makes is very hard to debug your plugin code.
When you build the project, Visual Studio generates a PDB file instead of an MDB file. Unity can't use this directly. You have to convert the PDB files into MDB files.
From command line, run this:
<UnityInstallationDirecory>\Data\MonoBleedingEdge\lib\mono\4.5\pdb2mdb.exe UnmanagedPlugin.dll
Again, the path might be different on Mac, you just need to find "pdb2mdb.exe" that converts the PDB files into MDB files.
After that, copy the MDB and dll file into the "Assets" folder in your Unity project.
I'm currently part of a team that is working on a rather large Typescript project in Visual Studio. As time has gone by and different versions of the project has been released, we've run into a snag when it comes to the versioning of Typescript installed together with Visual Studio.
Scenario:
v 1.1.0 of product released, built on TypeScript 1.8
v 1.2.0 of product released, built on TypeScript 2.1
A bug from customer X is reported for the 1.1.0 version, and the team will start working on a fix.
Problem:
Visual Studio is currently configured to use the latest version of TypeScript (2.1 in this case), so the code from v 1.1.0 does not compile.
Yes, I can manually change typescript versions in the project file and move around on tsc.exe to make this work. Typescript is installed globally as well, but for some reason, they decided that Visual Studio will install the compiler in its own folder instead of acessing the globally installed one.
Hoping someone else has run into this problem, and have a better approach to this.
This was solved by adding the following parameter to my .csproj file:
<TypeScriptCompileBlocked>True</TypeScriptCompiledBlocked>
Ended up running a grunt watch task, using the globally installed TypeScript compiler to compile the project.
Fetched from the official TypeScript docs
If you are using a different build tool to build your project (e.g. gulp, grunt , etc.) and VS for the development and debugging experience, set true in your project. This should give you all the editing support, but not the build when you hit F5.
Is it possible to integrate dependencies from Gradle inside Xamarin project?
A have some libraries, which I need to install, they look like this
dependencies {
compile (name: '<aar fileName>', ext:'aar')
compile 'com.koushikdutta.async:androidasync:2.1.6'
compile 'com.android.support:appcompat-v7:23.1.0'
compile 'com.android.support:design:23.1.0' compile
}
Can I expose them to Xamarin somehow?
There is no gradle in Xamarin.Android.
To get external libraries or Android libraries you could use:
NuGet
Xamarin Components
Do your own Java Library binding
Convert code directly from Java to C#.
There is a plugin for Visual Studio (tested it a few months ago but didn't worked for me) that in theory grabs dependencies from gradle and tries to convert them to C# Bindings.
Here you have a very good github page with awesome Xamarin Plugins.
Build your Android applications in Visual Studio using Gradle.
With the latest Visual Studio release, if you take a look at the cross-platform C++ section in the File->New project template section, you will see a variety of templates as shown in the figure below. Notice two new Gradle templates that have been introduced.
Source: https://blogs.msdn.microsoft.com/vcblog/2016/06/12/build-your-android-applications-in-visual-studio-using-gradle/
You can try the Java library binding, it's basically creating a C# binding Java library to consume your library from your Xamarin project.
Typically you won't use gradle to build your Xamarin projects. Thus you need to integrate/ reference those libraries through NuGet packages. AppCompat and Support Design are both available as NuGet packages. The otherone, if it does what I think it does, won't be needed because c# as build in async-support.
I am trying to add a barcode scanner plugin to my phonegap/cordova project for windows phone. I searched a lot but couldnt find any docs on adding external plugins to visual studio. I am using 'Visual studio 2010 Express for Windows Phone'. I got the phonegap plugin from here. Even thought the plugin is depreciated, I had success in using it in eclipse for building the android version.
Maybe check this out or this
Application developers use the CLI's plugin add command (discussed in The Command-Line Interface) to apply a plugin to a project. The argument to that command is the URL for a git repository containing the plugin code.
PhoneGap-WP7 maintains the plugability of other platforms via a command pattern, to allow developers to add functionality with minimal fuss, simply define your C# class in the WP7GapClassLib.PhoneGap.Commands namespace and derive your class from BaseCommand.
For .cs file you just need to add it to your VS project
For .js file you need to add it to correct folder (to be a part of VS project), for example to 'www' and THEN add reference to this .js file in your html page (this step seems to be missed in your case).
Optional. For some libraries you will also need to add additional dlls, but you can't miss this step since there will be compilation issues.
Hope this help u