I need to protect the business logic on app and this is created with xamarin forms. I have searching information on forums and here about Babel and ConfuserEx but I don’t get it works.
Case Babel
I have installed demo SDK and I have updated the path on environment variables.
On Android Project I have added the following lines as I have seen on samples and book “Xamarin Mobile Development for Android Cookbook”
<UsingTask TaskName="Babel" AssemblyName="Babel.Build, Version=9.3.3.0, Culture=neutral, PublicKeyToken=138d17b5bd621ab7" />
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
<Babel InputFile="$(TargetPath)" OutputFile="$(TargetPath)"
VerboseLevel="5"
ObfuscateTypes="true"
ObfuscateEvents="true"
ObfuscateMethods="true"
ObfuscateProperties="true"
ObfuscateFields="true"
VirtualFunctions="true"
FlattenNamespaces="false"
UnicodeNormalization="false"
SuppressIldasm="true"
StringEncryption="xor"
ResourceEncryption="false"
ValueEncryption="false"
DynamicProxy="false"
ControlFlowObfuscation="goto=on"
ILIterations="5" />
</Target>
The compilation is good, but I see dll with ILSpy tool and I can see flow, methods, variables, etc…
Case ConfuserEx
I have installed the VS Extension of ConfuserEx and I have tried to actívate it on common Project and it is obfuscated but When I archive in order to generate the apk, it isn’t obfuscated.
I have tried to do on Android Project instead common Project, but it don’t work.
Could you give me some advice in order to obfuscate app? I want to do it with Android, iOS and UWP app.
Because by default, uwp, droid and ios is easy to do reversing engineering, no?
Because by default, uwp, droid and ios is easy to do reversing
engineering, no?
Assuming that this is the question, the answer is that you are mostly wrong.
AOT compiled assemblies are not easy to reverse engineer, and AOT is mandatory for UWP and iOS, while on Android partial AOT is enabled now by the default and full AOT can be enabled too on the VS Enterprise.
Speaking of that there is nothing that can't be reverse engineered and you can still add the obfuscation on the top of AOT compilation to make it even more tough, just there is no built-in solution (and as far as I know no free solution either) so it is yours to pick the one that you like, such recommendations are not allowed here.
I've been using Babel with my Xamarin.Android apps for the last 3 years. It works extremely well. If you are having problems contact Alberto at Babel. He provides really great support. Most problems are because of the fact that the Xamarin's build process can vary from release to release and therefore you Babel task can require modifications to accommodate those changes
Related
I am using Visual Studio For Mac. My Xamarin Forms project is quite large and contains many content pages. Some of them will be only used in android project and some of them only used in iOS project. There is no problem when I compile the project into android. However, when I want to compile the project into iOS, it seems like did not accept anything related to android. Please refer to the screenshot. There is no way I can include the android specialised reference and compile into iOS project. So, any idea to deal with this? Maybe there is a way to force build the iOS project no matter what? The error from the screenshot is from the page that will be only used in android. So what I can do for now is delete the page when I want to compile as iOS and recreate the page when I want to used it for android. But there are plenty of them, it is too heavy for me to do this every time. Please help.
You can't call platform specific APIs at the .NET standard libraries that are used to host Xamarin.Forms code by default.
Basically you have those options:
1) using shared project instead of library and using conditional compiling (easier but it is now not available as the option when creating the project)
2) using dependency injection.
I'm nearly done with my app. I'm using Xamarin.Forms (PCL project for the shared code). Is there any benefit of switching PCL into .Net Strandard? I have read some articles, but still not 100% sure whether are there any benefits of upgrading, e.g. security, performance or is't more like richer API mainly? Thanks for any thoughts.
There is no direct improvement in security or performance, but in time .NET Standard will replace PCLs. The PCL is not as cross-platform as Standard, so to make it truly cross-platform the switch to Standard is the smart thing to do.
Also, a lot of NuGet packages are already switching to support Standard, and you will not receive any upgrades for that code in your PCL library. So coming back to the security and performance part; if a bug is found in a NuGet package, you will not receive the update containing a fix because you're still on the 'older' PCL technology. This is a bit of a stretch, but if you want to be future-proof, the switch to .NET Standard is mandatory.
Right now we're in a bit of a pickle. You cannot reference a Standard from a PCL and vice versa (not 100% sure on all scenario's but I think you can't). So, right now you have to carefully check if all NuGets you are using, have a .NET Standard version already. If not, you're stuck on a PCL if you can't do it without the NuGet. The creator of the NuGet could supply a PCL and .NET Standard version in one NuGet, so then you can transition from one to the other. But see if that is true for all plugins you are using.
There is actually a good post on this by Adam Pedley here.
Actually, you can refer a PCL from .netstandard and vice versa, but it depends on netstandard version and PCL profile. Refer to this table to find out what is possible in your case.
To move from PCL to netstandard:
1. Replace *.csproj content with this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.1</TargetFramework>
<PackageTargetFallback>$(PackageTargetFallback);portable45-net45+win81+wpa8</PackageTargetFallback>
<Copyright>Copyright © 2018</Copyright>
</PropertyGroup>
<ItemGroup>
<Folder Include="Properties\" />
</ItemGroup>
</Project>
2. You can add PackageTargetFallback tag if you want add references to PCL libraries. Also you can edit the value you need. In the example above I use "portable45-net45+win81+wpa8" to add PCL(Profile111) in the netstandard1.1 library.
3. Use the netstandard version you need. Copy info from "AssemblyInfo.cs" to the project settings (Properties->Package) and remove it as you don't need it anymore.
4. Manually install back nuget packages from "packages.config" file and scan old *.csproj file for references to you projects. Add them as well. Then you can remove "packages.config" file as well.
I tried it on VS2017 15.7.5. I found that it's better to use netstandard1.1 and profile111 if you develop for Xamarin.Forms (Android + iOS). In this case, you can still use old .NETPortable nuget packages (even though they don't support netstandard yet).
We have a problem when we build our app in Release mode with .Net Native Toolchain on.
MobileServiceClient.SyncContext.PendingOperations then returns -1 instead of 0 when there are no Pending Operations which result in that offline functionality no longer works (no items that are inserted when you are offline are sent over to the server).
The same phenomenon is described here:
https://github.com/Azure/azure-mobile-services/issues/890
We have tested with Visual Studio Update 2 and also with Visual Studio Update 3, but unfortunately, the problem remains in that version.
However, we have noticed that if we set "Optimize code" = false the offline functionality works, but then we instead get the following errors when Windows App Certification Kit tests have been completed.
"AppName" takes a dependency on Microsoft .Net Native Framework Package 1.x framework but is missing the framework dependency declaration in the manifest.
and
API CoCreateInstance in api-ms-win-core-com-l1-1-0.dll is not supported for this application type. "AppName.dll" calls this API.
If anyone has a solution for this, we would be very grateful!
With the help of a member from the .NET Native runtime and compiler team (Many thanks) we have been able to troubleshoot the problem and come up with a workaround!
We have worked around this issue by adding this to Properties\Default.rd.xml file:
<Library Name="Newtonsoft.Json"> <Assembly Name="Newtonsoft.Json" DoNotOptimize="true"DoNotInline="true" /></Library>
This instructs the optimizer to ignore all of the types/methods inside of Newtonsoft.Json.
I have noticed that you reposted on the Azure Forums as well. I asked a few follow-up questions there and will answer your query there. We can cross-post the eventual answer if you like.
I want to rewrite my old .net app based on FirebAse with the new C++ SDK, I have managed to link and compile the libraries in my VS2015 environment, but now have no idea about how to use them.
The firebase quick start here:
https://github.com/firebase/quickstart-cpp/tree/master/auth/testapp/src/desktop
doesn't really show anything.
Am I looking in the wrong place?
Cheers.
Firebase C++ only provides stub libraries as a convenience for desktop at the moment so while you'll be able to link the libraries they won't actually do anything. We have a desktop implementation of our light platform abstraction layer for internal testing only - notice we don't ship desktop MSVC or Xcode projects.
See the readme.md in the Firebase SDK zip file for more information.
Our company's svn cannot allow single file larger than 40mb, realm framework needs 140mb+，so how can I build realm-cocoa with source code on github?
You could instead use the dynamic framework, which is a lot smaller (28,5 MB), through being already linked, but you won't be able to support iOS 7 in that way.
Alternatively I would recommend using a dependency manager like CocoaPods, which helps you with the setup and integration. But as a Core Member of this project, I'm obviously biased in that regard.
If that shouldn't be available for you, then you could theoretically use SVN externals to checkout the realm-cocoa repo (GitHub supports SVN transports), add the Realm.xcodeproj to your Xcode project, set the iOS framework target as dependency target of your app target and link to Realm.framework. But please not that this is not an officially supported way of integration.