7

I am working on creating a module that I was hoping to have be installed right thru the Sitecore shell. The deeper I go, the more I realize I will need to make manual changes to the web.config to get this to work. For example this snippet would be needed:

<handlers>
   <add name="Nancy" verb="*" type="Nancy.Hosting.Aspnet.NancyHttpRequestHandler" path="/services/*" />
</handlers>

The main reason I wanted this as a separate module and not something like a NuGet package is so it can be installed very surgically on target boxes, rather than installing it for the entire codebase and introducing this functionality to all servers including delivery servers (which I don't necessarily want). I could ultimately abandon my current approach and make this into a web service but holding off on that just yet.

TL;DR: is there any way to include any configuration higher than configuration/sitecore in an install package? Other suggestions welcome. Thanks!

Improve this question

5 Answers 5

Reset to default
6

Ignoring my NuGet approach above; the only obvious option you have available is a lesser-known feature in Sitecore packages called "poststep". Essentially you can instruct Sitecore to execute some code, after your package has installed.

Sean Holmesby describes it here: Sitecore Upgrade Post Step Scripts

While the blog post mentions this in regards to .update packages, this works for all Sitecore packages.

Inside your package archive, you'll find the sc_poststep.txt file.

enter image description here

Enter a fully qualified Namespace, Assembly here (I think you can add multiple) and implement the transformation code in a class. Your class needs to implement the IPostStep interface.

It's clunky, but it's the only option I know of that could achieve what you want.

Improve this answer
2
  • I was unaware of the Post Step scripts, this could prove very helpful. If I went this route I would want to make it explicitly clear what modifications hare taking place for the exact reasons mentioned elsewhere (web.confg accuracy)
    – vandsh
    Commented Oct 12, 2016 at 14:16
  • 2
    Yes. The concerns raised by other people on this question are valid - so be careful what you do. Especially considering; if your code messes up web.config - your solution is pretty much dead in the water. That said, this could do it.
    – Mark Cassidy ♦
    Commented Oct 12, 2016 at 14:21
10

If you are making Web.config changes (which would be required for adding an HTTP handler), I would say that this is not something that should be just "installed" on your servers. You want to maintain the accuracy of your Web.config in your source, right? I'd also be worried about deploying Web.config changes in such an ad-hoc way (rather than following a structured deployment process).

If you want CD/CM-specific Web.config changes, the best approach would be to create a build config for each, and use XDT transforms.

Improve this answer
1
  • 1
    This does make sense and was something I had considered as well. If I went the NuGet route, even though the .dll would exist in all deploy /bin folders, I could achieve selectively enabling it thru transforms.
    – vandsh
    Commented Oct 12, 2016 at 14:09
2

There is a way to do this. Has nothing to do with Sitecore though; but NuGet.

The snippet you posted; you can place this into a file called web.config.transform, to have it added to the existing web.config.

While I share some of the concerns raised above; this is definitely something you would want DevOps to know about (use the readme.txt file, for instance) - you asked; and this is how it's done.

Reference: Source Code and Configuration File Transformations

Improve this answer
1
  • Misread the question, sorry :P
    – Mark Cassidy ♦
    Commented Oct 12, 2016 at 14:04
2

Instead of including it directly, you can include it as a Post Installation Step as well.

Improve this answer
0

There's not a good way to modify a web.config file directly which is where the <handlers> tag is going to need to go. The web.config file has the ability to link in external config files but still require an update in the original web.config to the external config file.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.