how to reference assemblies from web.configs in subdirs?

[Lucas Fletcher]

Hello,

I was wondering how I can reference assemblies from web.config files
residing in subdirectories without having to create a new project for each
web.config-containing subdirectory?

I would like to use an HttpModule, but only for files in a particular
directory, so I add a web.config file containing this:
<?xml version="1.0" encoding="utf-8" ?>

<configuration>


<system.web>

<httpModules>

<add name="MessageAuthenticatorModule"
type="Din.MessageAuthenticator,localhost"/>

</httpModules>

</system.web>

</configuration>

to the proper subdirectory. The problem is that the localhost.dll cannot be
found for some reason, even though the web.config file should be part of the
main web project. I really don't want to have to register anything in the
GAC.

Another question: if I have to resort to creating another web project with
its root located at the subdirectory mentioned above, does the web.config
file still inherit values from the main web project? If not, which I suspect
is the case, then creating a separate project is not much of an alternative.

Thank you,

 

[Lucas Fletcher]

Some additional information:

The subdirectory was a web application, which explains why it was looking in
its own bin directory.

However: Now that I have removed the application at the subdir (so now it's
just a plain virtual directory) the web.config file is not being read at
all.

I also tried using the <location> tag within the root's web.config, but
still no go...

 

[John Saunders]

Lucas,

I don't really have a pointer, but it looks like you're at a point where you
could use anything...

I once complained to Microsoft about the following. I had an ASP.NET web
application installed in the root of a web site. Its web.config <add>ed an
HttpModule, AModule. I then created a subapplication. That was a problem:

1) The subapplication would not start, since it couldn't find AModule.
2) The subapplication couldn't <remove> AModule, since it wasn't actually in
the modules list

I eventually had to put a copy of AModule in the bin directory of the
subapplication so that it could <remove> it...

I had similar fun with bad <add> entries not failing. The problem was that
it hadn't gotten that far - it was failing on the <add> entry from the
parent application before it got around to realizing that the <add> in the
child application had invalid attributes.

Good Luck with this. You may have to enter an incident with Microsoft to
reach a resolution.