Developing for WM5/6 and 2003

  • Thread starter Thread starter Echilon
  • Start date Start date
E

Echilon

I've developed an application in C# using the WM6 SDK, and a setup project to
go with it which generates a CAB. When I'm read to release a new version, I
build the main project, then fire up dotfuscator, then build the setup
project before running a custom script which zips everything up with the
readme and other files.

I'm fairly new to .NET CF, but how do you then build for WM2003 or 2003SE.
At the moment, I think I'd have to manually change the target platform,
rebuild and go through the whole process again. But this wouldn't really work
with my (current) mostly automated setup, as I'd have to manually rename the
files.

Is there any way to develop concurrently and have VS output to two folders -
one for WM5/6 and one for 2003/2003se?
 
Hi,

Echilon said:
I've developed an application in C# using the WM6 SDK, and a setup project
to
go with it which generates a CAB. When I'm read to release a new version,
I
build the main project, then fire up dotfuscator, then build the setup
project before running a custom script which zips everything up with the
readme and other files.

I'm fairly new to .NET CF, but how do you then build for WM2003 or 2003SE.
At the moment, I think I'd have to manually change the target platform,
rebuild and go through the whole process again. But this wouldn't really
work
with my (current) mostly automated setup, as I'd have to manually rename
the
files.

Is there any way to develop concurrently and have VS output to two
folders -
one for WM5/6 and one for 2003/2003se?
Click to expand...

i don't understand :-(
I generate my procects for Pocket PC 2003 devices and they run under 2003,
2003SE, WM5 and WM6...

Ciao
Stefan
 
Echilon said:
I've developed an application in C# using the WM6 SDK, and a setup project
to
go with it which generates a CAB. When I'm read to release a new version,
I
build the main project, then fire up dotfuscator, then build the setup
project before running a custom script which zips everything up with the
readme and other files.

I'm fairly new to .NET CF, but how do you then build for WM2003 or 2003SE.
At the moment, I think I'd have to manually change the target platform,
rebuild and go through the whole process again. But this wouldn't really
work
with my (current) mostly automated setup, as I'd have to manually rename
the
files.

Is there any way to develop concurrently and have VS output to two
folders -
one for WM5/6 and one for 2003/2003se?
Click to expand...

The different versions of Windows Mobile come pre-installed with different
versions of .NET CF. Windows Mobile 5 has .NET CF 1.1, 6 has .NET CF 2.0,
Pocket PC 2003 may not even include any .NET CF. The way I am solving this
problem is by developing an AUTORUN.EXE program in C++. Windows Mobile will
call this AUTORUN.EXE when the SD card is inserted and when Windows is
booted. AUTORUN.EXE will make sure the .NET CF 3.5 is installed on the
device. I write all of the other programs in C#/.NET CF 3.5.

The other option is to dust off the old IDE's Visual Studio 2002 & 2003 to
develop .NET 1.0/1.1 applications. You end up with many different .SLN
files and have to use many different versions of the Visual Studio IDE. You
can use Visual Studio 2008 to target 3.5 and 2.0, but you still need the
older IDEs to target .NET CF 1.0/1.1.
 
I don't fully understand what it is that you are trying to do.

That being said if you target Windows Mobile 2003 using the .Net Framework
then your application should work on the newer platforms without any need
for change. What is the reason that you want different binary versions for
each windows version?

Joel
 
I can't find the documentation for this at the time, but you can also
implement a native DLL named CESetup that contains custom actions. In your
case the custom actions would include verifying what version of the .Net
Framework were installed and taking care of installing it.
 
Usually one can run their managed code on multiple devices so long as the
framework versions are the same or have been tested and supported on future
versions of the frameworks. This is one of the major benefits of managed code
over native.

Where the differences lie is if you make use of platform specific
functionality which isn't available across different platforms. In these
cases you will need to code for them.

Apart from that you need not target multiple source versions for each
platform so long as the rules above apply.
 
Back
Top