I've never found it to be "unreliable" ("undocumented" is different),
although there may be advantages in how roaming is triggered in later
versions of the OS which haven't made it back to earlier ones. That is,
you may find that, when you're running a CE5-based OS, your card may
roam more-willingly or faster, giving you better connectivity. I don't
think that there are any broken things in CE4.2, at this point, though
(I just went through a test cycle on our 4.2 device that included
testing three different wireless cards over half a dozen different
encryption types and authentication types, including Summit, by the way,
with no problems).
Yes, you can run 2003 and 2005 on the same PC. I do that all the time
and there is no interference that I've ever seen, as long as you install
them in that order. I'm not sure that the other order will cause you
problems, but I'm pretty cautious about that.
No, no problems with having multiple OpenNETCF versions installed.
That's pretty much just source code, or assemblies, depending on whether
you have the source version or the binary version. I think that the
assembly names of the network things may have changed between 1.4 and
2.1 and a number of methods that were deprecated in 1.4 are, I believe,
gone now, but the new versions are much better. I'm not involved in
maintaining the code as much as I was in the 1.x days. It's worth
installing the 2.x version and just seeing how much of an impact the
compiler will tell you the change is going to have.
Paul T.
Hello Paul
It is looking likely that I will have to upgrade to 2005 sooner than I
wanted to as the device manufacturers are telling me that WZC in CE.NET
4.2 is unreliable and I have to use CE5, for which I need VS.NET 2005.
I think that I can install 2003 and 2005 on the same PC, but is there
any problem in installing OpenNETCF 1.4 and 2.1 on the same PC? Are
there likely to be many coding changes (to my code) between 1.4 and
2.1 - the application uses several of the OpenNETCF calls and I don't
want to start on this job until I have more time if it is likely to
cause a major rewrite. Thanks.
Andy Baker
"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message What version of the driver do you have? The first tab in the SCU
program will tell you that.
Yes, 1.4 is the latest .NET CF 1.0 version. Unfortunately, it's not
the latest version, generally. the 2.0 SDF would, I think, have later
code. Since you are getting an error in some situations, debug that.
Make sure, also, that all return values are tested. It's probably
just a matter of this card not working precisely the same as the other
card; that's not at all unusual, but there are still some things that
you can do to assure that it's not you.
Paul T.
Hi Paul
Yes, I have got the Summit card configured to use WZC. I am using
OpenNETCF which worked reliably in the past using the Broadcom card.
I am using version 1.4, which I thought was the latest version that
worked with Visual Studio 2003. Is this still the case? (We hope to
be upgrading to 2005/2008 shortly, but now is not a good time!). I
have the Summit driver from Unitech (the device manufacturer), but as
Summit themselves limit access to the drivers etc to their OEM
partners, I have no access to any others. I will contact Unitech to
see if there are other drivers available. Thanks for the advice.
Andy Baker
"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no
spam DOT com> wrote in message
So you've got the Summit card configured such that it uses WZC, NOT
the Summit SCU program to do the configuration, right? I don't see
any way to do what you're talking about unless that's the case, but
thought I should make sure. You have the latest driver from Summit?
They seem to release a new one about once a month. And you're
controlling the WZC stuff using your own wrapper classes or
OpenNETCF? If OpenNETCF, you'll want to get the latest version of
that, also. As we've gone from totally undocumented WZC APIs to at
least some documentation, there have been some bugs revealed. I
don't think that they would cause this, but it's worthwhile to try
to verify that.
Paul T.
I have been doing some more testing this morning and I am finding
that sometimes when switching between networks I am getting the
error message "DeviceIOControl - IOCTL_NDIS_BIND_ADAPTER". I'm sure
this must have something to do with it, although it fails whether I
get the error message or not.
Andy Baker
We have recently been supplied with some devices that have a
different radio card in them to the one we have been using all
along and I have a problem connecting to our LAN. From a cold
reboot, it sets up the WiFi card (Summit) and connects to the LAN
successfully, and I can ping the WAP and every PC on the LAN. I
then install our in-house written application software and execute
it, which basically involves logging into an SQL server database
and transferring data for a day's work. The software automatically
disconnects from the LAN and connects in AdHoc mode to a wireless
printer. However, I then find that the next time I come to use the
LAN, although the device reports that it is connected, I cannot
ping either the WAP or the LAN and cannot transfer any more data.
The WAP reports the device as assocated but the IP address is
0.0.0.0, which suggests that it has not connected properly.
Nothing except a cold reboot and complete reinstall cured the
problem. I can however, still connect in AdHoc mode to the
printer. This never used to happen with our previous cards
(Broadcom) . The software is written in VB.NET/C# 2003 and uses
OpenNetCF calls to do the network switching between LAN and
printer. It looks to me if the software is leaving the card in
such a state that it will no longer connect properly, but I am at
a loss as to what could be causing it. Any suggestions would be
appreciated. Thanks in advance.
Andy Baker
