Can I use my own DLLs with a Xamarin iOS or Android project?
The reason I'm asking is because I want to compile dlls from Clojure CLR, and use them with my Xamarin mobile projects.
Currently the answer for this is 'No' - you cannot use your own existing assemblies but must instead recompile those projects as Xamarin.iOS or Xamarin.Android (MonoTouch or MonoDroid) libraries.
This is because the Xamarin twins are based on old Silverlight profile code and not on full .Net.
This situation is changing currently - Xamarin is rebasing on Mono3/.Net4.5 and Xamarin is working towards PCL support.
However, even with these recent changes I think it is still advisable to rebuild your assemblies for the specific platforms at this time.
Related
I'm working on a xamarin forms (PCL) project (A basic customer care chat app which is meant to run on Android and iOS only) that has just two xaml pages, custom renderers and few dependencies. This project is meant to be implemented into another existing project (which I don't have access to its source code) such that an action would be binded to a button on the existing app to show a page on my own project.
There is need for me to share my chat project with my client's developer but without exposing my source codes, perhaps compiling to dll or nuget package that would be added to the existing project to access my project's functions and pages. I have searched through the xamarin forum and here on stackoverflow but can't seem to lay my hands on a solution.
Is this possible at all? If yes, what am I missing? If no, is there any better option to use?
Please do note that the chat app completely done, so I'm hoping perhaps there's a way I could directly convert the project to a Nuget package.
Thanks in anticipation!
If the host application is a Xamarin Forms one:
-Move your cross platform shared code into a PCL or .Net Standard (ContentPages, ContentViews, Classes).
-Move your Renderers and platform specific code to Android and iOs Class Libraries.
Your client will have to reference your first assembly (dll) in their XF assembly in order to instantiate/manipulate your views/classes and platform specifics one on their Back-end side (taking into account your renderers, effects, etc ...)
A lot of Xamarin Controls Libraries Open Source hosted on Github are working like that. For example this one: https://github.com/jamesmontemagno/Xamarin.Forms-PullToRefreshLayout
If the host application is a native application, take a look into Xamarin forms embedding
Finally, I seem to solve the problem by enabling visual studio to build Nuget packages for the chat app project (summing up to 3 nuget packages) on project build.
Thanks #Rudy Spano and #Micah Switzer for your contributions
I am upgrading a Win8 application to UWP. .NET Native is causing a huge amount of issues, and a lot of WCF features that the application uses aren't supported.
Is .NET Native required for UWP applications? Can I just disable .NET Native in the Release build? Apart from some potential .NET Native performance improvements, will I lose anything?
The point is you are migrating to the .NETCore for the UWP, the subset of the .net framework, that leads to lots of your original codes can't fit into.
Are you migrating from a winRT store application or full .net framework based desktop app?
So far as I know the .NET CORE really cut-off lots of stuff from the Full. So if migrating from a Full .net desktop, that's really suffer.
.NET is supposed to increase performance, however it may create serious troubles, in some cases, e.g. if application extensively uses marshalling.
You can disable .NET native for Release in project properties.
Open Project Properties and select Build tab.
Set
Configuration: Release
Platform: All platforms
Untick box 'Compile with .NET native tool chain'
After you build the project, allow to run Certification Kit (WACK), and if is passes, take my congratulations. (I am not that lucky!)
My setup for a mvvmcross project supporting iOS, Android and Win8 is to have two separate .sln files, one including the core, iOS and Android projects (for development in xamarin studio on mac) and one including core and winphone projects (for development in vs2012 on win8). However, I don't know which mvvmcross binaries (https://github.com/slodge/MvvmCross-Binaries) I should reference from my different .csproj files in this situation as there are two versions. Question is: what exactly is the difference between the two builds (XS-iOS-Mac and VS2012) and which binaries should I include for a working cross-platform setup? Thanks!
The difference between the two sets of binaries is that PCLs built on the Mac using the current Xamarin Stable releases are not true portable class libaries - see http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html
This situation is currently 'in flux' - the latest alpha release from Xamarin is starting to produce real PCL binaries - see http://deapsquatter.blogspot.co.uk/2013/07/xamarin-pcl-support-hoorah.html
Until this transition is complete, if you want to work off of the pre-built binaries, then one easy method is to:
link to binaries in a folder - e.g. in : /lib/Mvx/
on the PC, fill this folder from https://github.com/slodge/MvvmCross-Binaries/tree/master/VS2012/bin/Release
on the Mac, fill this folder from https://github.com/slodge/MvvmCross-Binaries/tree/master/XS-iOS-Mac/bin/Release
Alternatively, the nuget packages attempt to do this for you - and seem to work with one exception (a problem with using MvxCommand which is easily worked around using your own MyCommand in your Core project)
Perhaps my question is totally naiive and this is the reason why I couldn't find any information with Google or something else - but nonetheless, I think it is worth asking here.
I want to develop a C# application which behaves naturally in Mac and Windows (Linux would also be nice, but is not directly needed). My main operating system for development should be Mac OS X and therefore I want to go with MonoDevelop.
I can setup a project for MonoMac - works fine.
I can setup a different project for GTK# - works fine.
My question is now, what I have to do to get a project with a possibility for a MonoMac and a GTK#-frontend. So I will go with the MVC pattern and want to work in one project. As a result, building my project would result in a Mac executable (based on the MonoMac stuff) and one windows executable (based on GTK#).
Am I completely wrong with my approach?
What do I have to do to achieve my goal?
Yes, for a multi-platform app with the best possible look-n-feel on each platform, you would need one executable per platform. Using an MVC approach is the best way to do this - you can have a solution containing a library project with all the shared code - models, processing code, business logic, etc - and a project for each "frontend" executable containing the platform-specific views and shell.
If a really good native experience on Windows is higher priority than Linux support, I'd recommend using WPF or Windows Forms instead of GTK#. This would mean you'd have to split development between Windows and MacOS - you would need to open the same project in Visual Studio, SharpDevelop or MonoDevelop on Windows, and edit the WPF/WinForms project and the shared library there.
OTOH, GTK# has the advantage you could start off writing a single frontend that would work on all three platforms, and then write the platform-specific ones afterwards.
I'm writing a Windows 8 Metro Application using XAML, and am trying to add a reference using NuGet to Automapper, and it's saying its not supported. Is there a way around this? What are the requirements for adding references for Metro apps?
NuGet currently supports installing packages to Metro apps (work item #1527) but it does require the package libraries to be compiled for WinRT.
I had a look at Automapper and it only supports .Net 4.0 and Silverlight 4, it would need updated assemblies for WinRT. Note: other packages that don't have assemblies should install fine in Metro app.
Regardless of NuGet - absolutely no outside or third party assembly can be included in a Metro project that is not first recompiled in WinRT. There is one exception - Portable Class Libraries. But a PCL has many limitations and isn't what you are looking for.