I'm trying to make Npgsql, the PostgreSQL provider for .NET, available for consumption by Xamarin users. I've explored various methods for doing this and seem to be blocked.
First, a Xamarin project can consume packages which target certain PCL profiles. The problem is that none of of these PCL profiles contain System.Data, which Npgsql requires, even though Xamarin itself allows you to use System.Data.
Second, Npgsql already supports the .NET Platform Standard (version 3), and the documentation on the standard contains the following sentence:
If a library targets .NET Platform Standard version 1.3, it can only run on .NET Framework 4.6 or later, .NET Core, Universal Windows Platform 10 (UWP), and Mono/Xamarin platforms.
However, trying to go down this path yielded several errors (this question is one of them). My guess is that the Xamarin tooling isn't yet fullynetstandard-aware.
Finally, it seems possible to import Npgsql as a shared project inside the user's solution, but this seems like a very hacky and wrong solution - it bypasses NuGet entirely.
Does anyone have any info on this?
That npgsql package seems to be depending on pre-release packages (RC - Release Candidate). Run the install with -pre option:
Install-Package npgsql -pre
This worked at least when installing to an iOS project. Not sure if it functions correctly as none of the dependencies are added to the References, only Npgsql.
I believe your speculation is correct of Xamarin tooling not being fully netstandard/PCL5 aware AFAIK(Your speculation is as good as mine). This is a huge effort by all parties involved to be unified. There have also been significant changes on the dotnet end that can alter this.
For your questions about System.Data:
System.Data is missing a bit of functionality: https://developer.xamarin.com/guides/ios/advanced_topics/system.data/#Missing_Functionality
System.Data is available via the Xamarin.iOS.dll assembly as it's not supported in PCLs.
https://developer.xamarin.com/guides/ios/under_the_hood/assemblies/
https://msdn.microsoft.com/en-us/library/system.data(v=vs.110).aspx (Notice no PCL items inside)
Finally, there should be a blog post next week about netstandard via https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/
I would highly recommend that you join the .NET core slack channel to ask any questions you may have.
http://tattoocoder.com/aspnet-slack-sign-up/
Related
I am doing maintenance work on a VS2010 C# project built against .net v3.5.
I recently changed the project Target Framework properties to the latest version listed (v4) - due to an expectation of using a version of .net that is actually included in Win10 by default - and rebuilt without any apparent issues.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5.
Using MS VS2010 v10.0.40219.1 SP1Rel.
Unfortunately upgrading the build tools isn't an option (building the program with VS2015 works just fine).
I have gone googling but don't seem to have found any similar reports.
Based on some of the comments already posted, I seem to have not made myself entirely clear - hopefully the following will help.
1) the intention/requirement is to be able to install this app on a clean install of Win10 without needing any further downloads. (installing .net 3.5 is easy to do, just not what is wanted)
2) the ultimate build environment for this is automated, visualized and not in my control and therefore upgrading the tool chain is a major pain that I'd like to avoid if possible.
3) AFAIK there are no third party libraries involved. All of the listed references (dll's) are v4.0.30319.
4) this is a XAML-based development, one part of three projects in the solution - the other entries are the installer and a C# custom installation library. As far as I can tell everything is set for .net v4.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5
So there is some dependency in your project that targets that version of .NET. It could just be that you need to Build > Clean Solution and with a Build > Rebuild Solution the problem is solved.
Otherwise, assuming some library does require some .NET 3.x library, the installation request is entirely correct. Windows 10 does not have an option for installing .NET 2.0 and another for installing .NET 3.5. If you search for Turn Windows features on or off you will see this:
Any dependency on a .NET 2.x-3.x library will trigger the activation/installation of the first feature in the dialog.
As far as I can see, you have 2 options:
Move everything to a framework supported by Microsoft, most preferably .NET 4.7.2 given support and security.
Deal with the installation process and understand that Microsoft does not install these versions of .NET in purpose. You can, however, add these installers as a prerequisite and even bundle them with your installation, but that won't help much.
Thanks to all who have tried to help me!
The issue has been resolved.
There appear to have been two causes for this issue and my confusion:
it turns out that the blank install of Win10 that the testing was being performed on was not entirely clean - the pre-installed network drivers/utilities from intel also had a .Net v3.5 dependency...
one of the embedded resources in the project was effectively a uncompressed tar-ball containing a number of files; including an executable that had the dependency on .net v3.5 - this was a binary blob stored in svn so the content was had not been updated for several years (ie well before my involvement) ...
With both of these issues addressed it would appear that my problem is solved, so once again thank you for your feedback, suggestions and patience,
PeterT :->
My problem is very similar to that mentioned in this post:
System.ObservableExtensions.Subscribe: ambiguous reference
I would like to use the "GraphQL for .NET" nuget package and the "Plugin.BluetoothLE" package.
"GraphQL for .NET" references System.Reactive.Core and "Plugin.BluetoothLE" references System.Reactive
As stated in the other post:
Upon further investigation I found that ObservableExtensions exists both System.Reactive.Core and System.Reactive.
How do I resolve this? "Plugin.BluetoothLE" has System.Reactive 4.0.0 and "GraphQL for .NET" has System.Reactive.Core 3.1.1.
Is there a way for me to upgrade System.Reactive.Core inside GraphQL?
I havent tried this below but you can see on their github it was described as breaking change and there is workaround. see the highlighted sentence below.
v4.0 changes
Due to the overwhelming pain that fixing #205 - Implement assembly version strategy caused, we have refactored the libraries into a single library System.Reactive. To prevent breaking existing code that references the v3 libraries, we have facades with TypeForwarders to the new assembly. If you have a reference to a binary built against v3.0, then use the new System.Reactive.Compatibility package.
Supported Platforms
Rx 4.1 supports the following platforms
.NET Framework 4.6+
.NET Standard 2.0+ (including .NET Core, Xamarin and others)
UWP
Notably, Windows 8, Windows Phone 8 and legacy PCL libraries are no longer supported.
v3.0 breaking changes
The NuGet packages have changed their package naming in the move from v2.x.x to v3.0.0
Rx-Main is now System.Reactive
Rx-Core is now System.Reactive.Core
Rx-Interfaces is now System.Reactive.Interfaces
Rx-Linq is now System.Reactive.Linq
Rx-PlatformServices is now System.Reactive.PlatformServices
Rx-Testing is now Microsoft.Reactive.Testing
This brings the NuGet package naming in line with NuGet guidelines and also the dominant namespace in each package. The strong name key has also changed, which is considered a breaking change. However, there are no expected API changes, therefore, once you make the NuGet change, no code changes should be necessary.
One of two ways
Try setting Nuget to get the minimum version to the lowest one listed by your packages.
Split out the operations into separate libraries and manage the differing package version specific to library.
Today I was adding a NuGet package DocumentFormat.OpenXml into my C# project. My C# project is targeting.Net framework v4.5. In NuGet package manager it shows the information of dependencies of the NuGet package as shown below:
There is no information corresponding to .Net Framework v4.5. So, how do I interpret this information if my project is targeting .Net Framework v4.5. Is this information missing or there is any default assumption in such cases may be no dependencies. Can someone share some information in this regard
Note: This question might look like a non-programming question but I got stuck even before writing a single line of code so asking it in this forum.
.NET Frameworks are backwards compatible. Meaning if your project is targeting v4.5, you can consume packages with lower versions, such as v4.0, v3.5.
NuGet's specialty is compatibility checking (if packages are authored correctly ofc) :)
NuGet knows the available frameworks are v3.5, v4.0, v4.6 and netstandard1.3.
The "nearest" compatible framework with v4.5 is v4.0, so it'll pick the v4.0 assets when you install it.
So the answer, it has no dependencies in your case.
Please note that framework compatibility is not always apparent from just looking at the TFMs on nuget.org, there's different fallbacks that NuGet will attempt.
So really the best way to figure out what the dependencies are would be to install it in the project, since NuGet might need to resolve conflicts etc. if you have other dependencies.
I am confused with packaging of HttpClient. Earlier it was distributed as a part of Microsoft.Http.Net NuGet package while System.Net.Http was considered legacy. Looks like now it's the opposite: there is a fresh System.Net.Http package for all platforms and Microsoft.Net.Http has not been updated in a while and according to folks at Microsoft development team is going to be deprecated.
Questions then:
Can we replace dependencies on Microsoft.Net.Http NuGet package with (the newest) System.Net.Http?
Should legacy .NET 4.0 platform still use Microsoft.Net.Http?
What about non-Windows platforms (iOS, Android)? The new System.Net.Http supports them, but I remember with Microsoft.Net.Http I had to install additionally Microsoft.Bcl.Build and Microsoft.Bcl in order to get cross-platform stuff to work. System.Net.Http doesn't depend on them. Can Bcl packages be skipped?
System.Net.Http lacks some Http extension methods, like SupportsPreAuthenticate, and an attempt to call these method results in runtime errors (missing method). How should we deal with this?
This has been for a long time and continues to be confusing. I have seen such messaging myself but as of right now, it appears System.Net.Http is the correct choice, at least for .NET on the Windows platform and has no external dependencies.
For .NET Core, I have used Microsoft.Net.Http although it does require Microsoft.BCL. Unless you are experiencing problems, I suggest leaving legacy systems as-is, especially since these namespaces seem to be moving targets.
If that isn't confusing enough for you, the HttpClient Sample linked from System.Net.Http uses Windows.Web.Http! That implementation is for Windows Store apps.
Perhaps next year this will all change again.
I'd would like to use RabbitMQ .I find nugget .NET but i get error :
You are trying to install this package into a project that targets 'MonoAndroid,Version=v6.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.
How Can I implement connection with RabbitMQ . Manual copy source ?
The issue is that the RabbitMQ nuget package needs the full .NET Framework. Since PCLs and Xamarin Android projects don't provide the full framework, it won't work. One option is to take the source code and build it in a PCL like you suggested (eg see https://forums.xamarin.com/discussion/49858/using-rabbitmq-amqp-with-xamarin-forms). Depending on what you want to do, I think using the HTTP API might be worth considering too.
Rabbit MQ is now also built as a .net standard 1.5 libraries. https://www.nuget.org/packages/RabbitMQ.Client
You should be able to pull it into the latest Xamarin without any problems (taking into account that your xamarin build is set up to support version .net standard 1.5 or version 2.0).
Xamarin forms added support for standard libraries from version 2.3.5-pre
https://devblogs.microsoft.com/xamarin/building-xamarin-forms-apps-net-standard/
UWP is easily supported with .net standard 2.0 and is compatible with the 1.5 libraries.