Jeremy Davis
Sitecore, C# and web development
After you've finished installing an instance of Sitecore for development or test (as I've been discussing in my previous few posts – Installing, Adding DMS, Hosts & SSL), chances are you'll need to deploy some modules or packages onto it. Things like Web Forms for Marketers are regularly needed as a basis for development work. So what can you do if you'd like to automate this with PowerShell as well?
Continuing my current theme of installation automation via PowerShell, the next task I found myself looking at was how to enable Sitecore's analytics for a newly installed Sitecore instance. This is a task that the standard .exe installer doesn't do for the v6.6 sites I'm working with, but is relatively simple to automate.
Ages back I wrote up some
work on automating the Sitecore installer. I noted back then that I wasn't sure what the purpose of the
SC_IISSITE_ID
parameter to the MSI was. Having done some more work on the topic of install automation recently, I've got some more detail on what it's for now, as well as another parameter that's more important than I had realised...
When you install an instance of Sitecore via the .exe installer you get a single host name added to your machine, which matches the instance name you chose. But for real world projects this is rarely enough. Most websites need to respond to other host names, and they often also need SSL certificates installed so that these hosts can be accessed via HTTPS. Developers need these features set up so that they can code and test with them.
Recently I've been looking at automating more installation tasks via PowerShell, in order to try and standardise the processes developers use when setting up new instances for work. I've been digging out helpful bits of script from across the internet, and I plan to write a few posts to document some of the approaches I've been experimenting with. The first of these posts covers info on automating host names and their bindings:
Quick bit of script this week. Ages back I wrote up the process for working out how to run unattended installations of Sitecore using its .exe installer and then converted that to PowerShell. Recently I've been doing a bit more work on install automations in PowerShell. (Which I plan to write up in future posts) But while doing this, I realised that the flip side of automating the install is that it's also helpful to be able to remove an instance of Sitecore automatically too...
Spending a lot of time developing websites with Sitecore means I've reported my fair share of bugs to support. One particular issue that I came across in 6.6 a while back stands out as my "favourite" issue I've reported – just because the error stops a lot of developers in their tracks thinking "how on earth can this happen?". If you wrote this code, would you think it could crash?
Well it can crash. And to a less experienced developer it can be a very confusing error:
Recently a client of mine came up with some requirements that involved submitting data to the Web Forms for Marketers database via code. Having done a bit of Googling, I came across a Stack Overflow answer on the same subject which seemed to offer a solution. Implementing this code did indeed allow submitting data – however it didn't trigger Save Actions. So while the data will go to the configured WFfM data store, emails or CRM integrations won't get triggered.
That was an issue for my client, who wanted to have email notifications as well. So starting from the Stack Overflow responses, I looked into how the WFfM save actions can be correctly triggered via code.
I was down at Sitecore's offices for a training course the other week and got shown how useful the URIs for Sitecore items can be to your code – something I'd managed to miss before. So in the spirit of sharing, if you've not thought about uses for URIs, have a think about this:
It's a fairly common scenario in Sitecore code: You need to pass details about a specific item between two bits of code, but due to some sort of process boundary you can't pass the specific
Item
object. Given that a specific bit of content in Sitecore is specified by its database, identifier, version and language, how can you pass all that data across a boundary easily?
In my last two posts [first part, second part] I've outlined the results of some research into an approach for how you can package Sitecore with NuGet. I presented this at a recent Sitecore Technical User Group, and am documenting it here with a bit of detail that didn't fit into the presentation. This week I'll finish off the set of posts with a few conclusions from this experiment.
Last week I started writing up the content from my Sitecore Technical User Group presentation on using NuGet for the easy creation of new development instances. This week I'm continuing that topic, with the next steps for package creation:
