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.
Related
I am consuming Web Api services in my app. Though it is app with small functionality such as registration and login then also the size of the release was firstly 55 MB then i searched a bit then i got it down to 22 MB.
My settings are
Linking- SDk assemblies only.
i have tried every other thing such as Deselect Shared Runtime.
Select Pro guard, Generate one package, all type of linking but did not get desired result.
Am i missing something or the app size will be 22 MB.
please suggest a solution
(Copied from : https://montemagno.com/how-to-keep-your-android-app-size-down)
Linking Your Libraries
Xamarin applications use a “linker” in order to reduce your app size.
You can browse through the documentation and find out how this works,
but to simplify things, it uses static analysis to your app to remove
assemblies and types that are not used in your app to bring down your
app size. This is for any Xamarin app, so you should also try this out
in your iOS app because it can reduce your app size in a default
“Hello, World” application from 16MB down to 2.9MB! There are three
settings that you can supply from the projects settings:
Don’t Link will do just that, it won’t link anything and you will be left with All of Mono, mscorlib, Xamarin.Android, and a bunch of
other stuff:
Link SDK assemblies only is your safest bet and should be your default as it will only attempt to strip things out of Xamarin.Android
and any of your third party libraries will not be touched. However, to
really bring down your app size you should try out Link All
Assemblies, as it will investigate everything and bring down your
app size. Be sure to FULLY test your app as it is possible that the
linker may be agressive and strip out something you need, and if that
is the case you can actually use a [Android.Runtime.Preserve] flag or
set a linkskip in your MSBuild to ensure that not all of your
libraries get linked.
So employing this practice with my Bike Now app, which uses Json.NET,
Android Support v4, v7, Google Play Services, and Xamarin.Insights, we
can compare and contrast the app size when we build our app to support
all three ABIs (we will talk about this next!).
Don’t Link: 40.7MB
Link SDK Assemblies Only: 18.7MB
Link All Assemblies: 13MB
As you can see linking correctly can make a huge impact, but we can do
even better!
2. Splitting your APKs
On Android, there are ABIs (Application Binary Interfaces) that you
can support when you ship your application. The most used will be the
armeabi-v7a, however there are still tons of devices that support and
run the old armeabi ABI and even x86 devices as well. So to ensure
your app is reaching the most users you most likely have come into the
project settings and selected every single ABI (I know I do!).
However, for every ABI that you select you are actually bundling a
separate libmonodroid and sgen with your app. Don’t believe me then
rename your .apk to .zip and take a look in the lib folder:
This of course makes sense as you would need a different version of
monodroid and sgen that supports that ABI. The issue is that you now
have all of these libraries bundle into a single APK and your users
will be downloading all of them! The solution for any Android
developer (even Java devs) is to simply split up your APKs and upload
all of them to Google Play! This way you have a smaller app size
across all three APKs. You can do this now with a simple check in your
project options:
Now, instead of just a single APK to upload I have three with
different and smaller sizes (note it will take longer to create your
packages):
armeabi-v7a: 10.2MB
armeabi: 10.3MB
x86: 10.4MB
Notes:
You may need to close XS after selecting check box and ensure this
flag is set in your csproj:
true
Additionally, your new APKs will be in your /bin/Release folder and
will be marked with Signed in their file name.
Keep your users happy and keep down that app size with these quick tips.
Refer to these links:
https://learn.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-process
https://montemagno.com/how-to-keep-your-android-app-size-down/
https://forums.xamarin.com/discussion/113229/what-is-the-ideal-apk-size-from-xamarin-forms-and-how-to-reduce-it-without-force-close
To reduce APK file size you need to use ProGuard with visual studio. It will remove all unused code, resources and shrink files, classes, variables names to very short name.
How to use ProGuard you see my another stackverflow question How to use ProgGuard with Xamarin forms.
Another option use linking Android project's properties, use Sdk and User assembly option. It some time remove code which we are actuary using so need to be careful.
I am working on a nodejs project in which all code is written in typescript. It follows a microservice pattern (and each microservice is an independent project) hence lot of projects needs to be opened and debugged at the same time.
I tried webstorm and visual studio (with NTVS) but not satisified with both of them. Webstorm ignores many build errors (very important as those will fail during CI) and not as good as visual studio in intellisense and ease of use. On the other hand, Visualstudio is not as fast as I want. Also I am tied to windows and the filename length problem in node_modules is very frequent and annoying.
Others (atom, VSCode) doesn't have typescript debug support (or am I missing something?).
Can you please share your experience? Also I was wondering which editor google developers might be using to develop angular 2 :)
I have been working on a TypeScript project for 1.5 years now and am quite happy with using Visual Studio because we used .NET for back-end stuffs. For myself I consider the speed as "Ok", it is not that good - but the other stuffs e.g. intellisense is what we really like. I also personally think that as a "son" of Microsoft, TypeScript will get the best support from its "cousin" - Visual Studio.
However if you are a Eclipse person, you may be interested in this TypEcs (http://typecsdev.com/). There was also a post by Steve Fenton talking about TypeScript IDEs you may be interested (https://www.stevefenton.co.uk/Content/Blog/Date/201409/Blog/Which-TypeScript-IDE/), he listed a few of the popular ones with a few sentences of comments, including Atom and the atom-typescript extension.
A bit late to the conversation.
I recently tried VisualStudio 2015, VisualStudio Code 0.9, Atom (with Atom-Typescript package). And quite comfortable with Atom.
Atom-TypeScript uses the latest version of TypeScript so you can use all new features like async/await, string interpolation etc. The package created by community so we don't need to wait for major IDE release to use new TypeScript features.
For debugging couldn't find one. But love to use node-inspector for its light weight. The problem is you need to debug it in javascript version not in typescript version. Not so sure but maybe if you can provide map file you can debug the typescript version? like we have on Google Chrome Inspector.
VSCode can debug in Node. No browser debugging yet.
Not a recommendation, but I suggest you do not buy JetBrains' products (IntelliJ/WebStorm/ReSharper) for TypeScript editing unless you have evaluated them properly.
They reused a lot of their own logic for other languages instead of taking full benefit of the TypeScript language service, which means they behave more like a fancy JavaScript editor that can make some clever guesses as opposed to a robust IDE for a statically typed langauge. (Their type inference is different from the compiler and may fool you into believing an untyped expression (implicit any) is well-typed. Also, all the refactoring are the same as the JS ones, so they do not use or preserve any type information. No type-information-based refactoring (like safe renaming and moving) are available either.)
As for debugging, you may have more milage debugging the generated JS. Not only is it well supported, it also reveals problems that occur in compiler-inserted code. The latter would be otherwise difficult to understand if you're only looking at the TypeScript source. Also, in the generated code, you can actually set break points in single line lambda function bodies.
I too use Visual Studio. I haven't had any problem with its speed; I find everything is as immediate as I expect it too.
However, I haven't been using "TypeScript" projects. I have been using generic "Web" projects with TypeScript files. Plus, I don't use Visual Studio's own building and compilation facilities; I use my own Gulp tasks for my project (including rebuilding, watching for saves, minification, testing, etc), and Task Runner Explorer to manage/run them from inside Visual Studio. I think it's the best of both worlds: the snappiness and features of Visual Studio, and the flexibility of running my own custom tasks independent of platform.
I have to admit I don't do any deep debugging (e.g. breakpoints, stepping) from the IDE. Does VS do that with TypeScript? If I catch an error during execution (in the browser), I always have my source maps indicating where the error is, so I go back to the code, attempt to fix it, save, and reload in the browser.
I am using VSCode to actively debug an angular/node/typescript application. It does work, but you will need to do some setup/configuration. You must tell VSCode how to debug your applications. For instance I have multiple options in my launch.json configuration to debug my gulp scripts, my node server.js file, and the angular/typescript application via chrome using the "Debugger for Chrome" extension installed in VSCode. It is all possible with some configuration. Finally, depending on your exact situation you may need to have and correctly configure the map files for your project from javascript to typescript.
I also had the problem of file paths too long in the node_modules folder in visual studio when opening a project with npm. This is due to Visual Studio trying to download all your packages - incorrectly so I might add. The only way to avoid this for my project was to mark the node_modules folder as a hidden folder in windows (top level only).
I'm building some code with these portable class libraries at present.
I'm looking to target full .Net, WinRT Metro, Windows Phone, ... and then MonoTouch and MonoDroid. My experiments today show this can work - http://slodge.blogspot.co.uk/2012/04/experiments-with-portable-class.html
However, I have hit a fairly significant problem - MonoTouch and MonoDroid currently support these libraries in that you can consume PCLs as binary assemblies, but they don't allow linking between project files
e.g. I can reference MyLib.dll from a MonoDroid project, but I can't reference MyLib.csproj.
This is a problem as it means automated (resharper) refactoring doesn't work - and I seem to rely on this for most of my work!
I've seen that Microsoft publish targetting packs that allow you to extend class libraries, but I've not worked out where these install to or what they modify.
Here's the current Microsoft list: http://msdn.microsoft.com/en-us/hh487282.aspx
Does anyone have any knowledge about what these packs contain or how someone might make their own pack? If they're not too overly complex, then I would like to have a go at producing one for MonoTouch and/or MonoDroid.
This has come up a few times recently, so I wrote a blog post that should do what you want:
http://jpobst.blogspot.com/2012/04/mono-for-android-portable-libraries-in.html
Please let me know if have any issues!
This post and this post says that with Visual Studio, the run time library can be static/dynamic, and it shouldn't be mixed. Even one can have debugging version/release version for the library. And there are four possibilities (static/dynamic and debug/release).
So, with Visual Studio, the library provider has to provide four different versions of the same library?
ADDED
I tried to link CppUnit test (debug) with release build library, and I got an error. So, I wondered normally library provider might need to provide all the possible combination of libraries.
depends..
under normal cicrcumstances you only provide a realease version. Then you have the option for static/dynamic. In the case of static, you don't have to provide anything since it's static: your lib already contains all functions from the crt it needs. In case of dynamic, it also depends: if you expect your clients to build applications using your lib, they already should have the required lib on their build machine. Else, yes, you can provide them with a crt installer for the dynamic release version (or just ship the corresponding dlls but that's considered rather bad practice)
Also if I remember correctly, you cannot redistribute the debug versions of VS's debug libraries, so in the end this would mean the library provider should only provide one version.
This is really the case with ANY C++ library (we have the same 4 options in our Unix side builds).
Please note that you only have to provide the debug versions if you intend them to be used by other developers, who will need them to debug - otherwise, for end users, you can only provide optimized ones.
I have a custom framework that, following the advice in Apple's Framework Programming Guide >> Installing your framework I install in /Library/Frameworks. I do this by adding a Run Script build phase with the following script:
cp -R build/Debug/MyFramework.framework /Library/Frameworks
In my projects I then link against /Library/Frameworks/MyFramework and import it in my classes like so:
#import <MyFramework/MyFramework.h>
This works very well, except that I always see the following message in my debugger console:
Loading program into debugger…
sharedlibrary apply-load-rules all
warning: Unable to read symbols for "/Users/elisevanlooij/Library/Frameworks/MyFramework.framework/Versions/A/MyFramework" (file not found).
warning: Unable to read symbols from "MyFramework" (not yet mapped into memory).
Program loaded.
Apparently, the compiler first looks in /Users/elisevanlooij/Library/Frameworks, can't find MyFramework, then looks in /Library/Frameworks, does find MyFramework and continues on its merry way. So far this has been more of an annoyance than a real problem, but when runnning unit tests, gdb stops on the (file not found) and refuses to continue. I have solved the problem by adding an extra line to the Run Script Phase
cp -R build/Debug/MyFramework.framework ~/Library/Frameworks
but it feels like sello-taping something that shouldn't be broken in the first place. How can I fix this?
In the past months, I've learned a lot more about frameworks, so I'm rewriting this answer. Please note that I'm talking about installing a framework as part of the development workflow.
The preferred location for installing a public framework (i.e. a framework that will be used by more than one of your apps or bundles) is /Library/Frameworks[link text] because "frameworks in this location are discovered automatically by the compiler at compile time and the dynamic linker at runtime."[Framework Programming Guide]. The most elegant way to do this is in the Deployment section of the Build settings.
As you work on your framework, there are times when you do want to update the framework when you do a build, and times when you don't. For that reason, I change the Deployment settings only in the Release Configuration. So:
Double-click on the framework target to bring up the Target info window and switch to the Build tab.
Select Release in the Configuration selectbox.
Scroll down to the Deployment section and enter the following values:
Deployment Location = YES (click the checkbox)
Installation Build Products Location = /
Installation Directory = /Library/Frameworks
The Installation Build Products Location serves as the root of the installation. Its default value is some /tmp directory: if you don't change it to the system root, you'll never see your installed framework since it's hiding in the /tmp.
Now you can work on your framework as you like in the Debug configuration without upsetting your other projects and when you are ready to publish all you need to do is switch to Release and do a Build.
Xcode 4 Warning
Since switching to Xcode 4, I've experienced a number of problems with my custom framework. Mostly, they are linking warnings in GDB that do not really interfere with the usefulness of the framework, except when running the built-in unit-test. I have submitted a technical support ticket to Apple a week ago, and they are still looking into it. When I get a working solution I will update this answer since the question has proven quite popular (1 kViews and counting).
There's not much reason to put a framework into Library/Frameworks, and it's a lot of work: You'd need to either do it for the user in an Installer package, which is a tremendous hassle to create and maintain, or have installation code in your app (which could only install to ~/L/F, unless you expend the time and effort necessary to make your app capable of installing to /L/F with root powers).
Much more common is what Apple calls a “private framework”. You'll bundle this into your application bundle.
Even frameworks intended for general use by any applications (e.g., Sparkle, Growl) are, in practice, built to be used as private frameworks, simply because the “right” way of installing a single copy of the framework to Library/Frameworks is such a hassle.
The conventional way to do this is to have your framework project and its clients share a common build directory. Xcode will search for framework headers and link against framework binaries in the build folder first, before any other location. So an app project that compiles and links against the header will pick up the most-recently-built one, rather than whatever's installed.
You can then remove the cp -r and instead use the Install Location build setting to place your build product in the final location, using xcodebuild install DSTROOT=/ at the command line. But you'll only need to do this when you're finished, not every time you rebuild the framework.
Naturally, when you distribute your framework it should be installed in /Library/Frameworks; however it seems odd to me that you're doing that with the test/debug versions of your framework.
My first instinct would be to install test versions under ~/Library, as it just makes setting up your test and debug environment that much simpler. If possible, I would expect the debug/test framework to be located in the build tree of the version I'm testing, in which case it's installed as a Private Framework for testing purposes. That would make your life much simpler when it comes time to deal with multiple versions of your framework.
Ultimately, it doesn't matter where the framework is located as long as your application or test suite loads the correct version. Choose the location that makes testing/debugging/development easiest.