Re: Application Roots for assemblies

Discussion in 'ASP .Net' started by Kevin Spencer, Jul 3, 2003.

  1. 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" <> wrote in message
    news:...
    > 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, Jul 3, 2003
    #1
    1. Advertising

  2. Kevin Spencer

    Ian Turner Guest

    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" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    > > 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, Jul 3, 2003
    #2
    1. Advertising

  3. 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" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    > > 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" <> wrote in message
    > > news:...
    > > > 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, Jul 3, 2003
    #3
  4. Kevin Spencer

    Ian Turner Guest

    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" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    > > 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" <> wrote in message
    > > news:...
    > > > 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" <> wrote in message
    > > > news:...
    > > > > 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, Jul 3, 2003
    #4
  5. Let me point you to a couple of MSDN articles that should help:

    http://msdn.microsoft.com/library/d...ide/html/cpconhowruntimelocatesassemblies.asp
    http://msdn.microsoft.com/library/d...ide/html/cpconspecifyingassemblyslocation.asp

    HTH,

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

    "Ian Turner" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    > > 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" <> wrote in message
    > > news:...
    > > > 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" <> wrote in message
    > > > news:...
    > > > > 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" <> wrote in message
    > > > > news:...
    > > > > > 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, Jul 3, 2003
    #5
  6. Kevin Spencer

    Ian Turner Guest

    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" <> wrote in message
    news:...
    > Let me point you to a couple of MSDN articles that should help:
    >
    >

    http://msdn.microsoft.com/library/d...ide/html/cpconhowruntimelocatesassemblies.asp
    >

    http://msdn.microsoft.com/library/d...ide/html/cpconspecifyingassemblyslocation.asp
    >
    > HTH,
    >
    > Kevin Spencer
    > Microsoft FrontPage MVP
    > Internet Developer
    > http://www.takempis.com
    > Some things just happen.
    > Everything else occurs.
    >
    > "Ian Turner" <> wrote in message
    > news:...
    > > 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" <> wrote in message
    > > news:...
    > > > 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" <> wrote in message
    > > > news:...
    > > > > 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" <> wrote in message
    > > > > news:...
    > > > > > 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" <> wrote in message
    > > > > > news:...
    > > > > > > 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, Jul 4, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Carl Johansen

    Single vs multiple IIS application roots

    Carl Johansen, Jun 7, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    3,379
    Shimon Sim
    Jun 8, 2005
  2. Replies:
    1
    Views:
    528
    Patrick.O.Ige
    Jan 16, 2006
  3. Ian Pilcher
    Replies:
    0
    Views:
    412
    Ian Pilcher
    Jan 28, 2006
  4. Rob Smegma
    Replies:
    1
    Views:
    510
    Martin Honnen
    Nov 4, 2005
  5. Justin Caldicott

    Complex Roots

    Justin Caldicott, Dec 30, 2003, in forum: C++
    Replies:
    5
    Views:
    592
    P.J. Plauger
    Dec 30, 2003
Loading...

Share This Page