MvvmCross / MvvmCross-Forms

Support for Xamarin.Forms on MvvmCross: The .NET MVVM framework for cross-platform solutions, including Xamarin.iOS, Xamarin.Android, Windows and Mac.
http://mvvmcross.com
6 stars 2 forks source link

All projects compile, all but WindowStore run without errors #9

Closed PeterBurke closed 9 years ago

PeterBurke commented 9 years ago

INTERIM PULL REQUEST

This is an interim PR to enable reviewers to see progress and preview.

There will be more PR's to follow, and these will incorporate this PR. I suggest waiting for the last PR before we update the Master. But with Git you can clone this Repo with the PR to your desktop and review.

The current PR addresses an issue where WindowsPhone would not run due to a missing reference, and compile errors in the WindowStore project. Before addressing these compile errors I needed to satisfy myself that the WindowStore projects were linked via NuGet to the correct MvvMCross packages. I was puzzled by the fact that MvvMCross had a WindowStore NuSpec but NuGet decided to link to the WindowsCommon NuSpec. NuGet makes its choices based on the ProjectTypeGuid in the CSPROJ file. I verified that this was correct as per Xamarin documentation. NuGet decided to load MvvmCrossLibraries via the MvvmCross.HotTuna.MvvmCrossLibraries.3.0.1.nuspec a fragment of which follows

<!-- store -->
<file src="..\bin\Release\Mvx\WindowsStore\Cirrious.MvvmCross.WindowsStore.dll" target="lib\netcore45\Cirrious.MvvmCross.WindowsStore.dll" />
<file src="..\bin\Release\Mvx\WindowsStore\Cirrious.MvvmCross.WindowsStore.pdb" target="lib\netcore45\Cirrious.MvvmCross.WindowsStore.pdb" />

<!-- windows common -->
<file src="..\bin\Release\Mvx\WindowsCommon\Cirrious.MvvmCross.WindowsCommon.dll" target="lib\win81\Cirrious.MvvmCross.WindowsCommon.dll" />
<file src="..\bin\Release\Mvx\WindowsCommon\Cirrious.MvvmCross.WindowsCommon.pdb" target="lib\win81\Cirrious.MvvmCross.WindowsCommon.pdb" />
<file src="..\bin\Release\Mvx\WindowsCommon\Cirrious.MvvmCross.WindowsCommon.dll" target="lib\wpa81\Cirrious.MvvmCross.WindowsCommon.dll" />
<file src="..\bin\Release\Mvx\WindowsCommon\Cirrious.MvvmCross.WindowsCommon.pdb" target="lib\wpa81\Cirrious.MvvmCross.WindowsCommon.pdb" />

So NuGet given the ProjectTypeGuid decides to load from:win81 and not from netcore45 This might still be an issue because right now the Samples have no View to load.

In the next PR I will to add a C# view to each sample, plus test projects and prove that they run.

This should be followed by a PR that restructures and renames things. I would like to see the samples using NuGet referencing to the FormsPresenters rather than project referencing.

martijn00 commented 9 years ago

Thanks for this PR. Looks good mostly!

PeterBurke commented 9 years ago

WindowStore sample throws an exception very early during testing.

As per Xamarin developer notes, you put the following line of code into the App.xaml.cs:

Xamarin.Forms.Forms.Init(e).

I wrote an example 6 weeks ago and it works fine. But for some reason in this project it throws an E_FAIL COM Exception while attempting to update the resource dictionary. Others have had this error and Xamarin were unable to help. The situation is very opaque i.e. we cannot see past the COM call and E_FAIL is just 1 bit of information.

So what I will do is introduce another Sample called Sample.W81 based on my sample from 6 weeks ago that gets past this point, then gradually add the extras. This may of course ultimately mean removing the Sample.WindowStore project, but we can deal with the naming issues later.

PeterBurke commented 9 years ago

Now at the point where Windows.w81 Sample (replacing WindowsStore sample) runs all the way through without exceptions. I created a FirstPage to match the FirstViewModel and it locates it. I am getting a blank screen though. Also need to test the FirstPage in all the other targets.

I might issue a progressive PR later today. However if you can wait a day, I will also attempt to down convert from VS2015 to VS2013. Hopefully there will be no change to c# files or csproj files. Currently I have not had a situation where loading an MvvMCross solution has triggered an upgrade, so the VS version issue might be simply a case of downgrading the version numbers in the SLN file before issuing the PR.

martijn00 commented 9 years ago

Yes we can wait a bit. I think we just want this to be stable before the release of 4.0.0