Installing NodaTime 2.2.x in PCL with Profile44 - nodatime

I am working on a PCL project that is using Profile44 as TargetFrameworkProfile. When I try to install NodaTime 2.2.4 I get the following error message:
Could not install package 'NodaTime 2.2.4'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.6,Profile=Profile44', 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.
Do I have to downgrade to .Net 4.5 or what options do I have?

Noda Time 2.x only supports the Target Framework Monikers netstandard1.3 and net45. There's no direct PCL support, although some environments that traditionally used PCLs now support .NET Standard.
The 1.x series supports PCLs via Profile328, which has a NuGet target of "portable-net4+sl50+win8+wpa81+wp8". For environments that don't yet support .NET Standard, trying the 1.x series is the best option.
Note that I'm expecting Noda Time 3.0 to probably target netstandard2.0, although I'll still keep the older versions up to date with respect to time zone data.

Related

WindowsAzure.Storage SDK missing APIs in .NET Standard

I am converting a .NET Framework 4.7.1 class library to .NET Standard 2.0.
The library consumes a number of Nuget packages, all of which are available for both .NET Framework and .NET Standard and these packages include the WindowsAzure.Storage SDK.
The original .NET Framework class library compiles and runs correctly, but the .NET Standard library fails to compile, due to missing APIs (and some different method signatures) on the WindowsAzure.Storage SDK.
For example, CloudBlockBlob has a DeleteIfExists method in .NET Framework but not in .NET Standard.
The API documentation lists this method (and all the others that are broken in .NET Standard) but doesn't appear to mention any version differences between target frameworks. Did I miss something relevant here?
Is it normal that some .NET Standard Nuget packages have gaps in their APIs?
Is there a solution or a workaround for this (apart from re-writing the code that consumes these APIs)?
Thanks, in advance.
As per Peter Bons mentioned, In the nuget package WindowsAzure.Storage, there are only task based methods, so DeleteIfExistsAsync for .net core / .net standard.
Please use the new nuget package for azure storage. For blob storage, you can install Microsoft.Azure.Storage.Blob, version 9.4.0 or above, which does support sync / async methods.
The change log is here:
And here is a simple test with .net standard project with Microsoft.Azure.Storage.Blob, version 9.4.0 or above installed. Both sync / async methods are there.

Migrate Microsoft.WindowsAzure.Mobile.SQLStore to Microsoft.Azure.Mobile.Client.SQLiteStore

I am trying to update one of my Xamarin.Forms apps that uses the deprecated Microsoft.WindowsAzure.Mobile.SQLStore pacakge with the new Microsoft.Azure.Mobile.Client.SQLiteStore package but I get the following error when I try to install the package in my Core pcl project:
Could not install package 'Microsoft.Azure.Mobile.Client.SQLiteStore 4.0.0'.
You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile78', 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 tried to follow this documentation but they seem to forget to add the code sample, so I can't figure out exacly what they are doing. The deprecated Microsoft.WindowsAzure.Mobile.SQLStore package installed in a PCL library but the new Microsoft.Azure.Mobile.Client.SQLiteStore package doesn't or so it seems.
Any help would be appreciated.
It turns out that Microsoft.Azure.Mobile.Client.SQLiteStore 4.0.0 does not support PCL anymore but they moved to .NET Standard 1.4. PCL support stops at version 3.1.0
So if you are using PCL install v3.1.0. But before you install v3.1.0, make sure you manually remove the deprecated Microsoft.WindowsAzure.Mobile.SQLStore first.
Check out this issue for more details: https://github.com/Azure/azure-mobile-apps-net-client/issues/337
you can try and open the .csproj of your PCL and replace the Profile78 entry with a profile the NuGet package supports (probably Profile259 which includes almost everything but windows phone silverlight)
If your project won't compile after changing your profile (because there are missing type references e.g.) try picking a different profile the package supports.
If you're having multiple PCLs you might need to change the target profile of all of them.
Try Changing .Net profile to Profile 7 and then update.
Go To Cross Platforms Project Options->Build->General->.Net Portable

What is the importance of CoreCLR, PCL and WinRT in Azure-Storage-Net change log

I was inspecting the change log of Windows Azure Storage nuget from here. I do not get the usage of CoreCLR, PCL and WinRT.
For instance
Changes in 7.2.0 :
All (CoreCLR): NetStandard target framework changed to netstandard1.3
All (PCL): Removed support for PCL in favor of NetStandard GA release
...
Changes in 7.1.2 :
...
All (WinRT): Fixed a bug where HttpClient default timeout caused unhandled TaskCancellation exceptions.
...
A simple search on google tells that CoreCLR is a .NET execution engine and WinRT stands for Windows Runtime. I do not know what PCL is.
So what is the importance of these in change log in simple terms?
Those represent versions of the package capable of running on different versions of .Net:
WinRT is used in Windows Store apps, it uses a trimmed version of .Net
PCL is short for Portable Class Library, the old approach of targeting multiple versions of .Net from a single library
NetStandard is a new approach of targeting multiple versions of .Net, that came along with .Net Core, the new modular cross-platform version of .Net
CoreCLR is the runtime used by .Net Core, though marking changes to NetStandard version of the library as "CoreCLR" is confusing

Can't update hot tuna ios dialog support to version 3.5

When I try to update or to install dialog support package I get the error:
Could not install package 'MvvmCross.HotTuna.Touch.Dialog 3.5.0'. You are trying to install this package into a project that targets 'MonoTouch,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.
The issue is you are still targeting the old 32 bit only iOS api (the MonoTouch.dll). All apps being written for the store must support 64 bit and 32 bit (Xamarin.ios.dll).
You can I believe get a build of mvvmcross 3.5 that will support the old apis, but I'd look at upgrading your project to support the new iOS apis. Xamarin produce some good docs here: http://developer.xamarin.com/guides/cross-platform/macios/32-and-64/.
This goes without saying but make sure you have everything in source control first before upgrading just in case. Once you have upgraded you should upgrade all mvvmcross components to 3.5

Force NuGet to download packages built to project .Net version

This should be a simple question but I can't seem to find the answer anywhere.
I've got a project that I'm building to .Net 3.5. I'm trying to include Newtonsoft JSON.Net as a reference, but NuGet is installing a version built to .Net 4.0. This makes it impossible for me to use my compiled assembly in an environment that does not support .Net 4.0.
Is there any way to configure NuGet so that it ensures that the reference is not built to a version of .Net beyond the project settings?
Maybe you can use this answer to a similar question:
Download old version of package with nuget
It says that you can install an old version of a package
You can try to install a version compatible with .NET Framework 3.5, and it will be solved!
;) I hope this helps
NuGet will use the project's target framework to pick the correct assembly from the NuGet package. You cannot override this behaviour.
The latest version of the Json.NET NuGet package (6.0.1) contains an assembly specifically for .NET 3.5 so NuGet should automatically pick that one if your project has a target framework of 3.5.
Changing my project's target framework to 3.5 results in the following element being added to the project:
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
This is what NuGet uses to determine which assembly to use.
When Json.NET is installed into this project the Newtonsoft.Json.dll file is referenced from the packages\Newtonsoft.Json.6.0.1\lib\net35 directory. That assembly targets .NET 3.5

Resources