Visual Studio For Devices : Native Development

VS 2005 SP1 is now available !

MobileDevGroup — Tue, 19 Dec 2006 02:14:00 GMT

Yes VS 2005 SP1 is now available for download. Here are some useful links I wanted to share.

VSTS patches download	http://www.microsoft.com/downloads/details.aspx?FamilyID=bb4a75ab-e2d4-4c96-b39d-37baf6b5b1dc&DisplayLang=en
Express patches download	http://www.microsoft.com/downloads/details.aspx?FamilyID=7b0b0339-613a-46e6-ab4d-080d4d4a8c4e&DisplayLang=en
TFS patches download	http://www.microsoft.com/downloads/details.aspx?FamilyID=a9ab638c-04d2-4aee-8ae8-9f00dd454ab8&DisplayLang=en
How to obtain VS 2005 SP1	http://support.microsoft.com/?kbid=929697
Hotfixes in VS 2005 SP1	http://support.microsoft.com/?kbid=918526
VS 2005 SP1 Release Notes	http://support.microsoft.com/?kbid=928957
Heath’s blog with a ton of useful SP1 related information on install issues, install times, insights into how SP1 install works, etc	http://blogs.msdn.com/heaths/archive/tags/VS+2005+SP1/default.aspx

So as a device developer what should you expect ? Some big areas we touched upon were:

We Added Development Support for Windows Embedded 6.0 platform based devices
Ability to develop using SQL Server 2005 Compact Edition
Added 15 Device Side MFC Classes to MFC for Devices
Fixed issues with eVC to VS 2005 Migration Wizard
Updated to the latest Version of Device Side Native Compilers
Included the latest versions of the Windows CE Remote Tools

and many other bug fixes both from our team as well as other teams we work with.

Thanks

Amit

Visual Studio 2005 and developing for CE based devices

MobileDevGroup — Wed, 02 Feb 2005 20:04:00 GMT

A number of people have been trying to get this information on newsgroups and other means so I thought it would be nice to put a blog to provide an answer to CE support question.

