By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,203 Members | 1,636 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,203 IT Pros & Developers. It's quick & easy.

Reading - Parsing Records From An LDAP LDIF File In .Net?

P: n/a
Reading - Parsing Records From An LDAP LDIF File In .Net?

I am in need of a .Net class that will allow for the parsing of a LDAP
LDIF file. An LDIF file is the standard format for representing LDAP
objects. I need to be able to read the records from an LDIF file into
..Net.

There exists a Perl module that will do exactly this called
Net::LDAP::LDIF but I am wanting to port my code over to .Net and
cannot find anything with similar LDIF functionality. I would like to
avoid having to write my own .Net class to read the LDIF file and
create record objects. I am sure I am not that only person that needs
to do this that is using .Net.

Does there exist a .Net class that will read LDIF files? Is there a
third party .Net class that can be purchased that can read an LDIF
file?

Any help would be appreciated,
Jean-Marie Vaneskahian
je**@vaneskahian.com
--
---------------------------
Jean-Marie Vaneskahian
je**@vaneskahian.com
---------------------------
Jun 9 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
> I am in need of a .Net class that will allow for the parsing of a LDAP
LDIF file. An LDIF file is the standard format for representing LDAP
objects. I need to be able to read the records from an LDIF file into
.Net.

There exists a Perl module that will do exactly this called
Net::LDAP::LDIF but I am wanting to port my code over to .Net and
cannot find anything with similar LDIF functionality. I would like to
avoid having to write my own .Net class to read the LDIF file and
create record objects. I am sure I am not that only person that needs
to do this that is using .Net.

Does there exist a .Net class that will read LDIF files? Is there a
third party .Net class that can be purchased that can read an LDIF
file?


Hi,

Maybe this can be of Help.
http://forge.novell.com/pipermail/ld...ay/000195.html

also this might be (or not) of help:
http://www.codeproject.com/internet/clldap.asp

alternatively, if you have a couple of bucks to spare, you can buy a perl
..NET version.
maybe there is even an open source one. I don't know.
but then you could build your Perl classes into a .NET classlib, and use
them from any other
..NET language like C# of C++/CLI.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"
Jun 9 '06 #2

P: n/a
Bruno,

Thanks for the reply. I did not see how your first two posts could
help me read an LDIF file in .Net

I have considered using the ActiveState tools to make the PERL code
available in .Net but I want to see if a "Native" solution existed
first. I guess it does not. If I having to use a wrapper to make my
Perl code .Net accessable, what is the point to moving off of Perl?
Bruno van Dooren wrote:
I am in need of a .Net class that will allow for the parsing of a LDAP
LDIF file. An LDIF file is the standard format for representing LDAP
objects. I need to be able to read the records from an LDIF file into
.Net.

There exists a Perl module that will do exactly this called
Net::LDAP::LDIF but I am wanting to port my code over to .Net and
cannot find anything with similar LDIF functionality. I would like to
avoid having to write my own .Net class to read the LDIF file and
create record objects. I am sure I am not that only person that needs
to do this that is using .Net.

Does there exist a .Net class that will read LDIF files? Is there a
third party .Net class that can be purchased that can read an LDIF
file?


Hi,

Maybe this can be of Help.
http://forge.novell.com/pipermail/ld...ay/000195.html

also this might be (or not) of help:
http://www.codeproject.com/internet/clldap.asp

alternatively, if you have a couple of bucks to spare, you can buy a perl
.NET version.
maybe there is even an open source one. I don't know.
but then you could build your Perl classes into a .NET classlib, and use
them from any other
.NET language like C# of C++/CLI.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"


Jun 9 '06 #3

P: n/a
je****@gmail.com wrote:
Bruno,

Thanks for the reply. I did not see how your first two posts could
help me read an LDIF file in .Net

I have considered using the ActiveState tools to make the PERL code
available in .Net but I want to see if a "Native" solution existed
first. I guess it does not. If I having to use a wrapper to make my
Perl code .Net accessable, what is the point to moving off of Perl?


