Using IIS with VS 2005 and the new Web Project system

A number of people have asked me questions through my blog over the last few days about how VS 2005 uses and handles IIS (especially in cases of nested applications and virtual directories).  This blog entry provides more information on how this works, and hopefully clears up a few questions people might have.

 

Quick Review: How does IIS map applications and sites?

 

IIS supports hosting multiple “sites” on a server.  These sites are defined as a unique IP address, hostname, and/or port address combination.  For example: my site www.scottgu.com is a site with an IP address (192.197.157.24) a hostname “www.scottgu.com” and a port number of 80 (the default http port). Nikhil’s site (www.nikhilk.net) is also another site on the exact same web server machine.  It has the same IP address (192.197.157.24) and port number (80) as my site, but has a different hostname binding.  As long as one of these three things (IP address, hostname, port number) is different, each site can be differentiated and mapped separately on IIS.

 

When you register a site with IIS, you specify a parent directory for the default site content to live under.  When IIS is installed the “default site” is typically mapped to the c:\inetpub\wwwroot\ directory.  If you place a test.htm file immediately underneath this directory and access http://localhost/test.htm you will retrieve the file from the web-server.  You can have any number of physical directories and sub-directories you want underneath a site root.

 

IIS also supports the concept of “virtual directories” (commonly called "vdirs") under sites, which are logical directories from a url namespace perspective, but which do not have to be backed by a physical directory with the same name or location on disk.  For example, I could create a directory called “app1” that maps to c:\inetpub\app1 which contains a “test2.htm” file and create a “virtual directory” in IIS that mapped it underneath the default site. 

 

When I do this and request the below urls, the web-server will fetch these files:

 

http://localhost/test.htm -> c:\inetpub\wwwroot\test.htm

http://localhost/app1/test2.htm -> c:\inetpub\app1\test2.htm

 

Note that wwwroot and app1 are peer directories in this case.  Even though the logical url structure has “app1” underneath the root website, there is no requirement to physically structure the files this way (although I could if I wanted to).

 

IIS also then supports the concept of “applications” on servers.  These are the same as virtual directories except that they have some extra metadata stored in the IIS metabase configuration store associated with them.  With IIS6 they also support the ability for administrators to map them to be handled in different application pools (which are our worker processes) for greater reliability and process isolation. 

 

IIS “applications” can map to physical directories mapped underneath the site root, or to directories outside of the site root.  They can also be nested multiple layers deep. 

 

For example:

 

http://www.testsite.com/ -> c:\www.testsite.com\wwwroot (the “root site” app)

http://www.testsite.com/app1 -> c:\www.testsite.com\app1

http://www.testsite.com/app2 -> c:\www.testsite.com\app2

http://www.testsite.com/app3 -> c:\www.testsite.com\wwwroot\app3

http://www.testsite.com/app3/app4 -> c:\www.testsite.com\wwwroot\app3\app4

 

Note in this sample the root application (http://www.testsite.com/) and app1 (http://www.testsite.com/app1) and app2 (http://www.testsite.com/app2) are peer directories in the physical file-system hierarchy.  App3 and App4 are then physically stored underneath the wwwroot directory (with app4 actually being nested under app3).  The key thing to remember is that it is the IIS bindings, and not the file-system, which determines application scopes and boundaries – an administrator can configure things however they want.

 

In the IIS Admin Tool, the above mapping structure would look like this:

 

 

Note: Just to confuse things, when you use the IIS admin tool and right-click and choose “Create Virtual Directory” underneath a site, you are actually really creating an “application” (specifically: a virtual directory that has the app meta-data set).  If you want it to really be a vanilla virtual directory with no app semantics, you should open up the property pages on the newly created application and click the “remove” button under the virtual directory tab.  This actually doesn’t delete the virtual directory – it just removes the app meta-data and de-promotes it to be a normal virtual directory.  And no – this isn’t very logical or intuitive…

 

What does ASP.NET do with applications?

 

ASP.NET uses the IIS application meta-data flag (stored in the IIS metabase configuration system) to identify application boundaries, and applies special semantics to content hosted within them.  Specifically, when a directory is marked as an application ASP.NET does a few things:

 

1) It allows a \bin directory to be defined and used immediately underneath the application root directory to resolve assembly references. 

 

2) It allows “application-level” settings like authentication to be configured and set in a web.config configuration file.

 

3) It allows a “global.asax” file to be defined to handle global “application level” events (like application_start, and module specific events like session_start/end). 

 

