Nested Web sites in Visual Studio 2005

[jdn]

I have a root application that has various sub-applications (subdirectories
set up as applications within IIS). All of the sub-applications rely on the
root application for profiles, membership, etc.

This all worked fine for a bit, but now, I get an error when trying to build
the root site:

"It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level. This error
can be caused by a virtual directory not being configured as an application
in IIS."

The subdirectory is configured as an application in IIS.

I also need to have separate global.asax pages for the root application and
the sub-applications, and Visual Studio doesn't seem to like this either.

How can I get this to work?

TIA,
jdn

 

[jdn]

I was able to resolve the issue, though it isn't totally satisfactory.

If you add a web site (new or existing) in Visual Studio 2005, you have
three options: File System, IIS, FTP.

I don't know about the FTP option, but if you use the File System option,
the problem comes up. No sub-applications are recognized as such by VS
2005, no matter how they are configured in IIS.

If you use the IIS option, things are fine. So, if you have code that isn't
in the inetpub\wwwroot folder, set up the web site within IIS to point to
the folder where it resides, and then add the site to VS 2005 using the IIS
option. It will then see any sub-applications as applications.

This shouldn't be the case, in my opinion. Even a File System web site
should see the IIS settings. But, this is a workable workaround. You will
need to add any of the sub-applications as separate web sites to VS 2005 in
order to work on them (in the root application, they simply appear with a
special icon).

jdn

 

[Jim Cheshire]

I was able to resolve the issue, though it isn't totally satisfactory.

If you add a web site (new or existing) in Visual Studio 2005, you have
three options: File System, IIS, FTP.

I don't know about the FTP option, but if you use the File System option,
the problem comes up. No sub-applications are recognized as such by VS
2005, no matter how they are configured in IIS.

If you use the IIS option, things are fine. So, if you have code that isn't
in the inetpub\wwwroot folder, set up the web site within IIS to point to
the folder where it resides, and then add the site to VS 2005 using the IIS
option. It will then see any sub-applications as applications.

This shouldn't be the case, in my opinion. Even a File System web site
should see the IIS settings. But, this is a workable workaround. You will
need to add any of the sub-applications as separate web sites to VS 2005 in
order to work on them (in the root application, they simply appear with a
special icon).

jdn

Hi,

This isn't a bug. In order to recognize application in IIS, Visual
Studio has to read the metabase and display file and folder structure
according to what is there. Obviously, this doesn't apply in a file
system project.


Jim Cheshire

 

[jdn]

Hi,

This isn't a bug. In order to recognize application in IIS, Visual
Studio has to read the metabase and display file and folder structure
according to what is there. Obviously, this doesn't apply in a file
system project.


Jim Cheshire

I disagree. You shouldn't have a set of sites that WORK and have VS 2005
tell you that you can't build correctly.

I can't imagine it would be impossible to add the capability to do this.

At least you didn't call it a feature.

jdn

 

[Christopher Reed]

Okay, I will call it a feature. One of the purposes of the File System
option within VS 2005 is because some computers will not be able to have IIS
installed. In some corporate environments, IIS is not allowed on local
workstations, even this may be their development environment. Additionally,
some developers only have access to XP Home which does not come with IIS.
So, the File System option provides web developers the ability to test their
website with a standalone web server.

 

[jdn]

Then they should have found a way to be able to remove project files (where
they could have stored the required information) and yet not have this
happen.

I would call it maybe a design flaw then, instead of a bug.

I don't think it makes sense to be able to write perfectly functional, legal
code, which functions within a file system project and have the IDE say the
site can't be built.

jdn

 

[Jim Cheshire]

Then they should have found a way to be able to remove project files (where
they could have stored the required information) and yet not have this
happen.

I would call it maybe a design flaw then, instead of a bug.

I don't think it makes sense to be able to write perfectly functional, legal
code, which functions within a file system project and have the IDE say the
site can't be built.

File system mode was meant to work against the ASP.NET Development
Server. You can, of course, use it to open content that's in physical
folders in the IIS web site structure, but in doing so, you have to
accept the fact that File System projects do not enumerate the
metabase because they are . . . well, file system projects.

Jim Cheshire

 

[Christopher Reed]

There's a distinct difference between being able to "write perfectly
functional, legal code" and "have the IDE say the site can't be built".
Just because the individual pieces work doesn't mean that the website will.
If the files cannot be compiled together, then your website cannot function.

 

[jdn]

File system mode was meant to work against the ASP.NET Development
Server. You can, of course, use it to open content that's in physical
folders in the IIS web site structure, but in doing so, you have to
accept the fact that File System projects do not enumerate the
metabase because they are . . . well, file system projects.

Jim Cheshire

All the more reason to bring back project files then, I would think.

<shrug>

jdn