Faster execution (compiled versus interpreted), easier access from the
language of your choice. If those don't matter to you, then perhaps there
isn't a reason.

-cd
Jun 10 '06 #4

P: n/a
Carl,

I think you are missing the point. From what it looks like, unless I want
to create the class that can parse an LDIF file and create .Net objects from
the LDAP records in the file, I would have to have some piece of my new .Net
code call a .Net wrapper around the Perl module that does this.

If my very fast compiled .Net code that has the easy access from the
language of my choice still must call the interpreted Perl module just
dressed up in a .Net wrapper, then, what is the point.

I get the point to moving to .Net, hence the reason for my post. My question
that started this was, how do I do, what I am doing in Perl today in the
better, faster, flexible .Net. And the answer I get is... well you kinda
can, but either write this brand new difficult class, or call the external
Perl module...

Does that make sense Carl?

--
---------------------------
Jean-Marie Vaneskahian
je**@vaneskahian.com
---------------------------
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:uS**************@TK2MSFTNGP02.phx.gbl...
je****@gmail.com wrote:
Bruno,

Thanks for the reply. I did not see how your first two posts could
help me read an LDIF file in .Net

I have considered using the ActiveState tools to make the PERL code
available in .Net but I want to see if a "Native" solution existed
first. I guess it does not. If I having to use a wrapper to make my
Perl code .Net accessable, what is the point to moving off of Perl?


Faster execution (compiled versus interpreted), easier access from the
language of your choice. If those don't matter to you, then perhaps there
isn't a reason.

-cd

Jun 10 '06 #5

P: n/a
Jean-Marie Vaneskahian wrote:
Carl,

I think you are missing the point. From what it looks like, unless I
want to create the class that can parse an LDIF file and create .Net
objects from the LDAP records in the file, I would have to have some
piece of my new .Net code call a .Net wrapper around the Perl module
that does this.
If my very fast compiled .Net code that has the easy access from the
language of my choice still must call the interpreted Perl module just
dressed up in a .Net wrapper, then, what is the point.

I get the point to moving to .Net, hence the reason for my post. My
question that started this was, how do I do, what I am doing in Perl
today in the better, faster, flexible .Net. And the answer I get
is... well you kinda can, but either write this brand new difficult
class, or call the external Perl module...

Does that make sense Carl?


Perfect sense.

Are you sure that the ActiveState PerlNET product - part of their Perl Dev
Kit - doesn't do what you need? It says

<quote>
Allows you to use existing .NET objects from Perl, create new .NET
components in Perl, and even inherit from and extend components written in
other languages with Perl code.
</quote>

Now, I read that (very possibly incorrectly) as including a facility to
produce a .NET assembly from Perl. Of course, if that's just a .NET wrapper
around a Perl interpreter, then it's not going to give the benefits that
you're seeking, in which case you're probably going to have to write an LDIF
parser yourself.

I did a bit of searching for LDIF grammars and didn't come up with much. If
I was going to undertake creating a parser, I'd consider using ANTLR
(www.antlr.org), which can produce parsers in a number of languages,
including C#. There are EBNF grammars for LDIF on the net, having such a
grammar gets you a long way towards writing a parser with a tool like ANTLR.

-cd
Jun 10 '06 #6

P: n/a
> Thanks for the reply. I did not see how your first two posts could
help me read an LDIF file in .Net
Well the first item is about novell having a dll that can parse the files
for you.
at least, that's what i inferred from the url.
in that case you can simply wrap the dll in .NET code.

the second link was to an article that I quickly scanned through.
I had the impression that they used LDIF files, but I was not sure.
I have considered using the ActiveState tools to make the PERL code
available in .Net but I want to see if a "Native" solution existed
first. I guess it does not. If I having to use a wrapper to make my
Perl code .Net accessable, what is the point to moving off of Perl?


I had the impression that there are perl compilers that compile to native
..NET code.
You would have to check this with the vendor of course.