4) In ASP.NET V2.0 it also allows additional directories to be created underneath the app root to handle things like data providers, class library compilation, application resource files, etc.

 

ASP.NET then creates a CLR app-domain for all code running in the context of an application.  This app-domain is where code-loading policy is set (and how the assembly loader is hooked up to a \bin directory), and how additional code-access security permissions can be applied. 

 

Using the above www.testsite.com application bindings as an example, this would mean that the \bin directory locations with the above apps could live in these physical locations:

 

c:\www.testsite.com\wwwroot\bin

c:\www.testsite.com\app1\bin

c:\www.testsite.com\app2\bin

c:\www.testsite.com\wwwroot\app3\bin

c:\www.testsite.com\wwwroot\app3\app4\bin

 

Code living underneath the \app1 directory would use \app1\bin to load compiled assemblies. 

 

Code living underneath the \wwwroot\app3 directory would use the \wwwroot\app3\bin directory to load compiled assemblies. 

 

Code living underneath the \wwwroot directory – but not under the \wwwroot\app3 directory – would use the \wwwroot\bin directory to load compiled assemblies. 

 

Note that these assembly loading semantics are identical with ASP.NET V1, V1.1 and V2.0.

 

How Do You Open a Web Applications with VS 2005?

 

VS 2005 supports multiple ways to open and edit ASP.NET Applications.  Out of the box its “Open Web Site” dialog (invoked when you create or open a new web project) has four tabs – one to open web projects directly off the file-system (just point to the app’s root directory and go), by browsing IIS directly, by entering FTP credentials to open a site remotely, and by using FrontPage Server Extensions (note: I've circled the 4 tabs in the screenshot below).

 

 

The file-system tab option is great if you are working on a self-contained web project that requires no knowledge of the directory or URL structure of content outside its structure. 

 

However, if you are using multiple nested IIS applications or special IIS virtual directory rules on your web server to coordinate multiple applications, then you should avoid opening up these projects using the file-system web option – and instead open them using the “Local IIS” or “Remote Site” tab options.  The reason for this is because these nesting and relationship rules are stored in the IIS metabase, and for your application to properly run you will want/need these IIS bindings and semantics to be handled both at runtime and inside VS 2005. 

 

If you are coming from VS 2003 you are probably used to opening up web-sites with FrontPage Server Extensions and using a known URL.  To-do this with VS 2005, just follow the following steps:

 

1) Select File->Open Website off the file menu

2) Select the “Remote Site” tab on the “Open Web Site” dialog (see below)

3) Enter the name of the app you want to open to edit (example: http://localhost/app1)

 

 

Alternatively, you can also now browse, create and open web sites and applications configured on your local IIS server by using the “Local IIS” tab new in VS 2005.  This does not require FrontPage Server Extensions to be installed on the web-server (hooray), and also provides a much richer tree-view of what the sites, applications and virtual directories look like on your web-server.  To use this with VS 2005, just follow the following steps:

 

1) Select File->Open Website off the file menu

2) Select the “Local IIS” tab on the “Open Web Site” dialog (see below)

3) Drill down and pick the appropriate sites/application to open

 

 

Note that – just like today – you can absolutely use both a root web-site application (for example: in the above dialog just click on www.testsite.com) as well as nested sub-application (for example: in the above dialog just click on www.testsite.com/app1).

 

Working with an IIS Web Application in VS 2005

 

Several people have asked what happens when you open up a website that has multiple nested sub-applications underneath it.  For example: you open up www.testsite.com (the root application), which contains three immediate sub-applications (www.testsite.com/app1, www.testsite.com/app2, and www.testsite.com/app3).  One of the questions/concerns people have asked is whether VS 2005 now merges the directory structure of all of these apps together into a single directory structure model – which would obviously really screw up building applications and projects (since the \bin directory and application semantics should be different between all 4 of these apps).

 

The good news is that VS 2005 does the right thing and preserves the application scoping correctly.  Specifically, when you open up the www.testsite.com application using the bindings we specified above, you will get a project view that looks like this:

 

 

The only files and folders included in the solution explorer are those within the root www.testsite.com application, and any non-application sub-folders it contains (for example in the above case “subdirectory1” and “subdirectory2”).  When you perform a build or compile within VS 2005 only those files contained within the www.testsite.com application (and not any sub-applications) will get compiled.  When you build and deploy a web project using the “Publish” menu item, you will only deploy those files in the www.testsite.com root application (and not any sub-applications).  These are the same isolation semantics as used in VS 2003.

 

