Pocket PC development using express editions of C# and VB

Can it be done? I have not read that either express version of C# or VB is capable of creating and deploying to mobile devices. Any pointers will be appreciated.

Why do you want to use pointers in .NET?

Seriously, I'd like to know more about portable devices too..

Anyone have word on when the new MPx220s come out? I've held out in buying a mobile phone so I could get one.

I'm affraid that you will need the full version of Visual Studio, unless there will be an express version especially for compact framework development.

Peter

If, going forward, only full versions of Visual Studio will be supported for device development, that's a serious step backwards. There's a flourishing ecosystem of device programs and libraries, but a large part of it is due to the fact that eVC and eVB were free. There was very limited uptake in the 'Windows CE Toolkit for Visual xxx' days.

Now, we're told that Compact Framework 2.0 will have a free downloadable SDK. That's great - but a low- (or zero-) cost IDE is still important.

If you live in the US then check out this site:

http://www.msmobilityroadshow.com/

I just went to the event yesterday and they had demos of all the things you could do with mobile devices.  It included the complete mobile framework and a sample of MapPoint for free.

 

Try looking up your local .Net user group and attending their meetings.  It’s a good source of information, and free food!

 

http://www.ineta.org/

They also had an annoying video about a programmer on a reality dating show they kept showing us over and over and over and over...  I just want to give a very sarcastic thanks to the people who shot it.

Mike Dimmick wrote:

Now, we're told that Compact Framework 2.0 will have a free downloadable SDK. That's great - but a low- (or zero-) cost IDE is still important.

There is one.  It's called SharpDevelop.  It's free and it's Open Source (not that I think that's a bonus but some people seem to think so).  You can write in VB.Net or C#. I'll even let you convert between the two languages and use the MSDN if you have it installed.

Blkbam wrote:

There is one.  It's called SharpDevelop.  It's free and it's Open Source (not that I think that's a bonus but some people seem to think so).  You can write in VB.Net or C#. I'll even let you convert between the two languages and use the MSDN if you have it installed.

SharpDevelop is an editor. It's a good editor, but it's still just an editor.

An IDE must have a debugger. Seriously. I'm not saying I can't work without a debugger, but I don't really like doing it. DbgClr from the .NET Framework 1.1 SDK is OK (it's a cut-down VS.NET 2003), but it doesn't do device debugging.

While

Blkbam wrote:

There is one.  It's called SharpDevelop.  It's free and it's Open Source (not that I think that's a bonus but some people seem to think so).  You can write in VB.Net or C#. I'll even let you convert between the two languages and use the MSDN if you have it installed.

SharpDevelop is an editor. It's a good editor, but it's still just an editor.

An IDE must have a debugger. Seriously. I'm not saying I can't work without a debugger, but I don't really like doing it. DbgClr from the .NET Framework 1.1 SDK is OK (it's a cut-down VS.NET 2003), but it doesn't do device debugging.

While the eVC debugger crashes a lot, it does actually work most of the time. It's taken MS a long time to realise that most Pocket PC application developers do not work in Platform Builder - the device development story has always been oriented towards the OEM, not the VAR or ISV.

Few of us have access to any debugging ports on the device, or access to debugging versions of devices. All we have is the SDK exported from Platform Builder and off-the-shelf hardware, frequently even if subcontracting to the device manufacturer. This often means that vital debugging information, that the platform is capable of producing, is permanently locked off to us. Making PDBs available for system binaries would seriously improve matters - when your program goes on holiday in the middle of a system function, it's hard to work out how you ended up in there. I can trace back a call stack manually, but it's seriously hard work.