Upgraded to 1.3, iOS app won't compile (CS0234 on FormsApplicationDelegate base class)

I have followed the instructions for upgrading an existing XF app to 1.3, but I cannot get the iOS project to compile. When I change my AppDelegate's base class to FormsApplicationDelegate, I get the below compiler error:

Error CS0234: The type or namespace name Platform' does not exist in the namespaceXamarin.Forms'. Are you missing an assembly reference? (CS0234)

I have the Xamarin.iOS assembly in my References, as well as the XF package's references.

Posts

  • adamkempadamkemp USInsider, Developer Group Leader mod

    Make sure you updated your package in all projects.

  • AndyHopperAndyHopper USMember ✭✭

    Yep, checked that. XF 1.3.0.6292 in both the Android and iOS projects. The iOS project has Xamarin.iOS in References and Xamarin.Forms.Core and Xamarin.Forms.Xaml in Package References.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    I don't know. That error sounds like your packages aren't set up right. I would check again. I don't know what else it could be.

  • AndyHopperAndyHopper USMember ✭✭

    Hm. Well, I've removed every single package and re-added just Xamarin Forms 1.3. Still no dice; same error.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    You're not using a unified project are you?

  • AndyHopperAndyHopper USMember ✭✭

    Yep! I was following the instructions I found for migrating to 1.3, and step 1 was migrating to unified. Should I not use unified?

  • adamkempadamkemp USInsider, Developer Group Leader mod

    Which instructions? 1.3.0 doesn't support unified so if the instructions say to use unified then that's bogus. You need 1.3.1 for unified, which is in prerelease right now.

  • AndyHopperAndyHopper USMember ✭✭

    Ah, my bad: I was using the instructions at http://developer.xamarin.com/guides/cross-platform/macios/updating_ios_apps/ and totally glossed over the "unified" part. However, the reason I went looking for these instructions just reared its head as soon as I reverted: now that I'm referencing 1.3 and NOT using unified (which, incidentally, adds the Xamarin.Forms.Platform.iOS.Classic assembly), I'm getting a different compiler error on my XAML views:
    error CS0103: The name `InitializeComponent' does not exist in the current context

    (This is what made me think I screwed up migrating to 1.3)
    I have changed the build action on the XAML files to MSBuild:UpdateDesignTimeXaml to no avail.

    I just tried a brand new Shared Code (not PCL) solution, added a XAML file, upgraded to 1.3, same error.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    I have seen that error also when the namespace in the XAML doesn't match the one in the code behind. Did that possibly get messed up in the upgrade?

  • AndyHopperAndyHopper USMember ✭✭
    edited December 2014

    No, checked and double-checked. And on the brand new solution the only thing I changed was the XF package. The Android project compiled just fine. I did look at the build log, and I can see that the xaml.g.cs file is NOT being referenced in the mcs call during the iOS build. Could the .targets file be messed up for iOS where shproj projects are concerned?

    EDIT: I just nuked the obj folder under iOS and it's not getting regenerated; it definitely appears that something's not right with the .targets file.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    I got nothing. It's interesting that others seem to not be having this problem. Are you using the latest versions of Xamarin.iOS and Xamarin Studio?

  • adamkempadamkemp USInsider, Developer Group Leader mod

    I just updated my test project to 1.3.0, and I didn't have this problem. You can see my project here:

    https://github.com/TheRealAdamKemp/Xamarin.Forms-Tests

    The XAML files are set up in the project file like this:

    <EmbeddedResource Include="View\Pages\MainPage.xaml">
      <Generator>MSBuild:Compile</Generator>
    </EmbeddedResource>
    
  • MarcTorloMarcTorlo DEMember

    I had the same problem... The platform part is sperated in an a new assembly. Upgrade via nugget to 1.3.1.6294-pre1 (2014/12/24). Within this package there is a additional assembly Tamarin.Form.Platform.iOS.

    Everything is working fine then.

  • AndyHopperAndyHopper USMember ✭✭

    @adamkemp‌ I see in your repo that it's a shared PCL solution. Can you try with a shared code (shproj)? Incidentally, the reason I have to use a shproj is that Xamarin's OpenGL doesn't offer PCL support yet.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    Ok, I tried a new shared project, and I get the same error. I've never had much success using shared projects in Xamarin Studio anyway so I stay away from them. I guess in your project they worked before 1.3? Have you tried Visual Studio? I don't have easy access to it at the moment.

    I created this bug report:
    https://bugzilla.xamarin.com/show_bug.cgi?id=25627

  • AndyHopperAndyHopper USMember ✭✭

    Okey dokey; it definitely appears to be a bug in XS. Command-line builds with xbuild work properly, and VS builds work properly.

  • CraigDunnCraigDunn USXamarin Team Xamurai

    @AndyHopper, @AdamKemp, it's a known issue with XAML in Shared Projects in Xamarin Studio.

    See the yellow box warning in getting started with XAML.

    The fix is to enable MSBuild for the iOS project in Xamarin Studio (explained in the getting started with XAML doc).

    Warning: using XAML will have additional issues with Shared Projects - if you want to do any custom namespaces, you'll have to sync the namespaces and output assembly names for all the app projects (ie. you cannot have blah.iOS and blah.Droid namespaces) otherwise you won't have consistent 'resource identifiers'. Same goes for trying to load any other embedded resource (eg images).

  • AndyHopperAndyHopper USMember ✭✭

    Wahoo! Works a treat. @CraigDunn‌, you rock.

    I had really, really wanted to do this as a PCL, but since there's no PCL support for the OpenGL APIs I had the choice of either spending a lot of time spinning up my own wrapper/DependencyService or giving up and using .shproj. I'm lazy, so I chose the latter.

Sign In or Register to comment.