If you have a reusable LDIF parser .NET class, then you can focus on
application development.
I agree that having to run perl underneath is not an elegant solution
though, but if it is native .NET, it would be ideal for you.

I have learnt that reuse is better than rewrite. And that happens to be one
of the big selling points of .NET.
You can write in whatever language you feel most comfortable with.
An older colleague of mine wrote algorithms in fortran .NET. and we could
reuse them without a hassle.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"
Jun 10 '06 #7

P: n/a
Bruno,

Thanks very much for all the help! You bring up some very good points. As
much as I would love this to be all Native .Net, perhaps as you stated,
reuse may be more pragmatic than re-write. At least I could re-write a
little at a time with no time pressure, if I had the reuse code working.

Thanks again.

--
---------------------------
Jean-Marie Vaneskahian
je**@vaneskahian.com
---------------------------
"Bruno van Dooren" <br**********************@hotmail.com> wrote in message
news:eJ**************@TK2MSFTNGP05.phx.gbl...
Thanks for the reply. I did not see how your first two posts could
help me read an LDIF file in .Net


Well the first item is about novell having a dll that can parse the files
for you.
at least, that's what i inferred from the url.
in that case you can simply wrap the dll in .NET code.

the second link was to an article that I quickly scanned through.
I had the impression that they used LDIF files, but I was not sure.
I have considered using the ActiveState tools to make the PERL code
available in .Net but I want to see if a "Native" solution existed
first. I guess it does not. If I having to use a wrapper to make my
Perl code .Net accessable, what is the point to moving off of Perl?


I had the impression that there are perl compilers that compile to native
.NET code.
You would have to check this with the vendor of course.

If you have a reusable LDIF parser .NET class, then you can focus on
application development.
I agree that having to run perl underneath is not an elegant solution
though, but if it is native .NET, it would be ideal for you.

I have learnt that reuse is better than rewrite. And that happens to be
one of the big selling points of .NET.
You can write in whatever language you feel most comfortable with.
An older colleague of mine wrote algorithms in fortran .NET. and we could
reuse them without a hassle.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

Jun 10 '06 #8

P: n/a
Carl, Thanks for the advice. The resources you listed may help greatly in
writing my own LDIF parser. I will keep you updated on how it goes. Thanks
again

--
---------------------------
Jean-Marie Vaneskahian
je**@vaneskahian.com
---------------------------
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:OU**************@TK2MSFTNGP05.phx.gbl...
Jean-Marie Vaneskahian wrote:
Carl,

I think you are missing the point. From what it looks like, unless I
want to create the class that can parse an LDIF file and create .Net
objects from the LDAP records in the file, I would have to have some
piece of my new .Net code call a .Net wrapper around the Perl module
that does this.
If my very fast compiled .Net code that has the easy access from the
language of my choice still must call the interpreted Perl module just
dressed up in a .Net wrapper, then, what is the point.

I get the point to moving to .Net, hence the reason for my post. My
question that started this was, how do I do, what I am doing in Perl
today in the better, faster, flexible .Net. And the answer I get
is... well you kinda can, but either write this brand new difficult
class, or call the external Perl module...

Does that make sense Carl?


Perfect sense.

Are you sure that the ActiveState PerlNET product - part of their Perl Dev
Kit - doesn't do what you need? It says

<quote>
Allows you to use existing .NET objects from Perl, create new .NET
components in Perl, and even inherit from and extend components written in
other languages with Perl code.
</quote>

Now, I read that (very possibly incorrectly) as including a facility to
produce a .NET assembly from Perl. Of course, if that's just a .NET
wrapper around a Perl interpreter, then it's not going to give the
benefits that you're seeking, in which case you're probably going to have
to write an LDIF parser yourself.

I did a bit of searching for LDIF grammars and didn't come up with much.
If I was going to undertake creating a parser, I'd consider using ANTLR
(www.antlr.org), which can produce parsers in a number of languages,
including C#. There are EBNF grammars for LDIF on the net, having such a
grammar gets you a long way towards writing a parser with a tool like
ANTLR.

-cd

Jun 10 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.