Cross Platform Advice

  • Thread starter Thread starter Mike
  • Start date Start date
M

Mike

Hi,

I have a C# CF application that I would like to also execute on
regular Windows. It has some API calls in it so I have already #def'd
these so they will only apply when running against the CF.

With the previous version, I ended up creating new windows forms and
then cut and pasting the code from the CF version into the new forms -
this was laborious at best and then I ended up with two source bases
to fix bugs in etc. If I try to open the CF forms in a windows
project, Visual Studio complains alot about the resx files so I assume
there is CF specific tags in the form defintions.

Has anyone got any advice as to the best way to migrate a C# CF
application source base to regular Windows? Even better would be
having source code that runs on both platforms so I can just maintain
one version....

Many thanks

Mike
 
If you write it against the CF and avoid any CE-specific controls or APIs,
then the assembly will run as-is on the desktop. You can query the OS at
run-time and adjust controls/APIs and UI accordingly as well, so you could
easily maintain a single code base.

Take a look at the OpenNETCF.IO.Serial library, which runs on both.

www.opennetcf.org/library

-Chris
 
Thanks Chris, I appreciate the response. My CE application uses a web
service to communicate with its server. When I try to run it on
Windows, it complains about not being able to find System.Web.Services
and then throws a reflection error. Is there anyway I can make it find
and use the normal Windows System.Web.Services from the GAC as I
assume it does with System.Windows.Forms?

Thanks

Mike
 
Mike

A couple of issues raised here about cross platform use

1. U
Trying to maintain the exact same UI is hard work due to the different screen resolutions, but you can maintain a separate class which handles all the UI events and business logic which can be shared between the Windows app and the .NET CF app. You can pass control references into this business logic class so your form code becomes simple pass through to this shared class.

What you cannot do is compile the class to a separate assembly and expect it to work on both platforms, although they both reference System.Windows.Forms as a namespace, they are different assemblies (as you discovered with the web services).

2. Web service
I just tested creating a web service reference for a Windows Application and a Pocket PC application. I found the autogenerated code is identical (it is contained in the 'Web Reference' sub directory) - you can copy over the Windows Application version into the Pocket PC directory and it works perfectly

With source code control, it would be easy to share the source code business class library source code and the Web Reference auto generated proxy and use Get Latest to synchronise the two applications. That way you only maintain a single code base of the 'real application' code, and only the form layout files will be different. I would recommend adding new features in .NET CF, and then testing the changes on the full framework. This prevents accidentally utilising features which only the full framework supports

In general if I have radically different functionality between main framework and .NET CF I create an Interface and then implement the functionality in separate classes, one for main framework, one for .NET CF. The business logic works against the Interface and doesn't even know that anything is different.

I'm about to post some database access libraries on my web site using this principal which allow an application to use SQL CE, SQL 2000 and Microsoft MDB access transparently (after the constructor specifies the particular database being used). Drop me an e-mail if you would like to know when they go up

Regard

Liam Westley
 
Back
Top