One nice addition we have made to the solution explorer in VS 2005 is to have special icons for nested sub-applications show up in a root application’s web project view (you can see these in the screen-shot above with the app1, app2, and app3 special icons).  These are intended to let a developer know that there are sub-applications at this point in their logical web-space, but not get in the developer’s way.  These do not have any build semantics (they are completely excluded just like VS 2003 from compilation operations), and you can not expand them to get to their web-content.  They are simply designed to let you know a sub-application is there and to help you get context on the broader web structure.

 

Note also that in the above example “app3” happens to be mapped to a physical directory (c:\www.testsite.com\wwwroot\app3) directly underneath the root www.testsite.com application (c:\www.testsite.com\wwwroot\).  However, because it is marked as an application in IIS, VS 2005 will automatically exclude it from the www.testsite.com project and all compilation (same semantics as VS 2003).  Subdirectory1 and Subdirectory2 are not marked as applications in IIS, which is why they show up as part of the www.testsite.com application (again – same semantics as VS 2003).

 

One other nice workflow feature added in VS 2005 is that you can double-click on these sub-application icons.  When you do this you will get a dialog pop-up that will prompt you to either open this web application (and replace the current open solution) or to add this web application to your current opened solution:

 

 

For example, if I choose “add the web site to the current solution” when I clicked the “app3” icon in the solution explorer, I would end up with two separate isolated web projects in my solution:

 

 

Note app3 is physically underneath the wwwroot application’s directory on the physical disk – but like VS 2003 I get an isolated view of each application, and each application can be built and deployed separately.

 

Strategies for Web Project Management with IIS and VS 2005

 

You can use the same solution patterns you used with VS 2003 to manage sub applications with VS 2005.  Typically for nested sub-applications we see developers create a separate solution for each application – which typically contains a web project, as well as one or more class library projects.  For example, in the below sample I’ve added a data access layer (DAL) and business logic layer (BLL) into a solution that contains my www.testsite.com root application.

 

 

I can then setup cross project references and build dependencies the same way I do today:

 

 

I can then save out my solution file which encapsulates all of these cross-project relationships to disk (just like VS 2003 does today).  When I open it again in VS I will load the solution with the same settings as I left it before, and all three of my projects will open.

 

When I use the “Publish Web” option inside the IDE, it will compile the DAL project, then the BLL project, then compile the web project – and deploy the resulting binaries from all three compilations in the deployment directory I specify.

 

Versioning Applications using ASP.NET 2.0

 

One last thing to mention on the topic of IIS and ASP.NET 2.0 is versioning.  Specifically, the .NET Framework and VS fully support side-by-side with the .NET 2.0 and VS 2005 releases.  This means you can have VS 2003 and VS 2005 installed together on the same machine, and use VS 2003 for some projects and VS 2005 for others. 

 

It also means that you can choose to have some ASP.NET applications on your web-server use ASP.NET V1.1, and others run using ASP.NET V2.0.  This later support is particularly interesting – as it allows you to incrementally switch over your systems to use the new features on your schedule, and does not force an “all or nothing” move.  By default when you install ASP.NET 2.0 on a machine that has ASP.NET V1.1 already installed, we do not automatically upgrade these apps to use the new version.  Instead, administrators get to choose which app uses which version.  Note that this fully works with sub-application solutions -- where for example you could migrate the www.testsite.com/app1 application to V2 while keeping www.testsite.com/app2 on V1.1 and migrate it on a different schedule.

 

One way we’ve tried to make version switching easier is by adding support for it to the IIS admin tool under the new “ASP.NET” tab that gets installed when ASP.NET 2.0 is on the box.  You can pull up this tab now on any IIS application, and choose which version of ASP.NET you want to run using a version drop-down that will list all versions of ASP.NET installed on the system.  Simply pick a version, hit the apply button, and you’ve configured that app to run using it. 

 

 

No more messing around with ISAPI script-mappings required.

 

Summary

 

Hopefully this provides a quick summary of how you build and manage web applications using IIS with VS 2005.  If you are using VS 2003 you should find the steps pretty familiar – although hopefully the workflow is a little faster and easier that before.

 

Let me know if this makes sense or if you have any questions.

 

Thanks,

 

Scott

 

 

