Namespace or type '...' for the Imports '...' cannot be found

[Stephen Cochran]

I'm getting the following error in my ASP.NET application:

Namespace or type 'DirectoryServices' for the Imports
'System.DirectoryServices' cannot be found.

I have added the System.DirectoryServices.dll to my References, and am
including the line "<%@ Import Namespace="System.DirectoryServices" %>" at
the top of the page. I have checked my global assembly cache (both on the
development and the target machine) and both have the correct version of the
assembly (1.0.5000.0).

The server is Windows Server 2003, with all of the latest patches and
updates installed.

I've searched the net and newsgroups and have not yet found any solution to
this one beyond the ususal "Add a reference to System.DirectoryServices.dll"
to your project". Obviously, something deeper is happening here.

Anyone have a clue as to why this isn't working? Thanks!

 

[J Quick]

Despite the frustration of running into a problem such as this one, it some
consolation to know that others are sharing the experience. I feel your
pain. See my message "Type not defined error"

 

[Chris R. Timmons]

I'm getting the following error in my ASP.NET application:

Namespace or type 'DirectoryServices' for the Imports
'System.DirectoryServices' cannot be found.

I have added the System.DirectoryServices.dll to my References,
and am including the line "<%@ Import
Namespace="System.DirectoryServices" %>" at the top of the page.
I have checked my global assembly cache (both on the development
and the target machine) and both have the correct version of the
assembly (1.0.5000.0).

The server is Windows Server 2003, with all of the latest
patches and updates installed.

I've searched the net and newsgroups and have not yet found any
solution to this one beyond the ususal "Add a reference to
System.DirectoryServices.dll" to your project". Obviously,
something deeper is happening here.

Anyone have a clue as to why this isn't working? Thanks!

Stephen,

Just a shot in the dark, but do you have ADSI installed on your
Win2003 machine? From the .Net help file:

<quote>
Both the DirectoryEntry component and DirectorySearcher component
require that you have the ADSI SDK or ADSI runtime installed on your
computer in order to create applications with their functionality.
ADSI 2.5 is installed by default with Windows 2000 or Windows XP.
</quote>

(The help file page is mute regarding Win 2003.)

<url to help file page>
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vbcon/html/vbconintroductiontoadsiobjectsinvisualstudio.asp

or

http://tinyurl.com/55g33
</url to help file page>

Do you have the QuickStart tutorials that came with the .Net SDK
installed on the Win2003 machine? If so, those tutorials include two
Active Directory apps. Do those compile and run OK?
(http://localhost/quickstart/howto/)

Using Lutz Roeder's Reflector utility
(http://www.aisto.com/roeder/dotnet/), it appears that
System.DirectoryServices.dll has a dependency on activeds.dll. If
that dll isn't present (or maybe a permissions problem?), it may be
possible that's what's causing the error you are encountering.

 

[Stephen Cochran]

Stephen,

Just a shot in the dark, but do you have ADSI installed on your
Win2003 machine? From the .Net help file:

<snip>

Thanks for the reply. Now for a descent into the truly bizarre. A second
ASPX page, based upon the _exact same code_, works. The only difference is
that the first page was built with inline code, and the second was
code-behind. Otherwise, there were no differences (beyond the necessary
inline/code-behind fundamentals) in the code. The original page still fails.

I give up. ASP.NET wins. I'm in the middle of a crash course (learning by
doing), and there seems to be no rhyme or reason to what will work in
code-behind, but not in inline, or vice-versa (works inline, but not in
code-behind). I've been developing for a couple of decades now, and have
been working with VB since 1.0, and likewise ASP since it first came out.
This transition is kicking my butt.

The fun part is when pages built using nothing but designer generated code
fail, but the same operations work inline. Obviously (to me, at least),
there remains a way to go towards perfecting ("workabling"?) ASP.NET.

 

[Chris R. Timmons]

Thanks for the reply. Now for a descent into the truly bizarre.
A second ASPX page, based upon the _exact same code_, works. The
only difference is that the first page was built with inline
code, and the second was code-behind. Otherwise, there were no
differences (beyond the necessary inline/code-behind
fundamentals) in the code. The original page still fails.

I give up. ASP.NET wins. I'm in the middle of a crash course
(learning by doing), and there seems to be no rhyme or reason to
what will work in code-behind, but not in inline, or vice-versa
(works inline, but not in code-behind). I've been developing for
a couple of decades now, and have been working with VB since
1.0, and likewise ASP since it first came out. This transition
is kicking my butt.

Stephen,

I think this indicates a permissions problem with the ASPNET account.
The code-behind files that work are compiled under a normal user
account. The inline .aspx files that don't work are compiled under
the ASPNET account when the page is accessed.

I'm not very familiar with Active Directory (AD), but (here's another
shot in the dark ) it may be that the ASPNET account needs to be
given some kind of permission to access AD.

The fun part is when pages built using nothing but designer
generated code fail, but the same operations work inline.
Obviously (to me, at least), there remains a way to go towards
perfecting ("workabling"?) ASP.NET.

Yeah, I went through the same thing. Since I have VS.Net, I just
decided to do everything using the code-behind model, and concentrate
my effort on learning all its quirks.