This project is read-only.

Possible bug?

Feb 20, 2013 at 4:37 PM
I'm looking at an odd bug: unfortunately we're still using DotRas 1.1, but if this has been fixed in later iterations I'll look into upgrading.

I'm trying to dynamically create a phonebook entry where the device it needs is not necessarily present - driver or otherwise. If a driver is needed, can someone tell me which name Create needs? Target is Windows 7 (but the problem seems to happen on Vista; I've used almost identical code on XP, which is why I'm a bit confused).

Meanwhile, here's an extracted version of the code (originally it was part of a custom action in an installer, but this extracted version reproduces the problem exactly):
        string name = DeviceNameBox.Text;
        string pbkEntry = PBKEntryBox.Text;
            MessageBox.Show(String.Format("Name: {0} -------- pbkEntry: {1}", name, pbkEntry));
            Assembly DotRas = Assembly.Load("DotRas,Version=1.1.3488.31105,Culture=neutral,PublicKeyToken=b378f04384b7892a"); // we do this because of the original CA code mentioned above
            MessageBox.Show("Place 4a");
            RasPhoneBook pbk = new RasPhoneBook();
            MessageBox.Show("Place 4b");
            MessageBox.Show("Place 4c");
            MessageBox.Show(String.Format("Name is : {0}", name));
            RasDevice dev = RasDevice.Create(name, "Modem");            // Better hope all are actually this type
            MessageBox.Show(String.Format("Place 4d; was {0}", dev.Name));
            RasEntry ent = RasEntry.CreateDialUpEntry(pbkEntry, "*99*1#", dev);     
            MessageBox.Show("Place 4e");
            MessageBox.Show(String.Format("ent.Name was {0}", ent.Name));
            MessageBox.Show("Place 4f");
            ent.NetworkProtocols = RasNetworkProtocols.IP;
            MessageBox.Show("Place 4g");
            ent.Options = RasEntryOptions.IPHeaderCompression | RasEntryOptions.RemoteDefaultGateway;
            MessageBox.Show("Place 4h");
            MessageBox.Show("Place 4i");
            bool val = ent.Update();
            if (val == false)
                MessageBox.Show("Update returned false");
                MessageBox.Show("Update was true anyway.");
        catch (Exception ex)
            MessageBox.Show(String.Format ("Place 4: {0}.", ex.ToString()));
            MessageBox.Show(String.Format ("name: {0} pbkEntry: {1}", name, pbkEntry));
If I run this against an empty system phonebook, it crashes with an ArgumentException (after position 4h mentioned):

System.ArgumentException: 'name' cannot be a null reference or empty string.
Parameter name: name
at DotRas.ThrowHelper.ThrowArgumentException(String argumentName, String resource, Object args)
at DotRas.RasDevice.Create(String name, String deviceType)
at DotRas.RasHelper.GetEntryProperties(RasPhoneBook phoneBook, String entryName)
at DotRas.RasHelper.SetEntryProperties(RasPhoneBook phoneBook, RasEntry value)
at DotRas.RasEntryCollection.InsertItem(Int32 index, RasEntry item)
at DotRas.Design.RasCollection`1.Add(TObject item)
at DeviceSupportDllInstallationLibrary.DialerApi.CreatePhoneBookEntry(Session session, String name, String pbkEntry).

The above stacktrace is from the original CA, but is identical in the place in the POC code above.

Oddly, the entry gets created anyway! Or sort of - I wonder if it is correct, since then pbk.Open() crashes with a similar message if I try it again without deleting the contents of the phonebook. (I.e., point 4b of the above code). All the code which outputs the names and such as it goes along are correct. However, if one examines the entry which results, the only reference to "name" I can find is "FriendlyName" in the device section. This is empty, which I assume is the problem. Any thoughts on why this is happening (I have a feeling it is the device not being actually installed, but I have to chase that down a bit more.) But meanwhile, any advice or comments are welcome.
Feb 20, 2013 at 6:35 PM
I've figured out what is going on. This is actually connected to my perennial problem with device "fall back" it seems.

If there are no "modem" type devices enabled (but not necessarily present, as far as I can tell) the above occurs. (And the Windows 7 UI seemingly shows an X on the list.) If any are enabled, a phonebook entry is created, but the name of the device assigned to it in "top" position in the phonebook entry seems to be arbitrary (i.e. all enabled and present seem to appear), and does not respect the RasDevice.Name property at all; I can pass in seemingly anything there and the entry gets created, as they always have, with all enabled modems. Grumble. I guess I really do need that update thing - I hope it works and reorders like it should.

Now I have to delete all these spurious entries ...
Feb 21, 2013 at 4:49 AM

I do remember that there was a bug reported in 1.1 which appears to be what you're experiencing and was resolved for the 1.2 release. Also, there were a number of breaking changes going from 1.1 to 1.2, so you might want to look at the release notes in the help file if you plan to upgrade. It should help ease the upgrade process if you're going to move forward with it.

Here's the work item I found if you're interested in reviewing it:

If ya got any questions, just let me know.
Feb 22, 2013 at 7:27 PM
Ok, this seems to do the trick. Now I have to decide whether just my installer's CA should be migrated, or the rest of the code.

I see from my experience and the notes that some bitflags have been made into distinct properties. That's a bit cleaner (and I say that as a former C programmer!)
Feb 22, 2013 at 7:28 PM
And that horrible pun was unintentional!
Feb 23, 2013 at 4:34 PM
Yeah, the flags thing was the biggest change I'd say in that release. So many people were having problems working with the bit flags (overwriting all the options just to turn one on, not being able to turn them off correctly) that I decided to just make them all booleans. Haven't had anyone reporting problems with options on entries since, and it's been nearly 2 years since I made the change!