[Mono-devel-list] Tests for System.DirectoryServices

Boris Kirzner borisk at mainsoft.com
Sun Jun 19 11:26:55 EDT 2005

Hello Sébastien,
I've finished implementing the default ldap server feature (currently 
waiting for devlist approval) and I've also made an example for defining 
default ldap server configuration.(attached are an example file and the 
proposed patch for the case you missed my mail to the devlist).

The main point if the change is: if user does not specifies a path of an 
entry, the entry should point to default ldap server on the network 
(actually, to default naming context of the default ldap server). The 
default naming context can be retrieved from the server rootDse entry, 
so the only information we need to provide a desired functionality is a 
default ldap server host and port.

User does not have to provide his own configuration: the default 
configuration (absence of user configuration file) means "use 
localhost:389". User _can_ overwrite this with his own values using app 
config or machine config.

Is the "root" System.DirectoryServices is the best place to place an 
example and the explanation file?
Should also user configuration file reside there (since, for example, 
the tests run by default in this directory).

The second point is that DirectoryServices tests require environment 
variable of (some, not necessary the default) ldap server to run on.
So, the tests logic can possibly be: if no environment variable present, 
test prints warning message and silently passes(or, maybe, fails?). If 
someone wants to run this tests, he should define both environment 
variable and a user configuration file (or configure the host running 
these tests to act also as a default ldap server)

What do you think about this?


Sébastien Pouliot wrote:

>Hello Boris,
>>I understand that use of machine.config or app.config is far from ideal,
>>but at least it can provide us with a basic solution.
>When things gets too complicated people quit. I don't think many people are
>gonna be runned the LDAP tests but I wouldn't want to discourage anyone. So
>the easier the better ;-)
>Why don't keep the environment variable (very simple) and point it to a
>configuration file (XML or plain ASCII) ?
>That would mean:
>* that, by default, all non-network tests in System.DirectoryServices.dll
>will be executed (here I'm thinking about the few permissions tests already
>present _and_ future CAS tests);
>* it would be possible to check into SVN a configuration sample file that
>any user can copy (so it won't get in conflict with SVN) and edit;
>* it would be possible to have multiple configuration files, e.g. if you
>want to test against different LDAP servers (machine or software);
>* all configuration could be done in a single place whatever the
>runtime/version you are using.
>>Do you think there is a better way to provide a "default" behavior,
>>either at DirectoryServices or Ldap level, such that it will be easily
>>configured for each client application?
>>The trivial solution - default is "LDAP://localhost:389", does not looks
>>satisfactory and, in addition, does not provides a solution for base dsn.
>Without a valid configuration file I would simply ignore all tests
>(requiring a server). This is similar to what I'm doing for the CAS tests.
>If someone doesn't exclude them (default for "make run-test") and doesn't
>supply --security to the mono runtime, then they are all ignore (and nicely
>nunit still shows them as ignored when they aren't excluded).
>Sebastien Pouliot
>home: spouliot at videotron.ca
>blog: http://pages.infinit.net/ctech/poupou.html

Boris Kirzner
Mainsoft Corporation

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: directoryservices.diff
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050619/512adfa4/attachment.pl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: App.config
Type: text/xml
Size: 539 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050619/512adfa4/attachment.xml 

More information about the Mono-devel-list mailing list