Application Roots for assemblies

[Kevin Spencer]

As long as the "facades" virtual directory is configured as an Application
that's the way ASP.Net works. You can always remove the Application
configuration for that directory in order to make it a part of the root
Application.

HTH,

Kevin Spencer
Microsoft FrontPage MVP
Internet Developer
[url]http://www.takempis.com[/url]
Some things just happen.
Everything else occurs.

"Ian Turner" <iturner100@hotmail.com> wrote in message
news:uO31UIXQDHA.3020@TK2MSFTNGP10.phx.gbl...

> Hi,
>
> I've come across a strange problem to do with locating and loading
> assemblies when deployed into Web Applications.
>
> I'll describe the scenario:
> We have a web solution that contains a traditional Web Application project
> with ASPX etc., another Web Application project with a number of Web
> Services that act as facades into our business services layer, and a

number

> of private assemblies are used by each application (though not the same
> assemblies - i.e. no shared assemblies are required).
>
> When developing locally, both web projects are given virtual directories
> underneath the default website within IIS (though their physical paths are
> not located in wwwroot). In this configuration, each individual

application

> is able to correctly locate and load their assemblies. Some assemblies are
> loaded dynamically (as part of factory patterns etc.)
>
> When we deploy this solution to staging servers, we do not use the same
> configuration of virtual directories. Instead, the aspx application is
> installed directly into the root of a new website in IIS (i.e. it doesn't
> get it's own virtual directory). The facades application, however, IS
> installed in a virtual directory of the IIS website.
>
> The strange thing with this configuration is that when trying to locate
> assemblies, the CLR is looking in the facades virtual directory - even

when

> the assemblies that it is looking for belong to the aspx application.
>
> Sticking the assemblies into the GAC provides a workaround - but should

not

> be necessary.
>
> Has anybody seen similar behaviour before and / or have any suggestions?
>
> Cheers
> Ian
>
>

[Ian Turner]

Hi Kevin,

Thanks for that. So, I guess the question is: does the aspx application (if
it does not get its own virtual directory) also get configured as an
application? I'm assuming that it doesn't - as that would explain the
behaviour.

Cheers
Ian

"Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
news:ehXrgmXQDHA.2460@TK2MSFTNGP10.phx.gbl...

> As long as the "facades" virtual directory is configured as an Application
> that's the way ASP.Net works. You can always remove the Application
> configuration for that directory in order to make it a part of the root
> Application.
>
> HTH,
>
> Kevin Spencer
> Microsoft FrontPage MVP
> Internet Developer
> [url]http://www.takempis.com[/url]
> Some things just happen.
> Everything else occurs.
>
> "Ian Turner" <iturner100@hotmail.com> wrote in message
> news:uO31UIXQDHA.3020@TK2MSFTNGP10.phx.gbl...

> > Hi,
> >
> > I've come across a strange problem to do with locating and loading
> > assemblies when deployed into Web Applications.
> >
> > I'll describe the scenario:
> > We have a web solution that contains a traditional Web Application

project

> > with ASPX etc., another Web Application project with a number of Web
> > Services that act as facades into our business services layer, and a

> number

> > of private assemblies are used by each application (though not the same
> > assemblies - i.e. no shared assemblies are required).
> >
> > When developing locally, both web projects are given virtual directories
> > underneath the default website within IIS (though their physical paths

are

> > not located in wwwroot). In this configuration, each individual

> application

> > is able to correctly locate and load their assemblies. Some assemblies

are

> > loaded dynamically (as part of factory patterns etc.)
> >
> > When we deploy this solution to staging servers, we do not use the same
> > configuration of virtual directories. Instead, the aspx application is
> > installed directly into the root of a new website in IIS (i.e. it

doesn't

> > get it's own virtual directory). The facades application, however, IS
> > installed in a virtual directory of the IIS website.
> >
> > The strange thing with this configuration is that when trying to locate
> > assemblies, the CLR is looking in the facades virtual directory - even

> when

> > the assemblies that it is looking for belong to the aspx application.
> >
> > Sticking the assemblies into the GAC provides a workaround - but should

> not

> > be necessary.
> >
> > Has anybody seen similar behaviour before and / or have any suggestions?
> >
> > Cheers
> > Ian
> >
> >

>
>

[Kevin Spencer]

I don't understand what you're asking. In IIS, and Application Domain is
determined by several factors:

1. The root folder is configured in IIS as an Application.
2. All folders under the root folder, unless they are configured as
Applications, are part of the root Application.

The actual Application is not a set of folders; it is a memory space, in
which all the executable code and data for that Application resides. The
folders simply define what files are to be loaded into that Application
space when used.

HTH,

Kevin Spencer
Microsoft FrontPage MVP
Internet Developer
[url]http://www.takempis.com[/url]
Some things just happen.
Everything else occurs.

"Ian Turner" <iturner100@hotmail.com> wrote in message
news:uAvGavXQDHA.2320@TK2MSFTNGP12.phx.gbl...

> Hi Kevin,
>
> Thanks for that. So, I guess the question is: does the aspx application

(if

> it does not get its own virtual directory) also get configured as an
> application? I'm assuming that it doesn't - as that would explain the
> behaviour.
>
> Cheers
> Ian
>
> "Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
> news:ehXrgmXQDHA.2460@TK2MSFTNGP10.phx.gbl...

> > As long as the "facades" virtual directory is configured as an

Application

> > that's the way ASP.Net works. You can always remove the Application
> > configuration for that directory in order to make it a part of the root
> > Application.
> >
> > HTH,
> >
> > Kevin Spencer
> > Microsoft FrontPage MVP
> > Internet Developer
> > [url]http://www.takempis.com[/url]
> > Some things just happen.
> > Everything else occurs.
> >
> > "Ian Turner" <iturner100@hotmail.com> wrote in message
> > news:uO31UIXQDHA.3020@TK2MSFTNGP10.phx.gbl...

> > > Hi,
> > >
> > > I've come across a strange problem to do with locating and loading
> > > assemblies when deployed into Web Applications.
> > >
> > > I'll describe the scenario:
> > > We have a web solution that contains a traditional Web Application

> project

> > > with ASPX etc., another Web Application project with a number of Web
> > > Services that act as facades into our business services layer, and a

> > number

> > > of private assemblies are used by each application (though not the

same

> > > assemblies - i.e. no shared assemblies are required).
> > >
> > > When developing locally, both web projects are given virtual

directories

> > > underneath the default website within IIS (though their physical paths

> are

> > > not located in wwwroot). In this configuration, each individual

> > application

> > > is able to correctly locate and load their assemblies. Some assemblies

> are

> > > loaded dynamically (as part of factory patterns etc.)
> > >
> > > When we deploy this solution to staging servers, we do not use the

same

> > > configuration of virtual directories. Instead, the aspx application is
> > > installed directly into the root of a new website in IIS (i.e. it

> doesn't

> > > get it's own virtual directory). The facades application, however, IS
> > > installed in a virtual directory of the IIS website.
> > >
> > > The strange thing with this configuration is that when trying to

locate

> > > assemblies, the CLR is looking in the facades virtual directory - even

> > when

> > > the assemblies that it is looking for belong to the aspx application.
> > >
> > > Sticking the assemblies into the GAC provides a workaround - but

should

> > not

> > > be necessary.
> > >
> > > Has anybody seen similar behaviour before and / or have any

suggestions?

> > >
> > > Cheers
> > > Ian
> > >
> > >

> >
> >

>
>

[Ian Turner]

Clearly. So, in that case, why would the root of a website not be able to
correctly locate assemblies that are deployed in its bin directory. The
actual error that the CLR throws out is that the assembly or dependency can
not be found. Looking at the fusion logs identified that it was looking in
the bin directory of the facades virtual directory.

This is what I am asking.

Ian

"Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
news:uBMxraYQDHA.2476@TK2MSFTNGP10.phx.gbl...

> I don't understand what you're asking. In IIS, and Application Domain is
> determined by several factors:
>
> 1. The root folder is configured in IIS as an Application.
> 2. All folders under the root folder, unless they are configured as
> Applications, are part of the root Application.
>
> The actual Application is not a set of folders; it is a memory space, in
> which all the executable code and data for that Application resides. The
> folders simply define what files are to be loaded into that Application
> space when used.
>
> HTH,
>
> Kevin Spencer
> Microsoft FrontPage MVP
> Internet Developer
> [url]http://www.takempis.com[/url]
> Some things just happen.
> Everything else occurs.
>
> "Ian Turner" <iturner100@hotmail.com> wrote in message
> news:uAvGavXQDHA.2320@TK2MSFTNGP12.phx.gbl...

> > Hi Kevin,
> >
> > Thanks for that. So, I guess the question is: does the aspx application

> (if

> > it does not get its own virtual directory) also get configured as an
> > application? I'm assuming that it doesn't - as that would explain the
> > behaviour.
> >
> > Cheers
> > Ian
> >
> > "Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
> > news:ehXrgmXQDHA.2460@TK2MSFTNGP10.phx.gbl...

> > > As long as the "facades" virtual directory is configured as an

> Application

> > > that's the way ASP.Net works. You can always remove the Application
> > > configuration for that directory in order to make it a part of the

root

> > > Application.
> > >
> > > HTH,
> > >
> > > Kevin Spencer
> > > Microsoft FrontPage MVP
> > > Internet Developer
> > > [url]http://www.takempis.com[/url]
> > > Some things just happen.
> > > Everything else occurs.
> > >
> > > "Ian Turner" <iturner100@hotmail.com> wrote in message
> > > news:uO31UIXQDHA.3020@TK2MSFTNGP10.phx.gbl...
> > > > Hi,
> > > >
> > > > I've come across a strange problem to do with locating and loading
> > > > assemblies when deployed into Web Applications.
> > > >
> > > > I'll describe the scenario:
> > > > We have a web solution that contains a traditional Web Application

> > project

> > > > with ASPX etc., another Web Application project with a number of Web
> > > > Services that act as facades into our business services layer, and a
> > > number
> > > > of private assemblies are used by each application (though not the

> same

> > > > assemblies - i.e. no shared assemblies are required).
> > > >
> > > > When developing locally, both web projects are given virtual

> directories

> > > > underneath the default website within IIS (though their physical

paths

> > are

> > > > not located in wwwroot). In this configuration, each individual
> > > application
> > > > is able to correctly locate and load their assemblies. Some

assemblies

> > are

> > > > loaded dynamically (as part of factory patterns etc.)
> > > >
> > > > When we deploy this solution to staging servers, we do not use the

> same

> > > > configuration of virtual directories. Instead, the aspx application

is

> > > > installed directly into the root of a new website in IIS (i.e. it

> > doesn't

> > > > get it's own virtual directory). The facades application, however,

IS

> > > > installed in a virtual directory of the IIS website.
> > > >
> > > > The strange thing with this configuration is that when trying to

> locate

> > > > assemblies, the CLR is looking in the facades virtual directory -

even

> > > when
> > > > the assemblies that it is looking for belong to the aspx

application.

> > > >
> > > > Sticking the assemblies into the GAC provides a workaround - but

> should

> > > not
> > > > be necessary.
> > > >
> > > > Has anybody seen similar behaviour before and / or have any

> suggestions?

> > > >
> > > > Cheers
> > > > Ian
> > > >
> > > >
> > >
> > >

> >
> >

>
>

[Kevin Spencer]

Let me point you to a couple of MSDN articles that should help:

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhowruntimelocatesassemblies.asp[/url]
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconspecifyingassemblyslocation.asp[/url]

HTH,

Kevin Spencer
Microsoft FrontPage MVP
Internet Developer
[url]http://www.takempis.com[/url]
Some things just happen.
Everything else occurs.

"Ian Turner" <iturner100@hotmail.com> wrote in message
news:ObFe0sYQDHA.2228@tk2msftngp13.phx.gbl...

> Clearly. So, in that case, why would the root of a website not be able to
> correctly locate assemblies that are deployed in its bin directory. The
> actual error that the CLR throws out is that the assembly or dependency

can

> not be found. Looking at the fusion logs identified that it was looking in
> the bin directory of the facades virtual directory.
>
> This is what I am asking.
>
> Ian
>
> "Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
> news:uBMxraYQDHA.2476@TK2MSFTNGP10.phx.gbl...

> > I don't understand what you're asking. In IIS, and Application Domain is
> > determined by several factors:
> >
> > 1. The root folder is configured in IIS as an Application.
> > 2. All folders under the root folder, unless they are configured as
> > Applications, are part of the root Application.
> >
> > The actual Application is not a set of folders; it is a memory space, in
> > which all the executable code and data for that Application resides. The
> > folders simply define what files are to be loaded into that Application
> > space when used.
> >
> > HTH,
> >
> > Kevin Spencer
> > Microsoft FrontPage MVP
> > Internet Developer
> > [url]http://www.takempis.com[/url]
> > Some things just happen.
> > Everything else occurs.
> >
> > "Ian Turner" <iturner100@hotmail.com> wrote in message
> > news:uAvGavXQDHA.2320@TK2MSFTNGP12.phx.gbl...

> > > Hi Kevin,
> > >
> > > Thanks for that. So, I guess the question is: does the aspx

application

> > (if

> > > it does not get its own virtual directory) also get configured as an
> > > application? I'm assuming that it doesn't - as that would explain the
> > > behaviour.
> > >
> > > Cheers
> > > Ian
> > >
> > > "Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
> > > news:ehXrgmXQDHA.2460@TK2MSFTNGP10.phx.gbl...
> > > > As long as the "facades" virtual directory is configured as an

> > Application

> > > > that's the way ASP.Net works. You can always remove the Application
> > > > configuration for that directory in order to make it a part of the

> root

> > > > Application.
> > > >
> > > > HTH,
> > > >
> > > > Kevin Spencer
> > > > Microsoft FrontPage MVP
> > > > Internet Developer
> > > > [url]http://www.takempis.com[/url]
> > > > Some things just happen.
> > > > Everything else occurs.
> > > >
> > > > "Ian Turner" <iturner100@hotmail.com> wrote in message
> > > > news:uO31UIXQDHA.3020@TK2MSFTNGP10.phx.gbl...
> > > > > Hi,
> > > > >
> > > > > I've come across a strange problem to do with locating and loading
> > > > > assemblies when deployed into Web Applications.
> > > > >
> > > > > I'll describe the scenario:
> > > > > We have a web solution that contains a traditional Web Application
> > > project
> > > > > with ASPX etc., another Web Application project with a number of

Web

> > > > > Services that act as facades into our business services layer, and

a

> > > > number
> > > > > of private assemblies are used by each application (though not the

> > same

> > > > > assemblies - i.e. no shared assemblies are required).
> > > > >
> > > > > When developing locally, both web projects are given virtual

> > directories

> > > > > underneath the default website within IIS (though their physical

> paths

> > > are
> > > > > not located in wwwroot). In this configuration, each individual
> > > > application
> > > > > is able to correctly locate and load their assemblies. Some

> assemblies

> > > are
> > > > > loaded dynamically (as part of factory patterns etc.)
> > > > >
> > > > > When we deploy this solution to staging servers, we do not use the

> > same

> > > > > configuration of virtual directories. Instead, the aspx

application

> is

> > > > > installed directly into the root of a new website in IIS (i.e. it
> > > doesn't
> > > > > get it's own virtual directory). The facades application, however,

> IS

> > > > > installed in a virtual directory of the IIS website.
> > > > >
> > > > > The strange thing with this configuration is that when trying to

> > locate

> > > > > assemblies, the CLR is looking in the facades virtual directory -

> even

> > > > when
> > > > > the assemblies that it is looking for belong to the aspx

> application.

> > > > >
> > > > > Sticking the assemblies into the GAC provides a workaround - but

> > should

> > > > not
> > > > > be necessary.
> > > > >
> > > > > Has anybody seen similar behaviour before and / or have any

> > suggestions?

> > > > >
> > > > > Cheers
> > > > > Ian
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>

[Ian Turner]

I've already read both of them and, even using the <assemblyBinding> and
<codebase> overrides in web.config doesn't help.

I'm actually at TechEd Europe at the moment and I've asked a couple of the
experts on the same subject and so far am getting the same suggestions that
you are giving.

I've got a pretty busy week or two ahead but after that I'll try and put a
simple solution together that repeats the problem and post it here. So keep
an eye on this thread.

Thanks for all your suggestions so far. This one has got me pretty stumped.

Cheers
Ian

"Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
news:OKDrCvZQDHA.2480@tk2msftngp13.phx.gbl...

> Let me point you to a couple of MSDN articles that should help:
>
>

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhowruntimelocatesassemblies.asp[/url]

>

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconspecifyingassemblyslocation.asp[/url]

>
> HTH,
>
> Kevin Spencer
> Microsoft FrontPage MVP
> Internet Developer
> [url]http://www.takempis.com[/url]
> Some things just happen.
> Everything else occurs.
>
> "Ian Turner" <iturner100@hotmail.com> wrote in message
> news:ObFe0sYQDHA.2228@tk2msftngp13.phx.gbl...

> > Clearly. So, in that case, why would the root of a website not be able

to

> > correctly locate assemblies that are deployed in its bin directory. The
> > actual error that the CLR throws out is that the assembly or dependency

> can

> > not be found. Looking at the fusion logs identified that it was looking

in

> > the bin directory of the facades virtual directory.
> >
> > This is what I am asking.
> >
> > Ian
> >
> > "Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
> > news:uBMxraYQDHA.2476@TK2MSFTNGP10.phx.gbl...

> > > I don't understand what you're asking. In IIS, and Application Domain

is

> > > determined by several factors:
> > >
> > > 1. The root folder is configured in IIS as an Application.
> > > 2. All folders under the root folder, unless they are configured as
> > > Applications, are part of the root Application.
> > >
> > > The actual Application is not a set of folders; it is a memory space,

in

> > > which all the executable code and data for that Application resides.

The

> > > folders simply define what files are to be loaded into that

Application

> > > space when used.
> > >
> > > HTH,
> > >
> > > Kevin Spencer
> > > Microsoft FrontPage MVP
> > > Internet Developer
> > > [url]http://www.takempis.com[/url]
> > > Some things just happen.
> > > Everything else occurs.
> > >
> > > "Ian Turner" <iturner100@hotmail.com> wrote in message
> > > news:uAvGavXQDHA.2320@TK2MSFTNGP12.phx.gbl...
> > > > Hi Kevin,
> > > >
> > > > Thanks for that. So, I guess the question is: does the aspx

> application

> > > (if
> > > > it does not get its own virtual directory) also get configured as an
> > > > application? I'm assuming that it doesn't - as that would explain

the

> > > > behaviour.
> > > >
> > > > Cheers
> > > > Ian
> > > >
> > > > "Kevin Spencer" <kevin@SPAMMERSSUCKtakempis.com> wrote in message
> > > > news:ehXrgmXQDHA.2460@TK2MSFTNGP10.phx.gbl...
> > > > > As long as the "facades" virtual directory is configured as an
> > > Application
> > > > > that's the way ASP.Net works. You can always remove the

Application

> > > > > configuration for that directory in order to make it a part of the

> > root

> > > > > Application.
> > > > >
> > > > > HTH,
> > > > >
> > > > > Kevin Spencer
> > > > > Microsoft FrontPage MVP
> > > > > Internet Developer
> > > > > [url]http://www.takempis.com[/url]
> > > > > Some things just happen.
> > > > > Everything else occurs.
> > > > >
> > > > > "Ian Turner" <iturner100@hotmail.com> wrote in message
> > > > > news:uO31UIXQDHA.3020@TK2MSFTNGP10.phx.gbl...
> > > > > > Hi,
> > > > > >
> > > > > > I've come across a strange problem to do with locating and

loading

> > > > > > assemblies when deployed into Web Applications.
> > > > > >
> > > > > > I'll describe the scenario:
> > > > > > We have a web solution that contains a traditional Web

Application

> > > > project
> > > > > > with ASPX etc., another Web Application project with a number of

> Web

> > > > > > Services that act as facades into our business services layer,

and

> a

> > > > > number
> > > > > > of private assemblies are used by each application (though not

the

> > > same
> > > > > > assemblies - i.e. no shared assemblies are required).
> > > > > >
> > > > > > When developing locally, both web projects are given virtual
> > > directories
> > > > > > underneath the default website within IIS (though their physical

> > paths

> > > > are
> > > > > > not located in wwwroot). In this configuration, each individual
> > > > > application
> > > > > > is able to correctly locate and load their assemblies. Some

> > assemblies

> > > > are
> > > > > > loaded dynamically (as part of factory patterns etc.)
> > > > > >
> > > > > > When we deploy this solution to staging servers, we do not use

the

> > > same
> > > > > > configuration of virtual directories. Instead, the aspx

> application

> > is

> > > > > > installed directly into the root of a new website in IIS (i.e.

it

> > > > doesn't
> > > > > > get it's own virtual directory). The facades application,

however,

> > IS

> > > > > > installed in a virtual directory of the IIS website.
> > > > > >
> > > > > > The strange thing with this configuration is that when trying to
> > > locate
> > > > > > assemblies, the CLR is looking in the facades virtual

directory -

> > even

> > > > > when
> > > > > > the assemblies that it is looking for belong to the aspx

> > application.

> > > > > >
> > > > > > Sticking the assemblies into the GAC provides a workaround - but
> > > should
> > > > > not
> > > > > > be necessary.
> > > > > >
> > > > > > Has anybody seen similar behaviour before and / or have any
> > > suggestions?
> > > > > >
> > > > > > Cheers
> > > > > > Ian
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>