Running unit tests on Mac with MvvmCross? - xamarin.ios

Finally, I've got my Mac and tried to re-compile and run my project with Xamarin.iOs
Since, PCL is not yet supported, I had to create a copies of .sln and .csproj and replace references to MvvmCross-Binaries and it works (thanks, Stuart). I hope Xamarin will give more elegant solution soon.
However, I couldn't compile and run unit tests on Mac - Mono 4.5 is not installed, and I didn't find Cirrious.MvvmCross.Test.Core.dll.
So, is it possible to run this kind of unit tests on Mac or we just test it in Windows platform?

I believe you should be able to build and run the 4.5 assemblies using the latest mono 3 releases. Further, the latest mono alpha release should also contain 'proper' support for portable class libraries.
Alternatively, if you'd rather work off of stable xam releases, then you'll probably need to create your own version of a .net4 core test assembly - there are only 2 small classes so this shouldn't be too hard to do - https://github.com/slodge/MvvmCross/tree/v3/Cirrious/Test/Cirrious.MvvmCross.Test.Core
As well as on mac testing, I know some people also use the on device test runners - especially for iOS where the aot compilation makes on-device testing important.

Related

Can I use Visual Studio to develop Mono applications?

I have developed a .NET 4.5 application using WinForms. I want my application to run not only on Windows, but also on Linux, so I decided to port it to Mono.
However, I can't find any information on how to use Visual Studio for Mono. I don't want to switch to MonoDevelop, since VS provides much of the functionality I want and I am already familiar with it.
There apparently used to be something called Mono Tools for Visual Studio, which David Lively insists works on current VS editions, but I don't want to run an extension that was deprecated 3 years ago. I don't even know where to download the extension - it redirects to Xamarin, and Xamarin seems like not what I want because while it mentions VS integration, it forces me to install a bunch of Android and Java SDKs (why?).
As far as I can see, .NET and Mono code looks fairly similar, and there are 3 main concerns:
Making VS use the Mono compiler instead of the C# compiler, so I can tell if non-Windows users can compile my source, and also get notified about missing libraries
Making IntelliSense suggest only Mono-supported things
Making the "Run" command run the application using Mono, not .NET, so I can test it correctly
Is there really no easy way of accomplishing these?
Note: I want to develop Windows and Linux desktop apps, with a WinForms GUI or equivalent only. I am not interested in mobile.
In general, you can just target .NET 4.5 and compile with Visual Studio and the resulting assembly works as-is on Mono (assuming you don't use platform-specific stuff via p/invoke, etc).
Mono's WinForms support isn't perfect though (and nobody actively works on it), so you still need to test by running the app directly on Mono. Missing APIs aren't usually the problem, it's more that the Mono implementation has different behavior/bugs.
Another alternative to WinForms might be Xwt.

install and execute cocos2dx project on windows 8

I am making a small basic game for multiple mobile platforms using cocos 2dx, I have done all the coding in c++ on xcode and the project is running fine for iOS and android.
But when porting to windows phone I am facing a lot of hurdles. I am using cocos2dx 2.1.3 on visual studio 2012 express on 64 bit windows 8 with windows 8 phone SDK.
Firstly i don't get templates for cocos2dx, then there is no option to run the project in simulator or device. I have been digging the internet alot for this and have found some tutorials but all of them have one or the other limitations.
can somebody guide me with this windows part or a totally new way round to implement cocos2dx on multiple platforms ?
Option 1
Your going to have to open a new Direct3D project and follow the directions from here
Option 2
There are a couple build scripts available to generate project types for all platforms in python, as seen here.
(this works with 2.1.2 or later)
Option 3
Newer versions of cocos2d-x have build scripts for all platforms that come with the latest git repos. Not sure if there are a lot of breaking changes but the newer versions also have build projects.(build-win32.bat)
About the project template.
The templates for windows 8, at least in the last stable release I looked at a month ago, still had some issues with the html in the c++ project wizard but, the current development branch should have that fixed for the windows 8 visual studio browser. If they haven't then there are a couple of html meta-data tags that will need to be removed as they are depreciated in order for the project wizard to be usable.

How to get MvvmCross vNext to compile on Mac using MonoDevelop

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.

Building on Windows XP, when development is on VS2012?

We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)

Testing using an upgraded VS2012 solution, but building in VS2010

So I've downloaded VS2012 RTM and upgraded my Coded UI test projects to the VS2012 versions.
The reason I have done this is because I was having issues with VS2010 Coded UI tools due to partial support of IE9.
So I ran the tests from my developer machine both locally and remotely (making use of the new Visual Studio agent tools), and the tests worked successfully. Presumably, the reason my tests now work is that VS2012 upgraded them so that they now work with IE9, right?
So - this is my problem. I want to automate these tests, by launching them from our build machine - but our build machine still runs on VS2010, and for the time-being this is not going to change.
So I checked in my new VS2012 Coded UI test solution into TFS and queued a new build - so the build machine built my solution. And the build was successful. All good there.
So, next I created a new test case in Microsoft Test Manager and associated with the ordered test list in my new solution. Then I launched the tests (using the existing VS2010 test controller) on my remote test environment (which has the existing VS2010 test agent tools).
But the tests failed - the same issues that affected my tests with the VS2010 Coded UI tests (due to lack of full support for IE9)
Why did they fail?
Do I need the new VS 2012 agent tools for my test controller and agents? Must I build my solution in VS2012?
Ideally, I don't want to have to install VS2012 RTM on my build machine - I want to do the minimum possible to get my tests working and automating.
Is there a way around this?
Your coded ui tests reference assemblies that come with VS installation or your agent's installation (the assemblies defininf the WpfControl, Mouse, Keyboard, Playback and other classes).
So if you run it on a build/test machine with older versions of the dll's the same issues are going to stay, the tests will not start using the newer fixed assemblies thatt were shipped with VS2012.
As a temporary workaround you can check what dll's you reference and make sure that the build process puts them in the same directory with your tests assembly. That way the lookup for them will find the in the current directory without using the /path and finding them in the VS installation directory.

Resources