VS2005 will support both Managed (VB,C#) and Native Development (C++) for devices. We support Windows Mobile 2003 and 2003 Second Edition for Pocket PC and Smartphone out of the box and also support development and debugging on CE 5.0 based devices. For customers developing with on previous CE platforms such as 4.1 or 4.2, eVC will continue to remain the recommended development platform.

Thanks

Amit Chopra

Using Visual Studio 2005 to debug against Windows CE 5.0 devices without using ActiveSync

MobileDevGroup — Thu, 06 Jan 2005 00:35:00 GMT

We got a few posts from customers asking us on how best to debug a Windows CE 5.0 device without using Active Sync. Edward Xu, who is a Software Design Engineer/Test in our group, put together this information that will be useful in this regards.

This information only applies to the Visual Studio 2005 Beta 1 and the November CTP Drop. When newer functional device bits are available via new CTPs or the next Beta, we will update this Blog to reflect the changes.

Without the help of ActiveSync, VS 2005 does not automatically copy the connectivity binaries down to the device and hence debugging becomes problematic.

In order to use debugger on Windows CE 5.0 devices without active sync, you need to:

Step 1. Manually copy the following files down to the device

For VS 2005 Beta 1 users: Please Copy
Clientshutdown.exe
ConmanClient2.exe
ConmanSurrogate.exe
ConmanRPC_DLL.dll
TcpConnectionA.dll

From the desktop folder:
<VS Install Dir>\compactframeworksdk\connectionmanager\target\wce400\<CPU Type>, to \windows on device

For VS 2005 November CTP users: Please Copy
Clientshutdown.exe
ConmanClient2.exe
TcpConnectionA.dll

From the desktop folder:
<VS Install Dir>\compactframeworksdk\connectionmanager\target\wce400\<CPU Type>, to \windows on device
And Copy
EdbgTL.dll
From the desktop folder: <VS Install Dir>\smartdevices\debugger\target\wce400\<CPU Type>, to \windows on device

Step 2. Manually launch the conmanclient2.exe

On the device side, open the command prompt and run
Conmanclient2.exe /transport:tcpconnectiona.dll /property:port=5655 /id:Con

Step 3. Set the correct IP address

On the desktop side, open VS 2005
Tools à options à device tools à devices
Choose Windows CE 5.0 device, click on “properties”.
On the “Windows CE 5.0 device properties” dialog, click on “configure”.
On the “Configure TCP/IP” Transport dialog, choose “use specific IP address” and type in the IP address of your windows CE 5.0 device.
Click OK.

Now debugger is ready to go, and you should be able to deploy and debug program(s) running on Windows CE 5.0 device now.

'The Device Bits in December CTP are older than November CTP' - How and Why does this happen ?

MobileDevGroup — Tue, 28 Dec 2004 22:51:00 GMT

I recently responded to a customer's question with a note saying that the device bits in the December CTP are older than the November CTP. I am sure the next logical question people would have in mind would be - how and why would that happen. I'll make an attempt at explaining why even a newer CTP could have some bits which are older than the previous CTP. Before I get into the detail, take a look at this blog by the release team which explains how our build process works.

So based on that we have the Main Build and multiple VBLs under that. A set of teams in the division check code into Labs assigned to them, example my team usuallys work in VBL22. We build each lab daily and then usually once a week or so, these changes are moved to the Main Lab. Once it passes the release criteria, that code from Main is then Reverse Integrated into the rest of the labs to get all labs in sync. And this cycle continue.

The Dec CTP (looking at the help About) indicated that it from lab23 which is not the lab where my team checks code in directly. Also I noticed that the build number for this release is 041115 (Interpret YY,MM,DD). Which means that while this build has Lab23 bit which will be the most recent for the VS Team System , the bit from the Lab22 (my team's lab) could be considerably older depending on when Lab22 integrated to Main and then from Main to Lab23. Contrast that with the November CTP - it showed a build main.041202. So that should explain the How this happened.

Now to the Why part. Why does something like this happen ?. This Dec CTP release is focused on VS Team System. Once that team identifies a build in it's lab it takes then a few days to get the right set of fixes. During this phase we usually will not merge other labs so that this lab continues to be stable and in a known state. This means that team can deliver a stable build to our customers and can provide a good experience with the features they want to showcase in that build and it make the preview a lot more useful. The downside is that the other lab by virtue of the integration cycles will have older bits and this is exactly what happened in the Dec CTP.

So my suggestion to our device development community

- To try the latest feature set of VS Team Systems, sure use, the Dec CTP. If you are evaluating other features, most teams have team or individual blogs where they publish up to date known issues or build related information.

- For the latest feature in Managed Device development, continue to use the Nov CTP and the patch I put a few hours ago.

- And if you are doing Native Device development, Beta 1 release would be the best option so far. Nov CTP has a bug preventing Native Device Project from showing up and at this point and a patch for that is unlikely.

Couple of other suggestions.

When logging suggestions and defects from the Product Feedback Center, do mention the Build Number from Help About as it will help us get to the issue more quickly.

and

When installing these CTPs, I recommend a clean image of the machine. While uninstalling is getting better, a few older bits could stay behind making identification of some issues much harder for the team.

Our team would love to hear about your experiences with our tools so please feel free to use this blog, the product feedback center or the VS2005 newsgroups to send your thoughts / comments / suggestions our way. The microsoft.private.whidbey.smartdevices and microsoft.private.whidbey.smartdevices.cplusplus are the 2 most relevant newsgroups for device development for VS 2005 and you can continue to use the Microsoft public newsgroups for disucssion of VS 2003, NETCF 1.0 and eVC 4.0.

Thanks

Amit Chopra

The November CTP Drop of the Whidbey Standard SKU

MobileDevGroup — Mon, 20 Dec 2004 18:32:00 GMT

The November edition of the Whidbey CTP was made available a few days ago. For those who wanting to use this drop for developing for devices in Native C++, this particular drop did not include the templates / files needed to do device development therefore when you do a new Project for C++, you will notice that Smart Devices Node is missing. At this point there is no workaround for this issue.

Amit Chopra

What tools do I need to develop for Pocket PC and Smartphone?

MobileDevGroup — Thu, 23 Sep 2004 17:34:00 GMT

Robert's posted a nice little write-up over at the Windows Mobile blog on the different tools available for developing apps on Pocket PC and Smartphone devices. This is a bit of a tricky subject, since depending on the release of Windows Mobile you're targeting the tools can be quite different. His chart helps clear things up.

If you're looking for download locations for the various tools and SDKs you can find all of them at the Windows Mobile Developer's Center at MSDN. The Tools and Downloads page has direct links for everything Robert mentions.

Of course, the coolest tool on the block is Visual Studio 2005, which includes support for both native and managed Windows Mobile development. If you have a Beta 1 CD from one of our events and haven't given it a try yet please do! Don't forget to submit your feedback using the Product Feedback Center. If you don't have a CD kicking around, or you want the latest and greatest, and you're an MSDN Subscriber you can download the Beta 1 Refresh directly from the Visual Studio site.

[Author: Neil Enns]

Forceful home screens on Smartphone devices

MobileDevGroup — Wed, 22 Sep 2004 23:54:00 GMT

Another great question from the Smartphone developer newsgroup today. The gist of it is: "Why does the Smartphone home screen pop in front of my application every 10 minutes, and how can I stop it?"

The Smartphone Home screen pops forward after the device hasn't detected any user input for 10 minutes. (The length of time can be configured in the home screen control panel). Why? Because the device is primarily a phone, and the home screen is where you have to be to dial. The assumption is that if the user hasn't touched the phone for a while, it's likely in a pocket or a purse and the next time it's whipped out for use it'll either be to place a phone call or to run an app, both of which require the home screen.

99% of the time this works great, but there are certainly some applications where this doesn't make sense. A great example is Windows Media Player while it is playing a video. Since the user is watching the movie it would be rather rude to have the home screen pop forward.

To let the device know your app really is doing something that the user is watching, call the SHIdleTimerReset() function. The smallest timeout that can be set through the control panel is 10 seconds, so calling this every 9 seconds or so is generally a safe way to ensure the home screen doesn't pop forward. If you are going to do this, think long and hard about whether it is the right thing to do. Don't do it just because you think your app is important. Think very carefully about whether the usage scenarios for your application warrant this change to the standard Smartphone behaviour. Also, if you do call this, make sure you stop calling it when your application is no longer in the foreground, and don't override the home key so the user can still press it to get back to the home screen if they need to.

[Author: Neil Enns]

Windows Mobile Platform Migration FAQ

MobileDevGroup — Fri, 17 Sep 2004 16:58:00 GMT

MSDN has a new article up on migrating your application from one Windows Mobile version to another.

To ensure we are providing maximum information to our developer community, this article addresses a few of the most common issues and frequently asked questions (FAQs) around migrating between devices and platforms. We also provide an e-mail alias at the end of this article that you can use to report commonly-occurring issues so that we can add them to this FAQ.

This FAQ is targeted toward developers migrating from a previous version of Windows Mobile software or working to establish a single code base for all Windows Mobile-based devices.

[Author: Neil Enns]

Generating compressed CABs for Pocket PC and Smartphone

MobileDevGroup — Wed, 15 Sep 2004 19:28:00 GMT

At a partner event yesterday I was asked if it was possible to generate compressed CAB files for Smartphone and Pocket PC. It turns out the answer is yes and no.

All Smartphone devices support compressed CAB files, and cabwizsp.exe (the tool for creating Smartphone CABs) generates compressed CAB files automatically.

Pocket PC devices do not support compressed CABs. Cabwiz.exe, the tool for creating Pocket PC CABs, does not even implement creating compressed CAB files.

If you have one of the preview drops of Visual Studio 2005 you can use the new cabwiz.exe tool (this version works for both Pocket PC and Smartphone) that's in it to generate compressed CAB as well. To do so you have to add the /compress flag, as the default is to generate uncompressed CABs. These compressed cabs will work on all Smartphone devices, and Pocket PC devices running a future version of Windows Mobile (but none of the current ones).

[Author: Neil Enns]

Which CPU type for Smartphone development?

MobileDevGroup — Thu, 09 Sep 2004 22:22:00 GMT

Over in the news:microsoft.public.smartphone.developer newsgroup today someone asked a common question: "When I'm developing for Smartphone in eVC, which processor should I select?".

The answer is straightforward: ARMv4. All Pocket PC and Smartphone devices since 2000 use the ARMv4 processor. The only other processor you'd ever want to use is x86, and that's only if you're compiling your app to use in the emulator.

[Author: Neil Enns]

Secure Windows Mobile Development and Deployment

MobileDevGroup — Tue, 31 Aug 2004 16:53:00 GMT

Chung Webster's written a new article for MSDN about security and development on Windows Mobile devices:

This article looks at what development and deployment security options are available for the Pocket PC and Smartphone, including Public Key Infrastructure, Email with Exchange Server, Virtual Private Networks, WiFi, device configuration management, Pocket PC power on passwords and SQL SE security. (44 printed pages).

You can grab the article at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/wmdeploy.asp?frame=true.

[Author: Neil Enns]

Having trouble with USB connectivity?

MobileDevGroup — Tue, 31 Aug 2004 16:30:00 GMT

An update for WindowsXP was just released that resolves an issue with USB device connectivity to USB 2.0 ports. In particular this can affect Pocket PCs if you power-cycle them while they're connected.

Here's the writeup from the KB article:

When you connect a Pocket PC handheld device to a USB 2.0 hub or turn off the device and then turn it back on while the device is still connected to the USB 2.0 hub, Windows may not redetect the device. This problem may also occur with other USB devices that have pending transfers if the device is disconnected and then reconnected, or if the device is turned off and then turned back on while it is still connected to the USB 2.0 hub. After you install this item, you may have to restart your computer.

You can grab the update from http://www.microsoft.com/downloads/details.aspx?FamilyID=e8704911-1f94-47e6-8a69-26b47a29c8da&DisplayLang=en.

[Author: Neil Enns]

Programming against Windows Media Player on Smartphone and Pocket PC

MobileDevGroup — Tue, 03 Aug 2004 03:08:00 GMT

“Where are the APIs for programming Windows Media Player on Smartphone?“ This question has come up a couple of times in recent weeks on news:microsoft.public.smartphone.developer.

Unfortunately the answer is “there isn't one at the moment”. None of the Windows Mobile 2002 or 2003 devices, either Pocket PC or Smartphone, have a media player client that has an API.

The only workaround at the moment is to post window messages to the media player application. This is completely unsupported and is guaranteed to break in the next version of the client. However, if you really want to do it, Peter Foot has a writeup of how it works and a sample class library over at opennetcf.org. The library is in managed code, but if you're a native developer you should be able to look at the P/Invoke calls to figure out how to do the same thing in C++.

[Author: Neil Enns]

Localizing native Smartphone applications

MobileDevGroup — Fri, 23 Jul 2004 16:59:00 GMT

Over in the news:microsoft.public.smartphone.developer newsgroup someone asked how to localize the application name that appears in the program list. This is really not an obvious thing to do, and I know we documented it once but I couldn't find the information.

A fellow named Riki, however, posted back with a great writeup on his site about how to do this, as well as additional information on how to support multiple languages in your Smartphone application. It's a good reference to keep handy.

[Author: Neil Enns]

What's new in Smart Device Projects in Visual Studio 2005

MobileDevGroup — Thu, 22 Jul 2004 00:40:00 GMT

We've recently posted an overview of “What's New” in VS 2005 for device developers... check it out at: http://msdn.microsoft.com/vs2005/teams/devices/whatsnew/default.aspx

[Author: Ori Amiga]