Are there any mocking frameworks for Windows Phone 7 or do I need to create fakes manually?
I've not found any on google, and although I found Moq listed on WP7 resources page, I couldn't get it working.
There are no Mocking frameworks that support WP7 and I suspect there will never be any until WP7 supports Reflection.Emit.
On the .net framework there are many options that exist for the creation of a mocking framework (Profiler API, CodeDem, Refleciton.Emit, et al). The majority of these techniques won't work on Silverlight itself as it's missing quite a lot of the BCL/CLR. All existing Silverlight mocking frameworks use Reflection.Emit. WP7 does not support Reflection.Emit and thus no Silverlight mocking framework will work on WP7.
Because of that reason, I personally test WP7 assemblies on the Silverlight runtime. It's far from optimal (it sucks), but it's the best that can be done under the circumstances.
One could theoretically build a Mocking framework that uses Post-Build MSIL weaving that should work on WP7, but it's yet to be done.
If you'd like WP7 to support Reflection.Emit consider voting on this uservoice issue: WP7 should support Reflection.Emit for Mocking frameworks
EDIT 2/12/2011: Refleciton.Emit is supported on Mango. Hooray! Reflection.Emit based Mocking frameworks should just work.
I'm not aware of any currently available.
This article by David Gadd shows an example of testing on the phone using manually created fake objects and may be a useful resource.
I just got TypeMock Isolator, and it works with Windows Phone 7 (sortof).
You need to create a default Visual Studio Test project, and you will get an error saying that your Windows Phone 7 project can not be referenced, but for some reason the Mocks and Tests work perfectly.
Anyway, I'm really happy with the mocks it is able to create.
Any mocking framework that supports Silverlight 3 should work with Windows Phone 7. You may need to use a previous version of the framework to "dumb it down" to Silverlight 3, though.
Just wanted to notice some information that I found on MSDN:
http://msdn.microsoft.com/en-us/library/hh821022.aspx#sec2
The mock classes were manually developed as it is not possible to use a mocking framework on the Windows Phone platform. Mocking frameworks require the ability to emit Microsoft intermediate language (MSIL) code, which is not currently possible on the Windows Phone platform
Related
We are developing a cross platform mobile application using Xamarin. I have noticed there are different ways of structuring your code using Shared code or PCL/.net standard.
I attempted to use .net standard and what i have found is that it doesn't include all the libraries such as using ado stuff , datatable/datasets using system.data. Or using system.net for example. Other functions have less overloads and seems that its a stripped version of .net to work across platforms. Is there any way to add this functionality or use a broader range of .net?
You are correct - .Net Standard and .Net Core are stripped down versions of the full .Net framework. They contain only features that can be used on all platforms (Mac, Android, iOS, Linux, Windows, etc.)
The full .Net framework only needs to work on Windows, so there are additional things that you can do based on the fact that there is less complexity in implementing and that the code base is more mature (cross platform is still pretty new by C# standards). To the best of my memory, System.Net should work if you have your references correct, but System.Data will not (or at least direct database access is not possible)
You can regain some functionality through NuGet packages, but it won't be the same as using WinForms or something like that...
My best advice would be to program against an API. You can use a web server that runs on the normal (full) .Net framework, and does all the heavy lifting using all the .Net features that you are accustomed to. Your Xamarin app would send and receive data from the API and basically provide a mobile front end for whatever you are doing. This approach makes sense for most apps anyway, and is generally what you would be doing anyway if you used Swift and Java to create separate iOS and Android apps.
I have a Windows Phone 8 (XAML/C#) app and a Windows 8(HTML/JS) app.
Both apps are very different visually, but they consume the same data from a JSON API service.
What would be the best approach (in time, effort and money) to engage the development of these apps?
Example:
Can i write only once the "JSON API/Connection/Serialization/DataModels/etc Code" and reuse it in both apps? (Maybe doing a portable class library)
Should i use XAML for both apps? Javascript for both apps? to unify code languages?
Should i have only one solution containing a WP8 project, and a W8 project?
What's with Windows RT? Will my Windwos 8 app run in WindowsRT?
What I think is :-
You should make portable class library (PCL) for your common code. As
PCLs are made for code reuse.
I think it is not much crucial what are using for UI, it is up to
you in which are good.
You should not make same project for Windows 8 and WP8. don't mix up
things here because there are lot of differences between these two
platforms. In the end you don't want that if you changes for Windows
8 and your WP8 apps stops working. don't create trouble for
yourself.
What I think for Win-RT is - it is at the edge of death. So don't
worry about them too much. In future everything going to be unified.
Note- I strongly recommend you PCLs for your common code. If something is not supported in PCLs then create separate projects(may be specific to platforms) and reuse them.
Hope it help you somehow.
Can I use "System.Windows.Controls" and "Microsoft.Xna.Framework.Graphics" assemblies in the same project without facing any problems from Microsoft Certification process.
Because it has been said that, "4.2.5:-The application must not call any APIs in the Microsoft.Xna.Framework.Game assembly or the Microsoft.Xna.Framework.Graphics assembly when using any methods from the System.Windows.Controls namespace."
No you can't .The requirements are explicit. Can you describe what kind of functionality are you looking for? Do you want to combine Silverlight and the XNA Framework in a Windows Phone Application? Do you want to use one of its types?
The Marketplace certification requirements are explicit - and they were correct for applications which target WP7.0. However they aren't accurate for WP7.1 "Mango" apps.
For WP7.1 it is possible to write a combined SL/XNA application. There is even a code sample for this on MSDN (see link).
Our VB6 application uses a 3rd party control (PowerTCP from Dart) for SSL3 connectivity. However, this doesn't seem to work on Windows 7 - and I have not found any useful information on what I can do to make it work.
Is there a VB6.0 compatible control that will work on Win 7 for SSL3 communication?
Unfortunately, I can only suggest a workaround, not a solution: If you do not find a suitable ActiveX control for your VB6 application, you might consider migrating the communication part of your application to VB.NET.
This has the following advantages:
Calling .net code from VB6 is not hard.
The .net Framework has a built-in SSLStream class, which might already do what you want, so you're not dependent on a third-party component.
Since VB6 IDE support ended in April 2008, you will probably want to migrate your application to VB.NET sooner or later anyway. Therefore, migrating parts of your application now might be a better investment of your time than familiarizing yourself with a new third-party ActiveX control.
It has the following disadvantages:
One more layer in your application: Your VB6 code can call the .net code, but not vice-versa.
You need to familiarize yourself with the .net-COM interop stuff (it's not difficult, but it's something that needs to be done).
Your deployment process becomes more complicated, since you require the .net Framework to be installed on your customer's machines and you need to register your .net library as a COM component (so that your VB6 application can access it).
Dart still support the ActiveX control - why not ask them for help directly and post a question on their support forum?
Apologies in advance if you've already tried this.
I wanted to know what i shouldn't do in code that will prevent my C# app from running on mac.
In general you shouldn't use anything from the Microsoft.* namespaces, no PInvoke (DllImport in C#) and UI might be problematic as well.
Further information on Mono compatibility is contained in the Mono Guide Porting Winforms Applications. Existing applications can be checked for compatibility using the Migration Analyzer tool.
UPDATE: PInvoke actually works in Mono, but if you want to have it working cross-platform you must provide a native shared library with the same interface for each platform (i.e. Win API most likely will not work).
Mono's Application Portability guide is a good reference.
In addition to divo's recommendations, I would recommend the Mono Migration Analyzer (MoMA) tool: "The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono"
Also, I would keep an eye on Miguel de Icaza's blog, and the Mono Project website.
In his presentation for the Boston.NET Users Group this month, he showed a preview of a Visual Studio plugin that launches your app on Mono using a VM! This lets you test compatibility during the development process.
I believe their goal was to release it at TechEd 2009, so look for an update over the next month or so.
You will, at the very least, want to try and avoid using Windows Forms, since that is just a paper-thin layer on top of the Windows native UI.
Mono emulates it somewhat with help from WINE, but I wouldn't trust that.
Mono did this a while ago but the effort was abandoned. See WinForms on Mono for more information. Thanks jpobst.
Try using GTK# or Qt# (although I'm not too sure the latter one actually exists) for cross platform support. You might also consider using Java with SWT or even Swing instead of C#, but that will probably not be an option you're willing to consider.
Using anything related to P/Invoke is probably also a bad idea, since that invokes native code which will probably not be portable (unless you write it yourself, then you can choose to make it portable).
I'm not sure if it is possible with mono, but WIN32 API calls will definitly not work ;)