While you cannot avoid changing the actual web.config file that will appear in the published /website folder of your site, you can make it so that you do not actually change the OOTB web.config file provided by Sitecore in your solution, by using config XDT Transforms.
If your goal is maintainability, and upgradability then this is the option for you.
Using XDT Transforms to insert your new handler
- Include a copy of the OOTB web.config file in your solution (which you could optionally make into a read-only file or just mandate that developers shouldn't change it).
- Add a transform file for the web.config file, which you can optionally nest under the web.config (e.g. web.transformed.config; some versions of VS require extensions to nest files with expand/collapse, e.g. the SlowCheetah extension, but that is OOS for this post).
- Set your transform files to actually transform on build (using VS build configurations, SlowCheetah, build events, or any number of other options) or on deployment to your build server (e.g. TeamCity) as a custom build step
- Add the necessary configuration to your nested transform file, including your new handler, with the necessary XDT Transform(s)
Your config transform (e.g. web.transformed.config) for this change would probably look something like the below (untested):
<?xml version="1.0" encoding="utf-8" ?>
<add verb="*" path="project_sitemap.ashx" type="Project.Web.Handlers.Sitemap, Project.Web" name="project_sitemap" xdt:Transform="Insert" />
Note that in the above, I used
xdt:Transform="Insert" to add the new handler into the config.
There are multiple ways to organize and execute your config transforms, and the strategy that you choose should help you determine how to name your transform files and what to include in each.
OOTB, Visual Studio supports transforms applied on build for each build configuration. The default build configurations for each solution in VS are
RELEASE. You can add web.DEBUG.config and web.RELEASE.config transforms to be executed on build for the corresponding build configuration (i.e. if building in
DEBUG mode then the web.DEBUG.config transform will be applied, where as if building in
RELEASE mode then the web.RELEASE.config transform will be applied).
In contrast, Sitecore's config-patching feature is an example of a custom transform strategy that is executed on application start up. Conceptually, you could create a similar strategy that runs on build for all build configurations, wherein all configs that are configured as transforms would execute on build, regardless of naming, and you could use the names to identify the contents of the transform file rather than the build configuration that the transform file is applied for.
The sky is the limit with XDT Transforms, so start simple and figure out which strategy is best for you.