I have a xamarin application which is very slow, I need to improve this performance, with a little research I came across this concept of Ahead of time compilation. But I am not sure how to enable it for my project.
<AotAssemblies>True</AotAssemblies>
Apparently, I need to set this property to true in my .csproj file But I can't seem to find the file. Any help would be appreciated
Plus this is my first question on StackOverflow so I hope to find some help.
This property need to be setted in native .csproj, but there is a easy way to set that with GUI of Visual stuido.
For example, if want to set for Android in Visual Studio for PC, packaging properties can be set in the Android Options section of project Properties, as shown in the following screenshot:
and then you will see it in .csproj of Android solution.(Unload Android Solution will see this file):
In iOS, you will not need to set AOT, because iOS will use AOT as default.
However, there is a security restriction on iOS, set by Apple, which disallows the execution of dynamically generated code on a device. To ensure that we adhere to these safety protocols, Xamarin.iOS instead uses an Ahead of Time (AOT) compiler to compile the managed code.
Related
I'm considering the option "Bundle assemblies into native code" in the properties of my xamarin android project as below:
which has the description
bundles assemblies into a native shared library. This option protects
managed assemblies from examination or tampering by embedding them in
native binaries.
This seems like a great option to me. It makes my code harder to reverse engineer, and makes my apk file smaller as well. However, clearly there are reasons that this option isn't checked by default in Visual Studio.
The three cons I can guess at are:
compile time,
ability to run a profiler (which seems like a dead loss for xamarin
anyway)
potentially that this way of operating might affect error reporting
if you're using some kind of utility like AppCenter.
I'm curious to know what the actual cons might be, and if there is a compelling reason not to have this option as the status quo?
Perhaps as the official document says,there are two limitations.
This option requires an Enterprise license
This option is only available when Use Fast Deployment is disabled
But without Fast Deployment, Xamarin.Android has to build an APK every time there’s change in your project, regardless of size or scope. This feature allows “side-loading” of .NET assemblies to enable a much better experience.
I read this tutorial to try to set up Vulkan in Visual Studio. I got to the very end, compiled, and got this:
A few more screenshots:
I'm using version 1.1.114.0 while the tutorial is using 1.1.77.0, which may be at the root of the issue. However, I have not been able to find another tutorial showing how to set Vulkan up like this. How do I get Vulkan to work in Visual Studio?
I believe you must have missed a step in the tutorial. Specifically, look for the text
Next, open the editor for library directories under Linker -> General
in the linked tutorial page.
In the linker Input tab, either use a complete path to the Vulkan library (for example C:\VulkanSDK\1.1.101.0\Lib\vulkan-1.lib) or in the General tab, add the location of the library (for example C:\VulkanSDK\1.1.101.0\Lib to the Additional Library Directories entry).
If you can express the values in terms of an environment variable, then you'd want to use either VULKAN_SDK or VK_SDK_PATH, which in the above examples would resolve to C:\VulkanSDK\1.1.101.0. That way when you update your Vulkan SDK you don't need to update your project files, and they'll work on other machines that might have different versions installed.
In the long run I'd recommend switching to CMake for project generation, rather than maintaining Visual Studio project files directly. With CMake, adding a Vulkan dependency to your application is as easy as doing this:
find_package(Vulkan REQUIRED)
target_link_libraries(MyApp Vulkan::Vulkan)
You can find existing CMake-based Vulkan examples here or here.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Debug vs. release in .NET
Debug/Release difference
What is the difference between Release and Debug modes in Visual Studio while building a project?
Debug and Release are just labels for different solution configurations. You can add others if you want. A project I once worked on had one called "Debug Internal" which was used to turn on the in-house editing features of the application. You can see this if you go to Configuration Manager... (it's on the Build menu). You can find more information on MSDN Library under Configuration Manager Dialog Box.
Each solution configuration then consists of a bunch of project configurations. Again, these are just labels, this time for a collection of settings for your project. For example, our C++ library projects have project configurations called "Debug", "Debug_Unicode", "Debug_MT", etc.
The available settings depend on what type of project you're building. For a .NET project, it's a fairly small set: #defines and a few other things. For a C++ project, you get a much bigger variety of things to tweak.
In general, though, you'll use "Debug" when you want your project to be built with the optimiser turned off, and when you want full debugging/symbol information included in your build (in the .PDB file, usually). You'll use "Release" when you want the optimiser turned on, and when you don't want full debugging information included.
Well, it depends on what language you are using, but in general they are 2 separate configurations, each with its own settings. By default, Debug includes debug information in the compiled files (allowing easy debugging) while Release usually has optimizations enabled.
As far as conditional compilation goes, they each define different symbols that can be checked in your program, but they are language-specific macros.
The main difference is when compiled in debug mode, pdb files are also created which allow debugging (so you can step through the code when its running). This however means that the code isn't optimized as much.
I would like to add several extensions into my iOS application but it seems that once I do, I quickly exceed the 100Mb limit that Apple places on Over-The-Air downloads.
com.apple.usernotifications.content-extension
com.apple.usernotifications.service
com.apple.ui-services
Document picker extensions
Each bare bones extension results in a 6Mb addition to my application.
Since the Xamarin runtime is presumably embedded into each instance, is there any way I can share this runtime among the various extensions?
Is this available as a mtouch compiler flag?
What other options do I have?
Right now I'm asked to add 11 Extensions, and I'm already at 70MB and I haven't even started coding or adding assets yet.
The most important rule about reducing app size for Xamarin.iOS is still valid:
Enable the managed linker for all assemblies (and all extensions).
Additionally Xamarin.iOS will automatically create a single embedded framework for the Mono runtime which will be used by the app and all extensions (you can check this by verifying that yourapp.app/Frameworks/Mono.framework exists).
Also make sure you don't set the deployment target to anything lower than 8.0 (for the main app) unless you really need it (because if you set the deployment target to anything below 8.0 we have to embed the Mono runtime into the main executable, because iOS 7 does not support embedded frameworks).
Unfortunately we're currently not able to share any of the AOT-compiled code from the base class libraries (nor your own code), so for instance mscorlib.dll (and all the AOT-compiled native code) is included both the app and every extension, but this will change in a future release (I'm implementing it right now).
Some of the frameworks are missing when I generate Xcode project through Unity. What would be the reason? How can I solve this?
I mean manually I have added them in Build Phases to fix the error, but why are they missing?
They're missing because they are required when you use those APIs.
If you're coming from a language like Java this might seem strange, but with Objective-C (which is ultimately C) you need to let the compiler know where the APIs come from beyond just the header file import.
Unfortunately, Unity doesn't provide any support for specifying additional frameworks for your Xcode project to link to. However, if you can you should generate and modify your Xcode project once and then subsequently always have Unity update rather than override the project.