I wanted to obfuscate my application, but I couldn't find a free obfuscator for commercial use. I saw that mono supports AOT compilation, so is there a was to compile my app ahead of time using the community version of Xamarin?
If not: is there a free obfuscator for C#(xamarin) for commercial use?
NOTE:
I'm targeting Android
I want to clarify the licensing restrictions that come with Dotfuscator Community Edition (CE). UUioP writes "I know about Dotfuscator, but I was actually looking for a free obfuscator for commercial use." Dotfuscator CE most certainly comes with license restrictions that preclude most commercial use scenarios, but there is one exception (granted - it is a very narrow exception, but one that might work for some). Dotfuscator CE can be used to release commercial software if the code being obfuscated is written and owned by the Dotfuscator CE user. In other words, if you develop your own app (and it's your app - not your employer's), you can use Dotfuscator CE to obfuscate your app - even if it is for sale or other "commercial/production" use. See (Re) Introducing Dotfuscator CE - the licensing terms are explained towards the end of the post.
The AOT Compilation option requires an Enterprise license or higher. AOT compilation is available only when the project is configured for Release mode, and it is disabled by default.
Source: https://developer.xamarin.com/guides/android/deployment,_testing,_and_metrics/publishing_an_application/part_1_-_preparing_an_application_for_release/#AOT_Compilation
As for obfuscation, Xamarin.Android does not support obfuscation out of the box. You will need to use a third party obfuscation tool like Dotfuscator. They have a tutorial on this here.
Many people think Proguard will obfuscate their code in a Xamarin.Android project, but it only works on the Java end.
The Xamarin.Android ProGuard configuration does not obfuscate the APK, and it is not possible to enable obfuscation through ProGuard, even with custom configuration files. If you wish to use obfuscation, please see Application Protection with Dotfuscator.
Source:
https://developer.xamarin.com/guides/android/deployment,_testing,_and_metrics/publishing_an_application/part_1_-_preparing_an_application_for_release/#ProGuard
AOT in Xamarin:
It depends whether you are targeting Android or iOS.
As #Jon Douglas states in his answer, Android AOT in Xamarin is unfortunately currently limited to Enterprise licenses. (tip: You can test out this Enterprise feature using a limited-time Enterprise license trial.)
iOS AOT in Xamarin, on the other hand, is part of every iOS build, so you get it with the Community license for free. Note however, that the full .Net assemblies are still included in iOS release builds, so that defeats the purpose of AOT "obfuscation" in iOS. :/
Obfuscation:
ConfuserEx is a great .Net open-source obfuscator with an MIT License:
https://github.com/yck1509/ConfuserEx/
I still haven't tested ConfuserEx end-to-end in a Xamarin app, but it looks promising so far... (Beware, as many people point out, ConfuserEx is a little "confusing" to use...)
Related
I used Visual Installer project to deploy.
After I added .NET 4.6 components to my project and built it, I didn't got click to install option, to check this in Visual studio.
But after deleting this everything worked again.
Download Prerequisites: I would set the prerequisite to download from the vendor's web site - that is the first option of those 3 in your screen shot - at least in my English Visual Studio Setup Project. I don't read Russian / Cyrillic I am afraid. Those letters really look like an alien language :-).
Eliminate Embedded Prerequisites (for common runtimes): My rant about including the .NET framework is generally that what you include is 1) outdated in no time with all the security fixes (hence bloating your setup for no reason?) and 2) the new Windows OS versions are including .NET pre-installed outright (albeit perhaps not in the correct version). 3) .NET is also installed via Windows Update now - for home users (eventually, there is some delay in release), and 4) corporate packagers absolutely hate pulling packages apart to remove common runtimes since they have to use standard corporate packages for these runtimes and are not allowed to use the bundled ones. Just a report from those who receive vendor setups. Keep it simple. Prefer to document what your setup does? Providing simple Readme.txt or Deployment Info.pdf is good. Delivering a special setup for corporations and large scale deployment is another good way to do it (just a zip of prerequisites and the actual setup).
Launch Condition: A simple launch condition telling the user to install the .NET framework and what version might be enough, but maybe your "download from vendor site" is best?
.NET Runtime: As a side-note - and I guess this is well known for most - just pointing it out to whoever might read this: There have been way fewer versions of the .NET runtime (CLR) than is commonly perceived. There is the framework, and then there is the runtime. Please see .NET expert and overall computer expert Hans Passant's summary here (and the other answers on the page too). One more. Version 1.0 and 1.1 of the CLR would seem to be largely irrelevant by now?
Alternative Tools: I have long disliked Visual Studio Installer Projects. Just throwing in a link to alternative MSI tools.
I've been rather interested in C# and Mono since Microsoft announced that it was open sourcing .Net. I was wondering how much influence this decision has had over the Mono project? I'm assuming it now means there isn't any potential danger of Microsoft trying to shut down the project anymore (if they had wanted)?
Yes Roslyn has been integrated.
From the article Mono and Roslyn, which was written by one of the Mono maintainers:
At BUILD, we showed Roslyn running on Mono. If you want to run your own copy of Roslyn today, you need to use both a fresh version of Mono, and apply a handful of patches to Roslyn.
...
Our goal is to keep track of Roslyn as it is being developed, and when it is officially released, to bundle Roslyn's compilers with Mono.
Where is the difference between Xamarin.Mac and Mono:OSX. I know Xamarin bought Mono so I thought it should be the same. But Mono:OSX seems to be free, while Xamarin.Mac costs at least 399$. So where is the difference between them both?
Xamarin.Mac -> http://xamarin.com/mac
Mono:OSX -> http://www.mono-project.com/Mono:OSX
The following is an excerpt from an article at xamarin.com (http://docs.xamarin.com/mac/guides Jan 1, 2013) which answers your question.
What are the differences between MonoMac and Xamarin.Mac?
Xamarin.Mac is built on the open source MonoMac project. Xamarin.Mac is being developed by the maintainers of MonoMac, though contributions are continuing to flow to MonoMac as well.
Xamarin.Mac has these additional features:
A commercial license to the Mono Runtime
Bindings to new frameworks
Creates self-contained application bundles, without external dependencies on Mono.
These are described in detail in the following sections.
Bindings to New Frameworks
The following are new frameworks and APIs that are included in Xamarin.Mac:
CoreBluetooth
GameKit
New MountainLion AppKit APIs
SceneKit
StoreKit
Commercial License to the Mono Runtime
Xamarin.Mac also comes with commercial support from the Xamarin team, and the Xamarin.Mac product has a published roadmap of forthcoming features.
The Mono runtime license is a commercial license that allows developers to redistribute their Mono-based applications without being bound by the terms of the GNU LGPL v2. This allows you to publish both to the Apple App Store as well as distributing applications that embed the Mono runtime without having to provide source code or object files for end users to relink.
Creating Self-contained Application Bundles
Xamarin.Mac extends MonoMac by allowing developers to ship an application bundle that includes both their software as well as the required pieces of the Mono runtime, without requiring your users to fetch the Mono runtime on their own and install it separately on their systems.
This feature is used for AppStore deployments as well.
I am not from Xamarin, so below is only my own understanding,
Xamarin.Mac is based on Mono:OSX. It is not something that comes from middle of nowhere.
Xamarin.Mac provides streamlined experience of developing Mac applications, by integrating MonoDevelop, Mono core runtime, MonoMac, and probably some non-open-source addins/utilities. It is easier to use Xamarin.Mac than assembling the whole tool chain on your own.
Xamarin.Mac comes with support contracts. This can attract professional Mac developers, and enterprises, as they need support contracts to ensure their own products' supportability.
Anyway we can sign up the seminar and learn what it is,
http://resources.xamarin.com/intro-to-xamarin.mac.html
BTW, the statement "Xamarin bought Mono" is not that accurate. The proper terms can be found in this blog post by Miguel de Icaza,
http://tirania.org/blog/archive/2011/Jul-18.html
Xam.Mac fills many of the gaps missing from Mono on OSX.
There's bindings to the native OSX APIs for Notifications, for example.
The BIG win for us was a FileSysteWatcher that uses OSX FSEvents. It's awesome.
It also features an OSX compatible version of NetworkAvailability. Mono only has support for Linux/Windows
There's a program written entirely in C# that targets .NET Framework 2.0.
Is there a way I could somehow compile (translate) managed EXE to a native one so it could be .NET-agnostic? I know there are probably commercial products for that purpose... but they are a bit expensive.
The problem is that we are to deploy the program on computers running Windows XP with no .NET Framework installed. There's also a requirement that the program's size must not exceed 500Kb (1Mb maximum) for it is downloaded from the web server (now the size is 255Kb). That is why there's no way we could attach a full-fledged .NET FX (or even a reduced one) to the downloaded program's file.
Obviously it is a terrible software engineering error that should have been detected and avoided earlier so we could use native technologies like C++ instead.
We have tried for now Novell's Mono - an open-source implementation of .NET Framework for Linux, MAC and Windows. Mono consists of C# Compiler, IDE, runtime (CLR) and Class Library assemblies (like System.dll and mscorlib.dll - much like .NET's class library assemblies installed to GAC).
What we tried to do is to locate CLR files and ship those along with our program's file and a few assemblies. This way the program can be invoked by running "mono program.exe" (command prompt) on a user's computer.
In addition to the inconvenience of such a use for the end user CLR files (mono.exe and mono.dll) turned out to be about 2.5 Mb in total that is much greater than the desired 500 Kb or even 1 Mb.
So, we have left with no other option but to translate our .NET App to a native one by a compiler, however the question remains - what compiler should we use and where could we find one...
For now I have stumbled upon a Singularity OS Project by Microsoft Research. It is an open-source research OS that is written in managed code (in part at least). The Singularity OS includes a Bartok compiler that the OS uses in order to translate a managed program to a native one (x86 32 bit). It should be noted that Bartok can't translate all the aspects of .NET 2.0 to a native code, but most of them. However I haven't yet learnt how to use the Singularity...
I would be really grateful to you if you could provide me with some useful tips and advice regarding the problem, your own experience with Singularity OS and Bartok Compiler or another approaches to the problem that I have overlooked and ways of solving it.
Thank you very much in advance!
Finally, using Mono's Full AOT feature (on Callum Rogers' advice) I've managed to produce a program.exe.dll that lacks a CLI header.
So it looks to me like a native dll. However I can't figure out how to convert that dll into exe or make it operational.
Also this dll doesn't seem to expose any functions of interest such as main function.
Check out AOT (Ahead Of Time) Compilation from the Mono project. This compiles your managed project into a native exe or an elf executable (depending on which system you target) that does not need the JIT. This is the technique used to get mono apps onto the iPhone (where the JIT/Framework are not allowed) and also has the added benefits of faster startup times, lower memory usage and it makes it harder for people to decompile your code. You said you were already using Mono, so it should be compatible.
Read up about it at the mono-project.com website and at Miguel de Icaza's blog (and iPhone info).
Note that you cannot use dynamic code or generic interfaces like
interface IFoo<T> {
...
void SomeMethod ();
}
And you will have to compile the DLLs of all the libraries you use.
PS: Make sure to use "Full" AOT for your problem.
2018 Update
At Build 2018, Microsoft announced .Net Core 3.0 roadmap that support Windows desktop applications (Winform & WPF)
2017 Update
For console apps, you can use .net core Self-contained deployments (SCD). Even for a hello world app, your package will 50MB+. You still need to install VC runtime though.
Update
As #jenix's comment, .NET Native is only for Windows Store Apps(UWP). After 3 years of it's announcement, this is still true, .net native for desktop may be dropped by microsoft . So this answer is not applicable anymore.
========
Microsoft Announced .NET Native Preview on Build 2014
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
Announcing .NET Native Preview
Microsoft .NET Native
There is a project called CrossNet that parses .Net Assemblies and generates unmanaged C++ code, that can be compiled in any standard compiler.
Not really a solution for .NET to native conversion, but maybe this helps: http://www.yoda.arachsys.com/csharp/faq/#framework.required
Not quite sure that there is much you can do besides painstakingly rewrite the application. To ease the already burdening process, you could disassemble the .NET application using something like Reflector (into Microsoft C++), and use that as a base to start and just replace managed C++ references with native ones.
Recently, I came across Mono and MonoDevelop packages in Ubuntu linux. They claim to have a .NET runtime in accordance with CLI. Before installing the packages myself, I would like to know the following:
How powerful is Mono?
Can I develop GUI application for
linux like developing WinForm
applications for Windows.
Is MonoDevelop IDE compatible with Visual Studio IDE. Can I import VS 2008 solutions to MonoDevelop and work?
Does it support .NET 2.0 and above?
EDIT: Adding one more doubt
Is there any way to run the .NET exe (of a winform app) in Linux without building the cod e in linux? In fact I don't have the code for some of the small utilities I developed earlier and would like to run them in linux.
(Strange, markdown starts the enumeration with one, even though I began with 2...)
Yes, you can, but you're limited with 3rd-party components, because the internal implementation is different, and last time I checked (not very long ago), the Mono WinForms implementation made my test app look rather strange (owner-drawn list view). It is not really recommended, though Mono claims that it's now completely WinForms-2.0-compatible.
MonoDevelop is/was a SharpDevelop branch, with the latter having solution support. I don't know if MonoDevelop has. But the cool thing is, you can just develop with Visual Studio and run your compiled apps on Mono. And Mono is, by the way, also available for Windows.
Yes, it does, as far as the CLR goes. As Marc Gravell already wrote, the Windows Foundation libraries are missing, as are a few other (System.Management, for example). But things should mostly work, including ASP.NET 2.0. Mono's application portability guidelines are a good read on this.
1: pretty good, actually. Not all the full framework is there, so if you are writing code that should build on both MS .NET and mono, you need to build and test early against both platforms
4: yes - although things like WPF/WCF/WF (3.0) are missing or slimmed down
I don't know much about the development environment, since I use VSTS (on Windows) and just use a NANT script to do the build on mono...
Define "powerful".
Mono has a WinForms implementation to allow for some level of source compatibility. However, depending on your needs, you might want to use one of the Mono bindings for a Linux native framework, like Gtk# or Qyoto
Wouldn't know.
Depends on what parts of .NET you mean. C# the language seems to be pretty current, things get fuzzier the closer you get to the enterprisey features as was already mentioned.
To sum things up, if you'll be using Mono as a separate target platform, you're likely to have good results. If you want a no-code-changes-required .NET compatibility layer, less so.
Very powerful. There are no major bugs in the core implementation. It is not a science project. The deficiencies are mostly where you would expect, the newest APIs (Microsoft inherently has a first-mover advantage there).
Yes. We just finished a project where most of the GUI code was developed in WinForms on Windows. I was able to work on it using Ubuntu without major headaches. That said, this is one of the hardest parts of the API, and there are still issues. See http://mono-project.com/WinForms for details.
Don't know, as I don't use it.
Yes, though again, there may be some missing APIs in the runtime.
Note, I use Ubuntu Hardy (8.04).
Mono is mighty powerful. It has all the .Net muscle on a very strong open source skeleton.
When you say "develop GUI application for linux like developing WinForm applications for Windows" I understand that you are asking about a visual designer that will allow you to quickly create the UI. Yes, it is possible. MonoDevelop has Stetic - a built-in visual designer for Gtk#. There is also QyotoDevelop which enables QT support in MonoDevelop.
Yes, MonoDevelop natively supports VS project/solution file format. You can use the same code base to compile your app with VS in .Net on Windows and win MD in Mono on Linux.
Currently Mono supports C# 3.0 with some stuff beyond that already implemented and a lot in the pipeline.
Yes, in many cases it is possible to run a .Net compiled app in Mono, however with MonoDevelop's support for VS solutions it doesn't really matter. It takes as much as pressing F7 to rebuild the whole project, so the effort is really negligible. The best tool for checking if your application can run in Mono is MoMA.
Mono is very powerfull, sometimes even more powerfull than Microsoft's implementation. link text
Yes you can. Winforms 2.0 is supported
I believe so.
Yes it does. C# 3 is supported and just look at winforms and the asp.net implementation to see how much is supported from each of the projects. Look at http://mono-project.com
I use WinForms in mono. The 2.x releases are very good.
I develop forms in visual-studio on windows, and run them in Linux, with zero code changes. Yes, forms look a little different than on XP, but then again, an XP-themed GUI would look kind of strange in GNOME.
If you are just getting started, stick with WinForms, while you get comfortable with Mono/Linux. However at some point you might want to investigate GTK.