I've just started some MonoTouch development and I've tried, and failed, to get Moq working for my unit tests. The binary version fails because it's looking for System v2.0, which I assume is down to its Castle requirements, and building it from source crashes the compiler!
My question is has anyone gotten Moq to work on Mono (the touch part should be irrelevant, I'm not deploying it to the phone!), or had any joy with any of the other mocking frameworks? Failing that I'm back to rolling my own, which is a bit of a pain.
I'm using Moq right now with Monodevelop to test the non-Monotouch parts of a Monotouch app, and I haven't had any trouble. For the target runtime, my test project and the code under test both use Mono / .NET 3.5, and for references, it's got:
System, Version=2.0.0
nunit.core, Version=2.4.8
nunit.framework, Version=2.4.8
[code under test]
System.Core, Version=3.5.0
Moq.dll
System, nunit.core and nunit.framework are all as provided by Monodevelop.
The Moq I'm using is Moq.4.0.10827/NET35/Moq.dll.
(I haven't had any luck NUnit-testing the Monotouch parts -- I assume because when the tests are running, there's no phone or simulator, so the native code Monotouch is wrapping can't run. I've had to separate out the non-iOS-specific parts of the app and set up two separate solutions, one for real builds and one for unit testing the parts that can be unit tested. If you've gotten farther than that, let me know!)
Related
I wonder if it is possible to make an Objective-C project (no UI, no simulator is needed, hosted on Github) to be built on Travis?
Current Travis docs seems not to contain any information regarding the option to have Objective-C projects built on Travis.
But Building a C Project says that:
Travis VMs are 32 bit and currently provide
gcc 4.6
clang 3.1
core GNU build toolchain (autotools, make), cmake, scons
and that default test script is run like
./configure && make && make test
So, to rephrase the subject question:
Do any workarounds exist to make SenTestingKit test suite, that my project currently uses, behave like a C test suite, so it could be treated as such by Travis VM?
NOTE 1: Here is the list of resources, which seem to be related to the question:
Compiling Objective-C without a GUI. It claims that Both gcc and clang compile Objective-C 2.0 and that sounds very promising!
NOTE 2: I suspect that it is possible to use some testing tool other than SenTestingKit:
this tool should be easy to be run without a GUI and without xcodebuild etc: I've opened related issue for that: Is there any non-Xcode-based command line testing tool for Objective-C?. I am even thinking about writing an easy one just to be used by my project.
A few days Travis announced that they are now also supporting objetive-c projects. See Building An Objective-C Project for more info.
Update
It is even possible to make Travis launch the simulator so that you can run application tests and UI related stuff. I required a little extra work, but it's pretty straight forward. I wrote about it here.
I want to use the Novell.Directory.Ldap library in a MonoTouch and Mono For Android project.
http://www.novell.com/coolsolutions/feature/11204.html
When I compile my project in iOS simulator modus, It compiles without errors and runs correctly (in the iOS simulator).
When I compile my project in iOS device modus (to test the app with a physical device), I get this error:
Error MT2002: Failed to resolve "System.Void System.Security.Cryptography.RNGCryptoServiceProvider::.ctor(System.Byte[])" reference from "mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" (MT2002) (MyProject)
How could I solve this problem? I can't find a solution.
Should this library work for MonoTouch and Mono For Android?
Are there better LDAP solutions for Mono?
UPDATE: I just tested it with Mono For Android. This works fine.
There's three questions in there, so I splitted my answers in three. Please read all of them :-)
How could I solve this problem?
This is a general problem with a general solution to solve it.
The code you compiled is including a reference to "mscorlib, Version=1.0.5000.0
That's likely because you did not use the compiler provided with Xamarin.iOS (MonoTouch), named smcs, to build the assembly. That compiler would set the references to use the right mscorlib.dll assembly (and report anything missing in the MOBILE profile).
The fact that it can work for Xamarin.Android is that it uses the JIT (just in time compilation), so missing members won't be found before runtime (and if execution reach that code).
OTOH Xamarin.iOS uses AOT (ahead of time compilation) since JIT'ing is not allowed (by Apple) on devices. That means missing members are found at build time. In this case the (managed) linker can't find the reference and issue the MT2002 error.
So the solution is to re-build the assembly using smcs and fix, if any, build time errors. E.g. IIRC that RNGCryptoServiceProvider ctor is not available (and does nothing since seeding is not possible) and should be replaced with the default ctor.
Should this library work for MonoTouch and Mono For Android?
It should. However my personal experience with Novell.Directory.Ldap was not really good (code and design issues, e.g. threading, in particular with SSL enabled).
Also the code has not been updated for quite a while. You might be better served at looking at (managed or native) alternatives for your LDAP needs.
Are there better LDAP solutions for Mono?
Sadly I have not used any other similar library so I can't suggest alternatives (but maybe other people will be able to help).
The problem is solved.
Instead of using the dll from Novell, I downloaded all the source files of the Novell LDAP library and put them into a new library project. Then I made a reference to that library from my own Mono project.
While compiling my project and the library project, I received some errors from the library project. After solving these errors manually, it works fine for both (MonoTouch and Mono for Android).
Anyone had any luck getting Ninject to work on MonoDroid? i've tried the 2.0 and 4.0 mono builds from their website and also tried the .net versions.
With the Mono builds i'm getting a MissingMethodException in the instantiation of my StandardKernel
I am experimenting with Ninject on a combined WP7/Monotouch/Mono for Android project and Ninject works surprisingly good.
I used the latest sources, which contain a project file Ninject.WP7.csproj which seems to be outdated. It contains a lot of DefineConstants. I created new WP7/Monotouch/Mono for Android solutions with these constants and everything compiled and works!
Constants used:
SILVERLIGHT,SILVERLIGHT_40,NO_LCG,NO_ASSEMBLY_SCANNING,NO_WEB,NO_PARTIAL_TRUST,NO_SKIP_VISIBILITY,NO_EXCEPTION_SERIALIZATION,NO_DEBUG_SYMBOLS
not sure if they are all needed, but the SILVERLIGHT one is important because Monotouch/Mono for Android implement a large part of the Silverlight api.
Of course you cannot create Android Activities with Ninject. I use it mainly for constructor injection, to create .Net objects like a ViewManager, view models using a repository, etc., the usual things you do with dependency injection.
I haven't tried to get Ninject working, but I'd be very surprised if it just worked out of the box. If there's a Silverlight build of Ninject you may have more luck with that, but there are no guarantees. The "best" way to get support for it in Mono for Android would be to build the code against the Mono for Android profile as a class library.
That said, there are other options out there for doing service location in your apps. I have a blog post up here that talks about using TinyIoC and Funq for service location.
I have a friend who is was a serious Linux developer but now he's working with C# on Windows and is really loving it. I'm attracted to C# because, like Java, I should be able to compile on one system and run anywhere.
If you are developing on Windows with C#, you're using dot-Net. On Linux and MacOS, you're using Mono.
Other people have posted that Mono is pretty good, no longer a science project, and that most of the core Microsoft functionality is present. But that's not really getting at the questions that I have. I'm wondering:
How does performance of Mono on Linux/MacOS rate against Java? If I want to run fast on all three platforms with the same object code, what's my best choice?
Is it easy/possible/reasonable to use Mono with makefiles and do my development with emacs?
Is there support for code factoring in MacOS and Linux, or am I better off just biting the bullet and doing all of my development in Windows?
How well does Mono work with Subversion and the rest of the open source development stack? How about autoconf? Or is this a completely different way of doing things?
Thanks
I have been using Mono on Linux for about three years and lately have been using it on OS X. Some of the Linux stuff was pretty extensive but the OS X stuff has just been some simple ASP.NET MVC2 apps so far.
1) Performance of Mono has never been an issue for me. That is not to say that performance has not been important, it is just that the performance of Mono itself has never been an issue. A lot of what I have done is web based so I/O and database memory use have hit me before Mono has.
Historically, the biggest deficiency with Mono has been the Garbage Collector (GC). I would say that Java is better tuned in this regard. The most recent versions of Mono have made huge strides in this area but I do not have any hard numbers for you in terms of comparisons.
I am sure Mono is faster sometimes and Java sometimes but I would say that Java is faster overall.
2) You can certainly do Mono development with makefiles. Certainly the Mono team itself does. Also you can certainly use Emacs and there is a C# mode for it.
I tend to use MonoDevelop and xbuild (Mono version of msbuild) myself and do not have any experience doing C# work in Emacs. MonoDevelop is great because it is exactly the same on all platforms. Also, although I rarely use it anymore, it is nice that the project format is the same as Visual Studio and SharpDevelop.
3) MonoDevelop has pretty decent code factoring support. It is the same on Windows, Linux, and Mac. You do not need to use Windows for development (though you certainly can) but I believe you will be happier using an IDE like MonoDevelop. Even things like Intellisense become hard to live without once you are used to them. But integrated debugging, being able to drill-down into the framework, database integration, unit testing, SCM integration, and other nice tooling support all in one place is just the way to go (for me at least).
4) Mono itself does not care about version control of course. Your source files are just text and you could use anything to manage them.
That said, MonoDevelop has fantastic Subversion support built right into the IDE. I have used it extensively and it is one of the reasons I have trouble moving off MonoDevelop even on Windows. The latest version of MonoDevelop (2.6 beta) includes Git support as well.
You did not mention unit testing but MonoDevelop also has NUnit support built into the IDE. I use that on every project as well and it works excellently. The version in MonoDevelop is 2.4.8 (if memory serves) so it is not quite current but it works great.
In a nutshell, Mono works really well with Open Source tooling in general. It has always played really well for me.
Autoconf is of course used by the Mono project itself but, as a Mono developer, I have never seen a need for it. I strive to only use managed code in my projects. As such, all I need on the target platform is Mono (or .NET). Not having to worry about all that stuff is one of the primary benefits of a managed environment like Mono or Java. The runtime itself (the CLR) ensures that my app has everything it needs to function properly.
I know that MonoDevelop will build autoconf/autorun files for C/C++ projects (non-Mono) but I have not done much with it myself.
As to a previous comment, the Mono JIT is obviously tuned to the target platform. That is where platform specific performance tuning happens.
Just as a comment, I find that Mono is best viewed as a development environment in it's own right rather than a compatibility layer for Microsoft stuff. The Mono team has extended .NET in many interesting ways. Anything you develop for Mono will run on .NET but there are some .NET features not available for Mono. For example, Mono does not support Windows Presentation Foundation (WPF). You have to use Windows Forms or GTK# for cross-platform GUI work. You can also use something like Cocoa# or MonoMac on the Mac, MonoTouch on iPhone, or MonoDroid for Android. You can use Moonlight instead of Silverlight as well although I have not played with it much.
One more thing since you asked about Java. I have found a few times that the Java world had libraries that I could not find equivalents for in the .NET world. In these cases, I have had amazing luck using IKVM.NET to integrate this into my Mono apps. IKVM.NET also works on .NET but Mono and IKVM.NET are very cozy and even share some code.
So there you go, one real answer for you at least.
I've been experimenting with Rhino Mocks for unit testing my .Net Compact Framework application, and have hit a problem. I can get a basic unit test using Rhino Mocks built, but every time I run the test that has the Rhino Mocks code in it, the test fails because it can't find the Rhino Mocks assembly.
System.TypeLoadException: Could not load type 'Rhino.Mocks.MockRepository' from assembly 'Rhino.Mocks...
I've copied the rhino mocks dll to various places on the device (my app folder, and the SmartDeviceTest folder that gets created) but it still can't seem to find it.
Has anyone used rhino mocks with the compact framework and can point me in the right direction? Or failing that, can anyone suggest a mocking framework that does integrate and work with compact framework?
Thanks
Matt
My bet is that it can't find a dependency. IIRC, Rhino uses a lot of the CompilerServices and Reflection.Emit pieces which simply don't exist in the CF, so it's probably puking when trying to generate the mocks. I've not seen any mocking framework that works with the CF, and I've done quite a bit of looking (and trying to port).
I wrote a blog post on just this a few months ago:
http://elegantcode.com/2009/04/29/unit-testingmocking-on-net-cf/
Anyway, RhinoMocks, Moq, and TypeMock do not work on .netcf. Stubs from PEX (a Microsoft Research project) can work in theory, but is not there yet.
The key is to make stub classes instead of Mock classes (google search "Mocks are not Stubs")