Why ASP.NET 2.0 Application directories are not configurable

ScottGu provided detailed explanation in ASP.NET forums. I'll post the quote here so you won't have to scroll though the long thread.

<quote>

There is unfortunately a few technical reasons why we can't make them configurable:
1) Some of the directory names need to be identified before the application starts up. Specifically, you can only set assembly loading policy as part of app-domain creation. As such, the configuration of the directories would have to be set in something other than the local web.config (most likely machine.config) -- which breaks xcopy deployment as well as deployments in hosting environments (where you don't have access to change the machine.config).
2) Blocking the directories needs to be done through a native ISAPI filter (there is no other secure way to-do this out of the box). This filter also can't read from the web.config files of the application (otherwise it would significantly impact perf on all requests -- both asp.net and every other file extension -- to the system). It would also require that you reboot the web-server on every change (which is ugly too). In theory we could enable a registry setting to make this configurable -- but again this starts to get very ugly in terms of breaking deployments and makes administration a nightmare (among other things -- you'd have to be an admin on the box to deploy your app). This also breaks all hosting environment deployments.
We did look hard at having a shortened prefix instead of "application_" for brevity sake. As brian mentioned in the mail above the challange has been to find one that doesn't break a major tool or infrastructure piece that thousands of people use today. Specifically we looked at: "$code", "#code", "_code", "__code", ".code" (this was our favorite), "!code", and about 20 more. Each variety broke something major (command shells, frontpage, dreamweaver, source control systems, sharepoint, etc, etc). We are ceretainly open to suggestions if people can find one that works.
Note that the reason we've called it "application" instead of "asp.net" for a prefix is because these directories apply to a variety of different application types (Indigo for example, and IIS7 in the future). As such, we want to avoid having a product specific name (especially if it is a subset of the overall app-types that will use them).
We considered having a single sub-directory and grouping everything underneath as well -- the main reason we decided not to do that was that we got a lot of feedback that people preferred having them as top-level directories (even if a bit long) versus a sub-directory that needs to always be navigated to. Ultimately the consensus was that top-level makes things much easier and faster to navigate and manage.
Hope this helps provide some more context,
- Scott

</quote>

Comments

• Anonymous
  September 18, 2004
  Thanks for info
• Anonymous
  September 19, 2004
  The comment has been removed