This project is read-only.

Is PhoneBookPath really required with a EntryName?

Oct 10, 2011 at 2:31 PM
Edited Oct 10, 2011 at 2:31 PM
Looking at the source code of the InternalDial method of DotRas.RasDialer, it seems to
throw an exception if you use an EntryName without a phonebook entry, yet all it seems
to do the phoneBookPath is pass it to two methods which accept a null reference to mean 
the 'default phone book'. 

Is it possible to remove this restriction or failing that is there a method of 
determining what the default phoneBook path is?

Oct 10, 2011 at 10:30 PM

In an earlier version of the product the PhoneBookPath wasn't a required value to be passed to the RasDialer class, however that changed as of the 1.1 release. The reason behind it was a nasty little problem that was extremely hard to diagnose because the path wasn't being passed in. All you'd get back is a non-descriptive exception about the path being null.

The underlying Win32 API that the RasDialer uses allows for the path to be null and it determines which phonebook you wanted to use. However since phonebooks are file-based, and you can have the same entry in both phonebooks, it may not choose the entry you actually wanted to dial. When using the component, people assume the component couldn't figure out where the entry was even though it was really Windows under the hood that was choosing the wrong phonebook.

That's why it's required even though it doesn't appear to be doing anything, it's for the plumbing within Windows and making sure any problems while dialing entries can be identified and fixed.

As for your question regarding determining the phonebook path, there are actually two phonebooks in use by Windows... the one used by the current user, and the one used by all users. Which one you want to use depends on your application since using the all users phonebook may have security implications depending on the target machine configuration. If you're just looking for an easy way to determine the path of the "default" phonebooks, you can use the RasPhoneBook.GetPhoneBookPath method that's been exposed. It follows the Win32 guidelines for determining the path of the "default" phonebooks.

- Jeff

Oct 11, 2011 at 8:56 PM

Thanks for the reply.

My problem is that I need to use existing connections and it appears that on some computers these are stored in the current users phonebook and in others it is in the all users phonebook, so I really have to try both.

I thought, since they are just files, it would be quickest to open each phonebook and look for the name, but it appears the PhoneBook.Open command can take a long time (13 seconds) , whereas attempting to dial with the wrong phonebook takes less than half a second to return an exception, so I am thinking of catching the RasException and looking for errorCode 623 and switching phonebooks in that case.

Can you think of a better/faster way of doing this?




Oct 11, 2011 at 8:56 PM
Edited Oct 11, 2011 at 8:58 PM




Oct 12, 2011 at 12:10 AM

The closest thing I can think of in the 1.2 SDK that can check whether an entry already exists without actually opening it is the RasEntryNameValidator class, but that won't work for what you're looking to do with it. I'd have to make something, which after looking at the code it wouldn't be hard to do.

Oct 12, 2011 at 12:45 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Oct 12, 2011 at 12:49 AM

Yeah I didn't think it'd take that long to get the request filled, I just checked in the changes to do this as of changeset 84518.

bool exists = RasPhoneBook.Exists("Test Entry Name", @"C:\YourPhoneBook.pbk");

You'll have to download the source and compile it yourself to use the new feature, or wait till the next release to make use of it. That method will very quickly allow you to determine whether an entry exists within a phone book without requiring you to open the phone book and iterate through the entries.

Oct 12, 2011 at 7:39 PM

It takes less than a tenth of a second to perform the check, so thank you very much.

Oct 13, 2011 at 3:24 AM

Not a problem, glad it worked out.

- Jeff