I would run ProcMon to see why there is such delay after connecting the device. In ProcMon you can look at the Duration column to see what takes so long.
Thanks MagicAndre1981, Gov, and Larry. I watched the events in ProcMon and narrowed down the time frames. It appears that the networking stack to the device takes 3 to 7 seconds (varies with each device connect) to become usable. I setup a CMD window with "ping 169.254.2.1 -t" and could see where the device was unreachable (disconnected) then general failure (device was just connected) then ping results (device networking established) then after 3 or 4 successful pings the device's networking was generally available to other applications.
Herb should probably add to his points about how the new C++ will help developers from having to build abstraction layers. Back in the day we were building our own private libraries (mostly on a smaller scale and specific to a vertical market) then Microsoft came along and committed some dedicated folks to creating the .NET libraries on a large general purpose scale. Our not having to re-invent libraries with each job/career/vertical change is the elure of .NET (managed or not).
It would be interesting to see a cost analysis debate between the .NET and C++ camps.
Is there a way to tweak Windows Mobile Device Center (or Windows interaction with it) to tighten up the time span between when the device is recognized by Windows (audible sound to user) and when connectivity to the device is actually viable? We have seen 10 or 15 second delays between those 2 points in time and end users are confused by it.
A lightening storm is bearing down. Windows 7 has apparently downloaded installs at some point prior but not installed them. The user goes to quickly shutdown Windows prior to pulling the plug from the wall. There isn't an option to bypass installing the updates? However, "shutdown /s" does bypass?