I'm trying to build an app on Xamarin that targets multiple platforms but uses rx. So far I've created a core PCL which I would like to use rx, but when I tried to import the rx 2.1 nuget package I get the following error:
You are trying to install this package into a project that targets
'portable-net40+win+sl50+wp80+MonoAndroid10+MonoTouch10', 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 am aware that there is an rx component in the xamarin store, but it doesn't seem like I can add this into my PCL.
It seems to me that ideally I want the core rx libraries in the PCL, but that platform specific schedulers should be imported in the platform specific app implementations.
What is the best way to proceed at the moment?
n.b. I am aware this has been touched upon in other questions, but the answers pre-date release channel PCL support in Xamarin.
edit:
I've modified my PCL to target .net 4.5 (and removed silverlight). I can now pull in the rx nuget package but I'm getting a build warning that it cannot resolve 'system.runtime.interopservices.windowsruntime'.
Have a look at Paul Betts's ReactiveUI on GitHub. I've not done any Xamarin development personally, but I know that project uses Rx and is organised to run on multiple platforms including Xamarin - it will probably give you the right approach.
Paul Betts's also mentioned this in another question: Is Reactive Extensions 2.1 PCL compatible with Xamarin?
At the moment, Xamarin Stable can't build PCLs (Alpha just got it, I haven't experimented with it though). Just use multiple csproj files at the moment (see https://github.com/paulcbetts/starter-mobile for an example)
With the stable release (Xamarin.Android 4.10.1), it's still weird as I found out. I have the followinig setup:
(1) PCL-Library with profile 49 (.net 4.5, Windows 8, Xamarin Android/iOS).
(2) Xamarin.Android App referencing (1).
If Rx is added from Nuget to both projects, it adds "targetFramework="portable-net45+wp80+MonoAndroid10+MonoTouch10" to packages.config and adds references to "packages\Rx-Core.2.1.30214.0\lib\Portable-Net45+WinRT45+WP8\System.Reactive.Core.dll" to both projects.
(1) builds fine then, but (2) doesn't (missing system.runtime.interopservices.windowsruntime, as in the initial question).
Changing the Rx-path in (2) to "packages\Rx-Core.2.1.30214.0\lib\net40\System.Reactive.Core.dll" however works, though (2) still references (1).
I had a look into the Rx code. References to System.Runtime.InteropServices.WindowsRuntime are guarded by #if HAS_WINRT, so I guess a library that relies on WinRT shouldn't have been put into a Xamarin.Android project by NuGet in the first place.
It's okay for me to change references manually, don't know what will happen if Rx gets an update.
But why is it ok to have the wrong dll in the PCL-project (1) and let (2) reference (1) ?
Related
When updating a project to use current Catel version (4.0) I am getting this warning:
All projects referencing MyInfrastructureProject.csproj must install nuget package Microsoft.Bcl.Build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317569.
The error is reported for projects that references MyInfrastructureProject.csproj.
I find it odd that I need to add additional libraries to other project especially when it is concerned with nuget (if I am getting the picture correctly) and not with actual functionality of my code (or maybe even Catel). But in any case, I don't really understand the issue.
I searched a little for this issue but didn't find relevant details or explanations.
Should I go ahead and add the Microsoft.Bcl.Build reference everywhere in my project?
Thanks,
Tomer
If you don't know what is Microsoft.Bcl.Async you should study it.
Catel uses this feature pack so as to use async/await on .NET 4 and Silverlight 5. So if you use Catel in a .NET 4 project, you inherit the same dependencies, which is what the warning says.
Thus, yes, please go ahead and add the NuGet package to the necessary projects, or simply upgrade your projects to .NET 4.5 and reapply the NuGet packages.
This should be pretty straightforward, but can't work this out for myself I'm afraid!
The following line of code triggers the error:
using Microsoft.Xna.Framework.Storage;
Error: The type or namespace name 'Storage' does not exist in the
namespace 'Microsoft.Xna.Framework' (are you missing an assembly
reference?)
But as far as I can tell, I have added the reference: (Solution explorer -> right click References -> Add reference -> .NET tab -> scroll down to Microsoft.Xna.Framework.Storage -> select it -> click OK).
Microsoft.Xna.Framework.Storage shows up when I expand "references" in the solution explorer.
What am I missing?
EDIT
Okay on second look this might be to do with how I'm adding the references. When I search in the object browser Microsoft.Xna.Framework.Storage doesn't show up (but when I search, for example, for audio, Microsoft.Xna.Framework.Audio does show up). Is there anyway to check that when I click "OK" on the add reference pop-up that it is actually working?
I see two likely possibilities.
You have a mismatch of XNA 4.0 and XNA 3.1 (or previous) references in your project. If the Storage reference you added is from 3.1, you'll get this message. You can try removing it, and then looking specifically for the 4.0 version during add.
The device you are building for may not support the Storage mechanism. In particular, Windows Phone apparently uses a different storage mechanism (System.IO.IsolatedStorage http://msdn.microsoft.com/en-us/library/ff604992.aspx).
Hope one of these helps.
This question was asked a long time ago, but if anyone else is still looking for an answer, here is how i fixed it.
If you installed the Microsoft.Xna.Framework references by using the installer from Microsoft, then it installs in C:\Windows\Microsoft.NET\assembly. I found all of the Xna libraries in GAC_32 and Microsoft.Xna.Framework.Storage in GAC_MSIL.
You can also use the GAC to find libraries that aren't in Visual Studio's reference list. For .NET Framework versions before 4.0, the libraries are in C:\Windows\assembly, and the libraries for versions after 4.0 are in C:\Windows\Microsoft.NET\assembly.
It's actually been removed from Monogame by Microsoft.
Running: Windows 10, with integrated graphics card (Intel G45/G43), Visual Studio 19, Monogame 3.7.1
Project Structure: Solution > Game.Shared, Game.Android, Game.OpenGL (followed this guide on creating a Cross-Platform project, method number 3).
I changed the Target Framework in my OpenGL project from .NET 4.5 to .NET 4.7.x (the newest version), and I was able to build and deploy the app to an Android device. Do this by clicking the project and selecting Properties.
I simply commented out the line. App will successfully deploy to an Android device this way. The game will then deploy, but I can't get any content to load.
Have yet to see if I can deploy to an iOS device, I will update this post when I figure out if I can.
No nuGet's installed.
I have built a NuGet package for my Simple.OData.Client with support for Xamarin Android and iOS. This library uses Microsoft.Bcl.Async. Tests using Android and iOS simulator went OK, but when I install this new NuGet package into another project, it fails to compile Droid/Touch projects with the following message:
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(720,2): error : Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'Microsoft.Threading.Tasks.Extensions, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Perhaps it doesn't exist in the Mono for Android profile?
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(720,2): error : File name: 'Microsoft.Threading.Tasks.Extensions.dll'
Of course there is no Microsoft.Bcl.Async pack (yet) for Mono platforms, on the other hand since the library tests pass on these platforms, I guess this more of a challenge to make Visual Studio happy rather than do some code modification.
Has anyone managed to use on Mono PCLs dependent on Microsoft.Bcl.Async?
Generally, if the code in your package depends on another NuGet package, you need to declare a package dependency so that anyone installing your package will get the one you depend on too. That should take care of issues like this.
However, in this case it is a lot more complicated. Since Microsoft.Bcl.Async doesn't support Mono platforms, you can't declare that package dependency (or if you did it would always fail to install). Unfortunately the license for Microsoft.Bcl.Async restricts it to "Windows platforms". I'm not a lawyer but I think that means you shouldn't distribute Microsoft.Threading.Tasks.Extensions.dll as part of your package. Finally, there's no official PCL support for Mono platforms yet, so if you do come up with a solution that works now it may change when official PCL support comes out.
If you want to attempt getting this to work, what you basically need to do is create your own DLLs with the same names as are in Microsoft.Bcl and Microsoft.Bcl.Async for use on Mono platforms. In those assemblies, put type forwards for the types that Mono already implements (which should probably be the types in the System.* DLLs), and create an implementation of your own for the other ones (the AsyncBridge source code is useful for this). This is what I did for one of my BUILD 2012 PCL demos. The code for that is here. AsyncFacades and AsyncBridge are the relevant projects.
For those stumbling into this issue when getting the Simple.oData.Client from nuget, just install the following packages from nuget:
Microsoft Bcl Async Portable
Microsoft Bcl Async
I believe I've found the problem.
Earlier I had the following line in Simple.OData.Client nuspec file:
<file src="Simple.OData.Client.Core\bin\Release\Microsoft.Threading.Tasks.Extensions.dll" target="lib\portable-net403+win8+sl5+wp8+MonoAndroid16+MonoTouch40\Microsoft.Threading.Tasks.Extensions.dll" />
This is not how it should be because Microsoft.Bcl.Async should have taken care of copying Tasks.Extensions.dll. I reported this to Microsoft and expected this to be fixed in the RTM version of Microsoft.Bcl.Async. Apparently it was not, so all NuGet packages dependent on Microsoft.Bcl.Async should still copy this file. Then it will work.
for who has the same issue I think you can downgrade
System.Threading.Tasks.Extensions 4.4.0
So I've been working on a game, and the sheer number of projects has become unmanageable. Enter NuGet.
I wanted to ensure my code would work on different devices, so I've been making these projects as Portable Class Libraries. I needed to use these on XBox, Windows, iOS, Android, and Silverlight. I created some custom custom SupportedFrameworks in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.0\Profile\Profile1\SupportedFrameworks
Specifically MonoAndroid and VSMonoTouch
I successfully turned one of these PCLs into a NuGet package, but when I try to add them to another PCL of the same profile I get this error:
Could not install package 'Framework.dll 1.0.0.0'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile1', 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 package folder was brought down and contains a folder named: portable-win+net40+MonoAndroid16+sl40+net10+wp+Xbox40 and indeed contains the requested dll. I am able to add this dll to my project manually, so I believe this may be a bug in NuGet. I investigated this online, and found the main fix was to update NuGet, because the newest version plays nicer with PCLs. I've updated, but to no avail.
Has anyone seen this before, or am I missing something obvious? Any help would be greatly appriated =)
Thanks,
Joshua
It looks like you are using ".NETFramework" for the identifier in the XML file you put in the Profile1 SupportedFrameworks folder. This was basically a hack to get iOS projects building on Windows, but with real support for that scenario you should change that identifier to MonoTouch. Then when you create the package it should use monotouch in place of net10 for the lib/portable-x+y+z folder.
Then, as #Deepak suggests, install the nightly build of NuGet. Then you should be able to install the NuGet package into your PCL project. If you do try this, please let me know whether it worked or not. :)
I am trying to compile the vNext branch of MvvmCross on a Mac to try & start doing some iOS development using PCL's & MvvMCross.
I have spent a couple of days on this now but appear to be going in circles... being somewhat new to both C# & the Mac.
I have installed MonoDevelop 3.1.1 as recently referred to on #slodge's blog.
I have updated the targets file as per this reference https://files.xamarin.com/~jeff/Microsoft.Portable.CSharp.targets
I have downloaded the vNext branch from GitHub.
I have loaded the mvvmcross_all.sln in MonoDevelop however building it using the Debug|iPhone Simulator profile gives me 3 errors.
I have not been able to work out how to fix the references errors as for example appear in CrossUI.Core, ie references to
System
System.Core
System.Net
etc
Each of these lines has an error of Assembly not available for .NetPortable 4.0 Profile1 Profile (in Mono 2.10.9)
I realise its all a moving target but its obviously possible to get it to compile.
Any suggestions as to what I may have missed would be appreciated.
TIA,
Andreas
Thanks Andreas
In the version referenced in the blog at http://slodge.blogspot.co.uk/2013/02/a-patched-monodevelop-for-pcls.html, it appears that MonoDevelop reports that CrossUI is missing its references - but it still compiles. See this screenshot from my Mac - solution explorer reports problems but 'rebuild all' on CrossUI succeeds.
If you get problems with building, please do report the build output and I'll try to help.
Note that the patched version of MonoDevelop also still has other problems - e.g. syntax highlighting and intellisense issues- MonoTouch: creating multiplatform apps using Portable Class Libraries
Alternatively, there are some iOS/Mac friendly binaries on SkyDrive - http://slodge.blogspot.co.uk/p/mvvmcross-binaries_7.html
The schedule for 'proper' support of Portable Class Libraries is aiming for a demonstrable version before Evolve (so less than 2 months away). Until then I'll personally continue to do most of my PCL work in VS, with the platform specific steps in MonoDevelop.