Failing to extend my existing project with UWP , i search for reason why certain existing projects can't be extended with UWP.
Here i get an answer that all the nuget packages of X.shared project should be the same(with the same version) in the UWP project.
However , even after doing that the project failed to start , so i asked in the
xamarin-docs github and they tell me that the cause is a nuget package supported only in Ios and Android.
So my question is :
Should all the nuget packages be the same for *.ios *.droid, **.\shared and *.uwp ?
And what if i have other projects(not xamarin projects) in my solution ?
You don't understand the architecture of Xamarin and it is hard to answer in one paragraph, further reading of documentation instead of your constant asking of basically the same question on different places (please note that on the github you where warned that it was not the place to ask such a question) is highly advised.
But I'll try to answer. The package may use (or even need to use) native APIs to achieve some functionalities. Those native APIs are available only on one platform and such code is useless on another platform. So the package author in that case must write the separate implementation for each platform that he wants to support. He may cover just one platform or two or three, it is up to the package author. If the platform is not supported by the package and contains the native APIs, there is almost nothing that you can do aside to write your own implementation of the package for that. Even if you succeed in installing it won't work.
Related
I have created a Xamarin Android project. Via NuGet, I have added a reference to the Grpc package.
In my activity, I want to create a Grpc.Core.Server instance, but it won't let me because of the following runtime error:
System.IO.FileNotFoundException: Error loading native library. Not found in any of the possible locations: /storage/emulated/0/Android/data/DecodingPoC.DecodingPoC/files/.override/libgrpc_csharp_ext.x64.so,/storage/emulated/0/Android/data/DecodingPoC.DecodingPoC/files/.override/runtimes/linux/native/libgrpc_csharp_ext.x64.so,/storage/emulated/0/Android/data/DecodingPoC.DecodingPoC/files/.override/../../runtimes/linux/native/libgrpc_csharp_ext.x64.so
I haven't been able to find any information on this for Xamarin, only iOS, so I am hoping someone here can provide a suggestion on how to proceed.
Please note that gRPC c# support for Xamarin is currently experimental. The stable packages in nuget.org don't provide the support yet (that will change with the upcoming v1.15.x release).
See HelloWorldXamarin instructions on how to obtain the correct nuget package (or use the https://www.nuget.org/packages/Grpc.Core/1.15.0-pre1 pre-release package which already supports Xamarin):
https://github.com/grpc/grpc/tree/master/examples/csharp/HelloworldXamarin#experimental-only
You might also need this workaround if you are using Xamarin.Forms: https://github.com/grpc/grpc/issues/16250
I'm having a go at creating my first Android app using Xamarin. I'll be needing a database, and the Xamarin docs recommend the "SQLite-net-pcl" NuGet package (here). When I go to install this package it lists approx 50 dependencies that it wants to install! How much is this going to increase the size of my app by?
Is this normal with Xamarin development? Coming from a WPF background I admit I haven't got my head around all this .Net core/standard stuff yet.
And why do the docs recommend this package over the built-in 'Android.Database.Sqlite' namespace? Does the ease of use (of the SQLite.net package) outweigh the increase in app size?
How much is this going to increase the size of my app by?
Not much, Xamarin links out (removes) the unused code when you build your app in release mode. For example if you're not using any methods from System.IO, the assembly will not be included in the final build
Does the ease of use (of the SQLite.net package) outweigh the increase in app size?
Part of it is ease of use and the real advantage is you can reuse the code on iOS or any other platforms. Using Android.Database.Sqlite doesn't help you much if you're planning porting your app to other platforms
What determines which of those 50+ assemblies get pulled into my app?
Dependency on the netstanderd is what pulling those 50+ assemblies, otherwise Sqlite-net-pcl just need SQLitePCLRaw.* assemblies
There is nice series explaining netstanderd from one of the .Net engineers on youtube here - https://www.youtube.com/playlist?list=PLRAdsfhKI4OWx321A_pr-7HhRNk7wOLLY Hope it will answer your questions regarading netstanderd
I have tricky question about SignaturePad updated to Xamarin Forms 2.0, link to GitHub:
https://github.com/mrbelk/acr-xamarin-forms
I did manage to download repo and build it, however I have no idea how to produce proper DLLs that I could use in my project?
The main issue is that SignaturePadView is treated as Xamarin Forms View class instead of Android View, so there is different constructors, methods, etc.
Does smb know how to build these projects to produce proper dlls that iOS/Android solution will treat SignaturePadView as Android View and iOS UIView respectively?
Don't use acr.* any more if you want to save yourself some pain. I had to pull their camera implementation out of one of my apps due to no support for forms 2.0+.
Replace acr with supported NuGets like Plugin.Media and the others found here. For this particular issue no one has created a non-deprecated NuGet so there is this plugin as an option.
Apparently, it happens that we have actually used SignaturePad from https://components.xamarin.com/view/signature-pad but via acr.* nuget package.
What I found in my quick research that both acr.xamforms.SignaturePad and SignaturePad it self were in acr nuget package, and actually we were using components from SignaturePad, luckily. So I did remove this nuget from sln to get rid of acr.* components and add SignaturePad from xamarin components by hand.
Now we are able to use Xamarin Forms 2.0 without any problems.
Cheers,
G
I am using Xamarin and need to use a PCL
However, I cannot install ServiceStack into the PCL other than the PCL package which is classed as no longer being maintained
Has anyone come across this?
I want to use PCL because I dont want to duplicate code
PCLs are supposed to be supported via the latest Service Stack but this does not appear to be the case
I have code which makes use of ToJson which is in ServiceStack.TExt
I know I could create a folder inside my iphone (and android) assemblies but I am not sure this is a good approach because it doesnt feel right (everything all in one place instead of in proper layers)
Does anyone have any ideas about this?
Paul
Your assumptions aren't correct, ServiceStack PCL Packages ARE still being maintained, but instead of being maintained in individual packages, e.g:
ServiceStack.Client.Pcl
ServiceStack.Text.Pcl
ServiceStack.Interfaces.Pcl
They have now been merged as different profiles into the main client NuGet packages, e.g:
ServiceStack.Client
ServiceStack.Text
ServiceStack.Interfaces
I develop with Visual Studio. I have a class library that contains code common to many products I develop, and is now in use by 15+ solutions. I do LOB apps for my non-software company.
I've been adding this class library project directly to the solutions of all the solutions that need to use it. But I've been using NuGet to pull in many 3rd party packages and I really like its way of doings things. I'm thinking about adding this utility library as a NuGet package in our own repository rather than adding it directly as a project reference in the solution.
Is this a good idea? What criteria should I use to determine when to use NuGet vs when not to for internal class libraries? I realize that some might think this is an opinion based question, but I'm looking for specifically what criteria you'd use to decide rather than opinions about which is better.
Internal libraries that used and worked on by multiple teams can be exposed as Nuget packages. This way, multiple teams can work on the library, and each of them can update to a version as and when needed by that particular team.