M
Mark Rae
Hi,
Am currently in the process of migrating a whole heap of v1.1 ASP.NET
solutions to v2.0, and would be interested to know what others are doing
about excluding web.config from projects.
In v1.1, it was quite usual to exclude web.config from the project so that
it wouldn't get deployed to the live site along with the rest of the aspx
etc files and the bin folder. Typically (for me, anyway!) this was because
the web.config would contain lots of appsettings values which were different
in the development environment, the testing environment and the live
environment e.g. database connection strings etc. Excluding web.config from
the project meant that it didn't get deployed with the rest of the solution
so that deployment wouldn't overwrite the file on the other environments.
Excluding web.config in ASP.NET 2 renames it to web.config.exclude, which
causes debugging to fail.
What is the accepted wisdom for overcoming this in ASP.NET 2?
Mark
Am currently in the process of migrating a whole heap of v1.1 ASP.NET
solutions to v2.0, and would be interested to know what others are doing
about excluding web.config from projects.
In v1.1, it was quite usual to exclude web.config from the project so that
it wouldn't get deployed to the live site along with the rest of the aspx
etc files and the bin folder. Typically (for me, anyway!) this was because
the web.config would contain lots of appsettings values which were different
in the development environment, the testing environment and the live
environment e.g. database connection strings etc. Excluding web.config from
the project meant that it didn't get deployed with the rest of the solution
so that deployment wouldn't overwrite the file on the other environments.
Excluding web.config in ASP.NET 2 renames it to web.config.exclude, which
causes debugging to fail.
What is the accepted wisdom for overcoming this in ASP.NET 2?
Mark