I have a class library such as .NET Standard 2.0 that uses a nuget. I have multiple clients that use this class library. Will the client automatically get the required files from the class library references or do I need to install the same nugets used in class libraries in client apps that consume the library?
It depends on the nuget, generally in nuget's which are purely .net based won't be needed to be installed on the platform projects, for example, Json.net.
But let's say that you are using a nuget which interacts with the native api, under the hood, like Rg.Plugins.Popup, which lets you create UI basically which is not entirely only .NET thing, so it will be required to be installed on all the platforms.
There's really not a way that you can differentiate between them, but if you check the nuget's Github page, they would generally mention whether you need to install it on platform projects or not.
But you can assume that something which affects the UI would be needed to be installed on the platform project, whereas something which does nothing but pure logical processing would only be required to be installed to your .NET standard library.
Related
I have a .NET Standard class library project. I want the library to be available to the broadest array of consuming applications, so following Microsoft's advice here, I am targeting .NET Standard 1.3 in my project properties.
However, there is also a NuGet package called NetStandard.Library. And somewhere along the line, my project got a reference to this as well. What's more, it's a different version (1.6). I'm confused. Is this okay?
What is the relationship between these?
And somewhere along the line, my project got a reference to this as
well. What's more, it's a different version (1.6). I'm confused. Is
this okay? What is the relationship between these?
I think you should not worry too much about that.
1.6.1 is just the version of NetStandard.Library nuget package and it has nothing to do with the version of the target platform, and they don't interfere with each other.
The NetStandard.Library nuget package just service the related net standard project and provide any libs and apis to develop,build, debug the current project.
Besdies, NetStandard.Library 1.6.1 service net standard 1.x project while NetStandard.Library 2.0.3 services net standard 2.x projects.
So when you finishing developing it and pack your net standard 1.3 lib project as nuget package and then use it in target platform, actually, NetStandard.Library nuget package already finish its job and it is irrelevant in this step.
When you use such net standard project into other target platform projects, you only need to consider that whether the net standard version and the target platform version are within the scope of support as your linked document describes.
--------------Update 1-------------
Actually, sure.1.6.1 version is just only the nuget package version. NetStandard.Library 1.6.1 nuget package defines one or more standard.net version libraries.
And as far as I know, 1.6.1 version supports net standard 1.0~1.6 class library projects and the nuget package services for those net standard version.
And then it will direct the current project to the corresponding target platform projects.
Hope it could help you.
I have a Xamarin Forms application that uses shared code. It has three projects, shared, iOS and Android. These are very similar to those which are created when I create a sample application from the Xamarin new project menu.
I am looking to have the application updated and published by a company that has experience in doing this but I am not sure I understand a couple of the work items that have been suggested to me:
Currently, architecture is PCL which is becoming
obsolete.
Move to .NET standards
Could someone explain to me what these work items might mean?
Yes, it will become obsolete at some point. .NET Standard is the evolvement of the PCL libraries.
With PCL libraries you could target a number of platforms and only the functionality that was supported for all targeted platforms were available to you. Associated with each combination of platforms were the profiles. A profile was identified by two or three digits. Notable ones for Xamarin were 111 or 259. Read more on PCLs here: https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/pcl
.NET Standard is a specification of the APIs associated to it. If a platform supports a certain version of the .NET Standard, you are guaranteed that all APIs are available. This way, you can simply target a specific .NET Standard version and each platform that supports it will support your application. The .NET Standard specification has gained a lot of traction and is already more cross-platform than a PCL ever was. Most of the creators of NuGet packages are supporting it already and also Xamarin/Microsoft has replaced the PCL with a .NET Standard library in their templates. Read more on .NET Standard as a concept here: https://learn.microsoft.com/en-us/dotnet/standard/net-standard
So, if you have the possibility it might be wise to start moving to the .NET Standard library. That is, if you want to keep supporting your app and need new libraries coming in. If your app is fine the way it is, you can probably keep going with the PCL for a while. Converting is basically: change the csproj structure to the new structure. Retarget your library to netstandard and reinstall all the libraries you have installed, this time to download the .NET Standard compatible version. The last step might be a bit of a pain.
A good resource on converting might be this by Adam Pedley: https://xamarinhelp.com/upgrade-pcl-net-standard-class-library/
There is also a solution to do it automatically: https://smellyc0de.wordpress.com/2018/03/23/automatically-converting-pcl-to-net-standard-2-0-project/
.Net Standard is a specification for a set of APIs. and is the way things are going. With it, comes a higher level of range of .Net SDK APIs you can use, plus most 3rd party Nuget packages will support it. They can support a wider range of platforms. by targeting .Net Standard. Thus you will get access to a larger number of nuget packages. See https://learn.microsoft.com/en-us/dotnet/standard/net-standard
I put my Forms Apps into a .Net Standard library, because it easier to unit test. There is a Xamarin Forms nuget package you can use for testing, which means a lot of UI paths can be verified in code, where previously you had to do it on a device, perhaps with automated testing. https://github.com/jonathanpeppers/Xamarin.Forms.Mocks
Upgrading an existing PCL project to .net standard is a pain. Any more, I just create a new Xamarin Forms solution with the same name/root namespace, with the app as .Net Standard, then copy files over.
I am trying to work with facerecognition in xamarin forms by following these guides:
https://blog.xamarin.com/building-smart-apps-with-microsoft-cognitive-services/
https://blog.xamarin.com/adding-facial-recognition-to-your-mobile-apps/
When I add the needed packages: Microsoft.ProjectOxford.Face and Microsoft.ProjectOxford.Common to my shared project it works but once I add them to my iOS project the Microsoft.ProjectOxford.Face does not get added with the following error message:
Could not install package 'Microsoft.ProjectOxford.Face 1.1.0'. You are trying to install this package into a project that targets 'Xamarin.iOS,Version=v1.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
I have tried to install every version from it, all the way from 1.1.0 to 1.2.5.1.
I have the Newtonsoft.Json package installed as well as the Microsoft.Net.Http as well that is required.
Any idea how I can solve this?
You do not need to add this package to your platform projects. Since this i just a wrapper to access the Cognitive Services APIs it will work directly from the shared code.
The only time you need to install a NuGet on both your shared as well as your platform projects is when it leverages platform specific features. Have a look at the Dependency Service which is included in Xamarin.Forms.
That is basically what those NuGets do, they provide you with an interface to use in your shared code, but under the hood functionality is injected from the platform that you are running on.
In this case there is no need to access platform specific features, so you can just install it on your PCL and it should work.
I have a SDK written in C# targeting Win10 UWP apps.
It uses SQLite and works perfectly on C# client apps.
But can a C++/javascript app use my SDK with the SQLite dependency?
A winmd (windows runtime component build) would be required in case the SDK has to be UWP compatible since a UWP app can be in C#/C++/javascript/Visual basic.
I have posted this in msdn forums and they say i would need a windows runtime component for all the 3rd party dependencies for it to work.
Have already tried wrapper projects and wrapper winmd build, it does not work.
I am unable to find any winmd build for SQLite library.
Please advise on what can be done here.
Any help is really appreciated.
But can a C++/javascript app use my SDK with the SQLite dependency?
Yes, as in msdn forums said, you will need to wrapper in WinRT component universal apps.
Have already tried wrapper projects and wrapper winmd build, it does not work.
I don't know what blocks you, but you can refer to Writing a SQLite wrapper component for universal Windows apps, there are detailed steps you will need to follow, and samples you may have a look.
I tried various approaches to make this project work and found some success in the following:
Following is the project structure I made along with dependencies :
Client Application (in C++):
Wrapper winmd library.
Wrapper winmd library (in C#): (I generate a winmd component from this project)
My SDK project
My SDK project (in C#):
SQLite Net.
SQLite Net Async.
Newtonsoft JSON.
When I build the client application, I get the wrapperlibrary.winmd file but I dont get the corresponding dlls from the 3rd party dependencies in the output directory (SQLite and Newtonsoft). So i manually copied the required dlls to the output directory of the C++ application. Now it seems to work correctly, I can verify correct usage of the 3rd party libraries and my C# code. Presently I am just trying to make the setup work as a poc and worry about the packaging later.
The issue I now face is that my SDK also has some UI elements, so essentially compiled .xbf files for the "XAML" I have.
I have asked this question in another thread to not go off main topic here.
I have a Windows Phone 7.1 project with a Portable Class Library targeted to SL4, .Net4.5, WP7.5, Store Apps, but this is not available: http://msdn.microsoft.com/en-us/library/dd642331.aspx
It says it should be available in .Net 4.5. Of course I can program it myself, but I prefer to use functionality provided by the framework.
If I change to Windows Phone 8 (and remove SL4) it is available. Any hacks possible to get it working targeting WP7.5 / SL4?
You'll need to implement it yourself for WP7.5 and SL4. However, you can make it so that on platforms that already support it (ie .NET 4.5, WP8, etc), it will use the in-box version (and thus you can share it with other libraries that use the "official" version.
Basically, create your implementation as a PCL that targets all the platforms you want. Then create another PCL targeting the platforms that do support System.Lazy. This second library should have the exact same assembly identity as the first one, but instead of having an implementation of the type, it should use the TypeForwardedToAttribute to forward to the existing version of the type.
Then PCLs targeting broader platforms can use the first assembly you created, while platform-specific projects or PCLs targeting narrower platforms can reference the second one. You can make it easy to reference the right version of the assembly from the right projects by packaging them up into a NuGet package.