64 Comments

  • If I want to use a custom MembershiperProvider that code file is in app_code folder how can I specify the assembly name in membership section of the web.config file ? It seems to me that assembly name is generated at each build, isn't it ?

  • Hi,



    I develop on a Windows XP Pro machine and publish the sites to a staging IIS server thats on the local network. I think this is typical for a lot of devs out there.



    Can I also connect to this IISserver without requiring it to have FPSE and still see the virtual dirs and applications?



    And if not is it a security measure?



  • Scott, these last two posts are extremely helpful!!! I've printed both of these posts to use as references for implementing 2005. Thank you very much.

  • Simply installing the .NET Framework 2.0 redistributable on my production server didn't create that ASP.NET tab in IIS Manager. Apparently one still must use aspnet_regiis in that case?

  • Hi Jim,



    Unfortunately there was a miscommunication in the Beta2 timeframe, and the feature team working on this feature assumed a policy of not installing the tab when a previous version of ASP.NET was detected. This has been fixed in later builds (and the tab will always be there with the final release).



    To add the tab back in for the beta2 release, you should be able to run this command from the V2 specific framework directory:



    aspnet_regiis -ir



    Hope this helps,



    Scott

  • Hi Mattieu,



    If you are using a custom provider built in the app_code directory, you can just definethe classname to register it in web.config (for example "MyClassName"). You do not need to specify the assembly name if it comes from app_code.



    Hope this helps,



    Scott

  • Hi Michel,



    If I understand you correctly, you want to store your files on disk like this:



    c:\source\solution1\ <= parent dir of solution

    c:\source\solution1\solution1.sln <= solution file

    c:\source\solution1\webapp\ <= web project

    c:\source\solution1\library1\ <= class library project

    c:\source\solution1\library2\ <= class library project



    If so, then that will work just fine. You should find this pretty easy to setup and managed using VS 2005. Because we don't require Frontpage server extensions anymore (which by default stick apps underneath the c:\inetpub\wwwroot\ directory), it is a lot easier to map web projects to any place on disk.



    Hope this helps,



    Scott

  • Hi Tom,



    Yep -- we definitely see the scenario of a developer building on Windows XP Pro and then deploying to a remote staging server as a common scenario.



    The treeview that let's you browse IIS vdirs and applications unfortunately only works on local IIS boxes. This is for three reasons: 1) security in getting permission to browse the IIS metabase store, 2) the protocol to access the metabase remotely as an admin is a dcom based one and is typically blocked by firewalls and some enteprise networks, 3) ultimately to open a web-site you need both the ability to find its apps/sites, as well as actually get the files (for local IIS boxes it is easy, because we can just lookup the physical file paths and access them directly).



    To connect to remote servers for your scenaro you have three options:



    1) FPSE (this is similar to VS 2003 today)

    2) FTP

    3) Opening the remote paths using UNC shares



    Hope this helps,



    Scott

  • mmmmmm... 2.0.50727... when is it going to hit MSDN Subscriber downloads!

  • Hi Steve,



    I think we've now locked on that version string to be the final version string for the product, and are now doing point-builds to increment it. Right now I'm using 2.0.50727.18



    Hopefully you'll get it soon. :-)

  • Thanks Scott. That is perhaps the best summary (or blog post) I have seen for any MS product. Answsers many questions I have always had and could never find in such clear language. Thanks!

  • Thanks Scott for another great post. Your recent posts have been providing valuable insight for upgrading to 2.0


  • Thanks, Scott. As always, a very helpful post.

    The "find" function does not work in VS2003 for Web apps. Does the "Local IIS" new access mode solve this problem ?



    Thanks,

    Jean-Marie

  • Hi Jean-Marie,



    I don't have a copy of VS 2003 handy right now, so am not really sure what the find behavior there is. I did just try out the "find in files" behavior in VS 2005 on a web-project using the Local IIS feature, and it seemed to work just fine.



    Hope this helps,



    Scott

  • BTW... you do force me to use Frontpage server extensions if I want to publish to a remote site. :( :(

  • Hi Tommy,



    Actually no -- you can use FTP with VS 2005 to directly publish to a remote site. You can also obviously use a network share directly (or connect over DAV) if you want to. So you aren't limited to using Frontpage server extensions (which is what VS 2003 is limited to today).



    Thanks,



    Scott

  • Oops, you're right, I was thinking of "Find in files", not a simple find. In VS 2003, this command does not work for Web apps. I just rechecked.

    But, in VS 2005 beta 2, I could do it without problem in "Local IIS", "File System" and "Remote Site" modes. Nice.



    Thanks,

    Jean-Marie

  • Scott,



    I had tried Web Projects before and it didn't work as you described, but I just tried it again with Beta 2 and it seems to work at this point to get the project segrated.



    However, now I get errors compiling my project. Looks like there are problems with the web.config file in the



    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.

    error ASPCONFIG: D:\Westwind\aspnet_webadmin\2_0_40426\web.config(Line 6)



    And there's still the issue of ASP.NET 1.1 sub-virtuals choking on any 2.0 web.config entries higher up the virtual directory or root web chain...



  • Hi Rick,



    The error you are seeing (it is an error to use a section registered....) basically means that you are trying to use a section in a web.config file that can only be used at the application level in a sub-directory beneath the application.



    What this usually means is that you have a virtual directory that doesn't have the application-bit set in IIS, but which you are using as the root of a web project as a sub-application.



    From the description above it looks like the error is coming from the aspnet_webadmin tool -- which is a little weird, since it doesn't by default work under IIS (instead for security reasons it is configured by default to only work with the built-in web-server). Did you copy it underneath an IIS path? If so, you should make sure its virtual path is set as an application in IIS.



    Hope this helps,



    Scott

  • Scott-



    That lead to something. Yes, the SubSite is maked as an application. I did some more inspection of the root web.config and we are using aspnet_setreg to encrypt username and passwords.



    The offending line is:



    <identity impersonate="true" userName="registry:HKLM\Software\Company\Platform\[Account]\ASPNET_SETREG,userName" password="registry:HKLM\Software\Company\Platform\4.0\[Account]\ASPNET_SETREG,password" />



    Do you know of a work-around to accomadate this?



    Thanks for the help!

    Ben






  • Scott-



    Found the issue. Nothing to do with aspnet_setreg. The issue was that the root site was inpersonating a user that didn't have access to write to the v2.0 Temporary ASP.NET Files. That was a fun one. Thanks for the help...defintely pointed me in the right direction.



    Thanks,

    Ben

  • Hi Ben,



    To share Forms Auth between the two apps, you also need to make sure that you have a common key being used between the two systems (this is also true when you share across machines). By default ASP.NET uses an auto-generate value that will probably be different between the two versions. If you instead fix it to be a specific value, I think this should work.



    Hope this helps,



    Scott

  • Scott, I am working on a website that has a virtual directory (/shared). It contains several html files with boiler plate text for our legal pages. This is not an application but a simple virtual directory. Because of the virtual directory, I cannot use the file based solution (the built-in web server does not support virtual directories), so I am using a local IIS solution. The problem is that VS2005 treats the virtual directory like a physical directory and copies the directory when I publish the site. Is there a way to prevent this? Thanks, Steve

  • Hi Scott,

    The easist approach would be to copy the file to each app (then you get both WYSIWYG designer and runtime support). I believe for the /app1 app you might be to use this syntax to get runtime support "../master.master" -- where you are logically walking up to the parent app to share the file.

    Hope this helps,

    Scott

  • Hi Steve,

    There are a couple of ways to change this behavior:

    1) Move the virtual directory so that the physical path for the virtual directory is not underneath the app. The virtual paths would all stay the same -- the only difference is that the physical path would be different. This would prevent those files being published.

    or:

    2) You could make the /shared virtual directory as an application. If this just contains static files then there would be no change in behavior, and it would be automaticlaly excluded from publish operations.

    or:

    3) You could covert your web-site project to be a VS 2005 Web Application Project. With this project type you can explictly include/exclude files from the project -- and only those files in the project are published. I have a tutorial on how to covert a project to be like this here: http://webproject.scottgu.com

    Hope this helps,

    Scott

  • Scott, I have an existing 1.1 App (in a separate Virtual Directory as you described) that I am trying to put under a new 2.0 App as part of a gradual 1.1 to 2.0 migration. The 1.1 app is choking on the inherited web.config coming from the 2.0 web.config above with this error: "Parser Error Message: Unrecognized configuration section 'connectionStrings'". Apparently it does not recognize the new sections that are being passed down to it. This is what Rick Stahl was mentioning in his comments above. One way to get around this would be to put these 2.0 sections in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config, but I would hate to hamstring the new project that way. Are there any other ways to stop the 1.1 web.config from inheriting the settings from above. Thanks Will

  • Hi Will,

    My guess is that you are running into this at runtime as opposed to design-time, and it is unfortunately a design limitation with how configuration settings inherit. We realized this in V2.0, and added support to handle it for V3.0 -- but unfortunately 1.1 doesn't support a way to bypass sections it doesn't understand built-in.

    Two ways you could get around it:

    1) You could update the V1.1 Machine.config file to have ignoresectionhandlers mapped to the new configuration sections like . This would cause V1.1 to ignore these parent settings.

    2) You could change the site name from something like http://www.domain.com/app1 to http://www2.domain.com/app1. This would prevent the app1 app still running with V1.1 from inheriting the web.config file in the inetpub root directory.

    Hope this helps,

    Scott

  • If i create a site under file system but later decide i want to use local iis how do i change the binding?

  • Thanks Scott! I appreciate your effort for the Asp community.

    It worked great to use an IgnoreSectionHandler for the the 'connectionStrings' section in the 1.1 machine.config and I thought I was all set to put my 1.1 app under my 2.0 app. Then I added an IgnoreSectionHandler for 'system.web.pages.namespaces' and got the error "Child Nodes are not allowed." Have you encountered that issue? Here is the code in the 1.1 web.config file:





    Will

  • Hi Andrew,

    If you want to switch a project within a solution to use IIS, just remove it from the solution, and then choose Fill->Add->Web Site and use the IIS section above to open it.

    Hope this helps,

    Scott

  • Figured out a way to do what I need. In the page directive, I specify pagefile=”” when surprisingly, the compiler will accept. Then in the pages pre_init event, I set the masterpage to “~/Master/mypage.master”, which works on my development box and should work in production. I suppose the same approach would work if I set the directive in the web.config and overrode it in global.asax.
    Incidentally, I have seen documentation that claims you can specify the masterpage in web.config and override it in a particular page’s page directive, but this won’t actually work. If the page does not have a page directive, then it must have all the tags that are omitted from a content page in order for it to compile. If it has those tags, you won’t be able to set it to use a master page at runtime (I don’t think). So don’t see how this notion of having a default master page for the app and overriding it for specific pages can work in practice.

  • Hi Will,

    Unfortunately I don't think you can block out that section. :-(

    What you could do, though, is add a location directive to the machine.config or root web.config for ASP.NET 2.0 and set the namespace values there (as opposed to within the root web.config in inetpub). Since V1.1 uses a separate machine.config file it won't see this and as such won't have a problem.

    Hope this helps,

    Scott

  • Hi Scott,

    We have upgraded all our ASP.NET 1.0 and 1.1 web applications to run against .NET Framework 2.0 on one of our local web servers (IIS 6.0). Most of our applications are working fine against the new version. However, we've hit a problem where one of our web applications that uses two assemblies (a custom server controls library and data provider) from the GAC throws a "Could not load file or assembly ... or one of its dependencies. The system cannot find the file specified." exception.

    The assembly binding redirects are in the machine.config and the runtime section of the application's web.config includes the qualifyAssembly element to allow partial naming. The web.config in the framework 2.0's config folder has not been modified. The 2 assemblies it can't find are not in the local bin folder but are in the GAC. This used to work against 1.1. The app still works if we make it run against 1.1 in its own application pool. However, we need it to use the new version so this is not an acceptable workaround. Can you offer any guidance please?

  • Hi Jyoti,

    The issue you describe above actually sounds like the issue fixed by this QFE: http://support.microsoft.com/?kbid=915782&SD=tech

    If you call the Microsoft Support number they will be able to send you the QFE patch for free that fixes it. We are also then going to make it available via download later this month I believe.

    Hope this helps,

    Scott

  • Hi Jyoti,

    Can you send me an email that summarizes the problem (scottgu@microsoft.com)? I'll then loop someone else in to help investigate.

    Thanks,

    Scott

  • Hi Scott,

    It's kind of urgent.

    We have an ASP.NET 2.0 application (migrated from 1.1) running on Win 2003 Server (IIS 6.0). There are many instances of this application running on different application pool for each of our client.

    All the time it works fine but sometimes it just dies throwing exceptions from mscorlib like IndexOutOfRangeException etc. and we have to recycle/restart that specific pool. It seems when it dies, it's not able to instantiate an object because mainly it happens in new().

    Any help???

    Best regards,

    Praveen

  • Hi Praveen,

    It sounds like you might be loading two versions of the CLR into the same process. Can you double-check that you don't have both a V1.1 and a V2.0 application loaded within the same application pool?

    Thanks,

    Scott

  • Scott,
    I have just moved my vs.net 2005 asp.net app to my remote server. When I now do open website, I can open it on x:\inetpub\mywebapp but when I try to browse default.aspx I get a security error:

    The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

    I've tried changing the trust level in the machine.config and changing the .net configuration utility security policy but I continue to get this problem.

    Any ideas appreciated.

    Thanks
    Kieran

  • Hi Kieran,

    I'm not 100% sure I understand your scenario. Any chance you could email me some more details (scottgu@microsoft.com) and I'll be able to help you more.

    Thanks,

    Scott

  • Scott, my situation is as such: I have a ASP 2.0 Application and set it up on server under IIS - the problem is, when 2.0xx is selected under the ASP.NET menu, the website cannot be found. When 1.1 is selected, the website can be found (but errors out on the connectionStrings tag, something specific to 2.0). Is there a way to fix this?

  • Hi Jon,

    It sounds like some internal error is happening. Are you using IIS6? If so, can you make sure that the ASP.NET 2.0 web-site is running in a separate application pool from all 1.1 sites. It could be that it is trying to load in a 1.1 process and that is causing the problem.

    If that doesn't fix it, try checking the Windows Event Log under "Application" to see if an error was output there.

    Hope this helps,

    Scott

  • Thanks Scott, it turned out to be that we didn't have the 2.0 Extensions set up on IIS, but the framework installed.

  • Is there a more basic version of this information? I'm trying to build an Intranet site to house (initially) an app that is finished, and I want to set up neat folder heirarchies so that I can keep everything organised, as I add more departments home pages, and apps for each department.

    I'm afraid this all seems very complicated.

  • Hi Alan,

    What I usually recommend is to not create custom virtual directories unless you absolutely have to (since they can make deployment more complicated).

    If you are building a standard Intranet application, just have normal directory folders underneath your application root. This should help keep things simple.

    Thanks,

    Scott

  • Hi Alan,

    This blog post might help with what you are after: http://weblogs.asp.net/scottgu/archive/2006/08/16/Tip_2F00_Trick_3A00_-Creating-Sub_2D00_Web-Projects-using-the-VS-2005-Web-Application-Project-Option.aspx

    It points to two articles that describe how to setup sub-projects to handle scenarios similar to what you are after.

    Hope this helps,

    Scott

  • what are the minimum requirements for running an .aspx page on a machine?
    I can run that using Visual Web Developer 2005.
    But i need a more generalised solution using IIS and .NET Framework......
    Is it possible to run the aspx page without VWD?

  • Hi Siddharth,

    Yes - you can run ASP.NET without having IIS installed on a machine. If you open up a web-site using the "file system" option shown in the second picture above, then it will use a built-in web-server that ships with Visual Web Developer to run it.

    Hope this helps,

    Scott

  • Hi Scott,

    I've installed VS 2003,VS 2005 and sharepoint services in my windows 2003 OS.When i tried to run the dubbugin in VS 2003 it says that 'auto-attach w3wp.exe is failed'. I open my IIS and check the ASP.NET tab, i found out that only the 2.0 version is there. The thing is that i've already installed my .Net Framework 1.1 but didn't appear in ASP.NET/Version Tab.What do you think is the problem? Also, during my setup of sharepoint, i unchecked the asp.extension in IIS.


    Regards,
    JC

  • Hi Scott, I had already solve my problem with ASP.NET version..what i did was i run the aspnet_regiis -i, and it worked.
    But i have another problem, when i tried to run or debug my application using vs 2003 i encountered error something like permission.I checked my wwwroot and i found out that there's a web.config generated during my installation of sharepoint services. I renamed it to web.config.old and tried again to run/debbug my application and it worked properly without a problem.But if i rename it back to web.config, the problem occured.What should i do to so that even if there's a web.config (for sharepoint purpose)in my wwwroot i can still run my application without a problem.

    Regards,
    JC

  • Hi Scott,
    Thanks for your blog--it's been invaluable. We have a root application that references many dlls that no other applications will reference. Is there much overhead with leaving all of these references in the root web.config? Or is there a recommended way to reference dlls (without putting them in the web.config) that also makes them available to the IDE? These dlls are in the GAC.

    We also have an issue that we can't reference a 2.0 dll in the root web.config because we have many 1.1 applications that we are not willing to convert yet. We tried to block it in the 1.1 machine.config, but I was not able to get it to work. If you think that's an option, can you provide the name for for hiding an assembly that's been added? Or even for hiding all assemblies?

    Thank you,
    JaS

  • Hi JaS,

    I would just keep it in the root web.config file. There shouldn't be any performance issue with doing this.

    Thanks,

    Scott

  • Hi. Glad I found this! Have got a web server in Windows Server 2003 with IIS 6 and some application folders which are also virtual directories. Accoring to your blog, they should show up in VS 2005 when the remote web server is opened, but they don't. Is this an IIS6 problem?

  • Hi, great information.
    I have an situation, hope you could help me.

    1) I have a precompiled site exposing WebServices which i need to debug.
    2) It relies on some traditional C DLLs.

    Now if i publish source code on IIS then it gives DLLNotfoundException for nativeDLLs, hence i am using precompiled website.

    Under Development Server also i am not able to resolve the issue of DLLNotfound for native DLLs.

    So how do i debug this precompiled website?

  • We use the web setup project to deploy our web applications. To automate additional installation tasks like setting the .NET version and encrypting the web.config files we use a custom installer along with the web setup project (see relevant code below). However we recently ran into a problem when deploying an application on a server where there are several web sites. The site we wanted to install on was not the default site. Therefore our code to set the .NET version and assign the newly created application pool did not work since "W3SVC/1/ROOT/" was not the correct path to the website. Is there a property similar to [TARGETDIR] which we can pass to our custom installer to account for this. We know hard-coding "W3SVC/1/ROOT/" was not the best option but we also knew it would be correct 90% of the time. Thanks as always for your time.

    Best Regards,
    Stephen



    info = New ProcessStartInfo()
    info.FileName = "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe"
    info.Arguments = String.Format("-s W3SVC/1/ROOT/" & strVDir)
    info.CreateNoWindow = True
    info.UseShellExecute = False
    Process.Start(info)
    info = Nothing

    Dim myApp As New DirectoryEntry("IIS://localhost/W3SVC/1/ROOT/" & strVDir)
    myApp.Properties("AppPoolId").Item(0) = strMyAppPoolName
    myApp.CommitChanges()
    myApp = Nothing

  • Hi Stephen,

    You can pass in the targetsite and targetvdir path as context parameters to your custom action by passing this:

    /targetdir="[TARGETDIR]\" /targetvdir="[TARGETVDIR]" /targetsite="[TARGETSITE]"

    If you want to send me email I can forward some code that walksthrough how this can be done.

    Thanks,

    Scott

  • I'm currently creating a web setup project and want the installer to create a new website based on the details the user enters as oppossed to adding a virtual directory under a selected website. Is this possible and if so how would I go about achieving it?

    Thanks in advance
    Neill

  • Hi scott,

    I have two application in asp.net 2.0, one app will store all the pdf files within that application folder. In app2 i want to access it, how to configure web config (defining path) for 2 applications

    Regards
    RamesH

  • Hi Ramesh,

    Are you trying to access the .PDF files from code on the server? If so, the second application should be able to just open the file-path directly and access the files.

    Thanks,

    Scott

  • Hi Scott,

    How are you? Can I host a precompiled VS 2005 website using IIS in Windows XP Pro?

    Thanks and regards,

    Sai K. Huan

  • Hi Sai,

    Yes - you can host a pre-compiled site with any version of IIS, including IIS on XP Pro.

    Hope this helps,

    Scott

  • Hi Mohsen,

    Are the DLLs you are trying to reference in your \bin directory already? If so then you don't need to explictly reference them - they'll actually be autonmatically referenced and conmpiled against when using a web-site project.

    Hope this helps,

    Scott

  • Hi,
    I want to create a web deployment project through which i can deploy my web application on server. I had made it but while deploying the application it create's the folder under C:\inetpub\wwwroot. Please let me know any way by which i can provide the option which will give option at the time of installation that in which drive or directory you want to do the installation.
    Please let me know the solution in .NET 2003 or .NET 2005
    Thanks
    Gagan

  • I migrated one of my projects designed in VS 2003 to VS 2005. Whenever I build the application (migrated one), I get a port number in the URL. Is this mandatory? Because, I have my CSS and images files in another folder which is outside the virtual directory which cannot be seen when I browse. But if I remove the port number and browse it, all the images and CSS appear ok.

    Any idea?

  • Hi Sathya,

    If you click on the project root in the solution explorer, and then go down to the properties window, you should see a property that allows you to configure which port number to use. If you configure port 80, then the number won't show up in the browser window.

    Hope this helps,

    Scott

Comments have been disabled for this content.