Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Re: Application Roots for assemblies

Reply
Thread Tools

Re: Application Roots for assemblies

 
 
Kevin Spencer
Guest
Posts: n/a
 
      07-03-2003
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
http://www.takempis.com
Some things just happen.
Everything else occurs.

"Ian Turner" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
>



 
Reply With Quote
 
 
 
 
Ian Turner
Guest
Posts: n/a
 
      07-03-2003
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
> http://www.takempis.com
> Some things just happen.
> Everything else occurs.
>
> "Ian Turner" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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
> >
> >

>
>



 
Reply With Quote
 
 
 
 
Kevin Spencer
Guest
Posts: n/a
 
      07-03-2003
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
http://www.takempis.com
Some things just happen.
Everything else occurs.

"Ian Turner" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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
> > http://www.takempis.com
> > Some things just happen.
> > Everything else occurs.
> >
> > "Ian Turner" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > 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
> > >
> > >

> >
> >

>
>



 
Reply With Quote
 
Ian Turner
Guest
Posts: n/a
 
      07-03-2003
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
> http://www.takempis.com
> Some things just happen.
> Everything else occurs.
>
> "Ian Turner" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > 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
> > > http://www.takempis.com
> > > Some things just happen.
> > > Everything else occurs.
> > >
> > > "Ian Turner" <(E-Mail Removed)> wrote in message
> > > news:(E-Mail Removed)...
> > > > 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
> > > >
> > > >
> > >
> > >

> >
> >

>
>



 
Reply With Quote
 
Kevin Spencer
Guest
Posts: n/a
 
      07-03-2003
Let me point you to a couple of MSDN articles that should help:

http://msdn.microsoft.com/library/de...assemblies.asp
http://msdn.microsoft.com/library/de...yslocation.asp

HTH,

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

"Ian Turner" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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
> > http://www.takempis.com
> > Some things just happen.
> > Everything else occurs.
> >
> > "Ian Turner" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > 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" <(E-Mail Removed)> wrote in message
> > > news:(E-Mail Removed)...
> > > > 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
> > > > http://www.takempis.com
> > > > Some things just happen.
> > > > Everything else occurs.
> > > >
> > > > "Ian Turner" <(E-Mail Removed)> wrote in message
> > > > news:(E-Mail Removed)...
> > > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>



 
Reply With Quote
 
Ian Turner
Guest
Posts: n/a
 
      07-04-2003
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Let me point you to a couple of MSDN articles that should help:
>
>

http://msdn.microsoft.com/library/de...assemblies.asp
>

http://msdn.microsoft.com/library/de...yslocation.asp
>
> HTH,
>
> Kevin Spencer
> Microsoft FrontPage MVP
> Internet Developer
> http://www.takempis.com
> Some things just happen.
> Everything else occurs.
>
> "Ian Turner" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > 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
> > > http://www.takempis.com
> > > Some things just happen.
> > > Everything else occurs.
> > >
> > > "Ian Turner" <(E-Mail Removed)> wrote in message
> > > news:(E-Mail Removed)...
> > > > 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" <(E-Mail Removed)> wrote in message
> > > > news:(E-Mail Removed)...
> > > > > 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
> > > > > http://www.takempis.com
> > > > > Some things just happen.
> > > > > Everything else occurs.
> > > > >
> > > > > "Ian Turner" <(E-Mail Removed)> wrote in message
> > > > > news:(E-Mail Removed)...
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Parsing File "roots" - break this code Ian Pilcher Java 0 01-28-2006 09:08 PM
Can't fetch the xml: roots element are missing benclissen@gmail.com ASP .Net 1 01-16-2006 05:42 AM
xsl - extracting corresponding pairs from different roots Rob Smegma XML 1 11-04-2005 12:44 PM
Single vs multiple IIS application roots Carl Johansen ASP .Net 3 06-08-2005 01:07 AM



Advertisments