Breaking change supporting 32-bit and 64-bit platforms, as required for all iOS projects as of February 1.
See issue #801.
Changed .Touch projects to use Xamarin.iOS.dll instead of monotouch.dll.
Changed .Touch plugin projects to use Xamarin.iOS.dll instead of mono…
Changed project types of iOS projects.
Migrated more iOS code to 64 bit.
As a user... how do you think we should introduce this change? It obviously has to happen, but it's going to break everyone's projects....
Will also ask for input from Twitter :)
I'm really not sure. How was the reaction to the breaking change introduced in 3.2?
My test of these fixes was not thorough at all. I translated an automatically generated NinjaCoder example to the Unified API and that worked (at least from Xamarin Studio). How do you go about testing changes? I'm also curious to find out how to to test if the code generated by the NuGet package still works.
Changes generally tested by:
For nuget, I believe you'll need to change the targets - I'm not sure yet, but I believe that Xamarin are trying too nuke all MonoTouch naming - to replace it with Xamarin - although the situation is changing a bit (maybe) - see answer on http://stackoverflow.com/questions/26068750/could-not-install-package-mvvmcross-portablesupport-3-2-1-at-visual-studio-2013 (this might mean we could release a package with both old and new assemblies... but doing so might be too much pain to actually build....)
Ooops - when I said "you'll need to" I meant "we'll need to" :)
I'm failing miserably with ApiExamples. I see a list but each element leads to an empty page (tested on iPhone 4 and iPhone 6 Plus). I'm guessing this is because of the bug in Xamarin.iOS for Visual Studio. If I switch to iPhoneSimulator instead of iPhone the project doesn't compile at all anymore because of supposedly missing namespaces that should all be in Xamarin.iOS.dll. I can't get it to compile at all in Xamarin Studio because of these missing namespaces, although Xamarin.iOS.dll is correctly referenced.
I'd say it's too early to do the switch to the Unified API.
I wonder if @migueldeicaza can get someone from Xam iOS team to take a look - I'm sure they don't want to hear "I'd say it's too early to do the switch to the Unified API."
... and on Visual Studio iOS support, let's log and complain about the bugs - they may not use VS as much as XS, but they do seem keen to address things like yesterday's CGRect issues and other things like https://bugzilla.xamarin.com/show_bug.cgi?id=15002 which I encountered yesterday
These are the ones I am seeing so far.
In fine .Net naming tradition, we'll aim to include this in our 3.5 release - https://github.com/MvvmCross/MvvmCross/tree/3.5 - but obviously we'll need to get stability from Xam before we switch over...
The fix from Xamarin in now in the beta channel. https://bugzilla.xamarin.com/show_bug.cgi?id=23868
So ... I really want to merge this into 3.5... which means the 3.5 will have the fragment changes and this....
Is there any way we can keep the old Classic API too? Is it case of having to build the assemblies twice and then use different nuget targets? (Not sure I can be bothered with the manual overhead of that...)
What do we have to put into the nuget packages? Anyone know?
Downloading beta updates now...
It seems we'll need the newest NuGet version 2.8.3 (https://nuget.codeplex.com/releases/view/133091) and change the platform moniker (http://developer.xamarin.com/guides/cross-platform/macios/unified/#NuGet).
Supporting both in NuGet might be possible through Bait & Switch but I don't think it will be possible with a real PCL. I also don't think it's worth the effort since everyone will have to switch by February 1. Could 3.5 be released as a pre-release NuGet package with corresponding warnings?
I've merged into the v3.5 branch... I can't get it building here... not sure why (I can build other xam.ios projects) - will keep pushing this tomorrow night :)
Thanks - this is going to rock :)
(but I might go missing when we actually push this live - there'll be a lot of confused people with this 64bit handover :))
What I'm seeing in the iOS projects is:
and if I look in references then I see:
and if I select that Xamarin.iOS reference then I end up with:
I'm a bit confused... if I create a new Unified iPhone project and it builds fine... tried creating a new copy of the repo - that works fine.... I'm a big bit confused right now...
Can you see any difference in the csproj file between the working version and mine? I remember seeing this problem for one project but it disappeared after I browsed for the right DLL once.
Nothing obvious - https://gist.github.com/slodge/82e23c8c30caed0d92d4
Heading for some zzzzz - sure it will make more sense tomorrow :)
<Import Project="$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.MonoTouch.CSharp.targets" />
probably shouldn't be in there (line 39)...
Could be :)
Looks like it's in your branch too: https://github.com/lothrop/MvvmCross/blob/64bitshizzle/CrossCore/Cirrious.CrossCore.Touch/Cirrious.CrossCore.Touch.csproj#L39
I'll give it a go later :)
That targets line does indeed seem to be the cause here...
Removing it makes my project build :)
Before I go edit all my touch csproj files (won't take long!), is this in your local copy of the repo too? Or have you already fixed it?
(I've removed them for now - but can easily discard my changes later if I've got out of date csproj files - it's just a "replace in files")
Thanks! No, I didn't fix it locally. I just saw that the correct line was in there and didn't notice the wrong one wasn't removed. Might explain some of the strange behavior I was seeing...
Got stuff building, made a few small nuspec changes (and a couple of linkerpleaseinclude fixes) and then my first couple of ios sample apps "just worked" TM
Top work :)
I'm closing this now - as 3.5 is "live" on nuget
Thanks again for the work - fabulous stuff :)
I'm also trying to talk with people at the moment about how to open up Mvx to make it easier to contribute - I'm trying to learn how to be a better githubber. Hoping to add a few more people as contributors with write access... If @Cheesebaron is ok with this (I suspect he will be!), I'd love you to be one of them :)
No objections from me 👍
I would be honored.
Thanks - moved to #841 :)
I'm going to test this with the Xamarin Alpha channel next week as suggested in http://blog.xamarin.com/unified-api-and-64-bit-support-complete/.