Jeremy Davis
Sitecore, C# and web development
Recently I posted an idea for a PowerShell script to extract the set of changed items in TFS needing deployment for a Sitecore project. I left the script at the stage where it gave a list of the files to package, but didn't actually give you a package definition.
Having done a bit more thinking about how that might be achieved, I've decided that it's probably worth a series of posts as creating a sensible solution to the problem seems a bit too complex for a script and a single post.
So for this first post, I'll sketch out the problem I want to solve and look at some of the basic code if will require. I'll flesh out the code an implementation over the rest of the posts – but I'm not sure how many there will be at this point...
There's quite a bit of material out on the internet about creating custom fields in Sitecore. But inevitably, when I found myself with a requirement to create one, I couldn't find anything particularly close to my needs. So here's another post about creating a custom field – maybe it'll be of help to someone...
Recently I found myself at the end of a sprint where a collection of developers had worked on a lot of different things in a pre-existing Sitecore solution. I needed to be able to deploy only the changes that were part of the sprint, and I had to generate a deployment package that could be installed by the client. And I didn't have access to any fancy tools such as Hedgehog TDS, that can be used to automate these things in other ways.
I've talked previously about how you can improve your content editors' understanding of where things live inside your Sitecore content tree by making use of relative queries to specify where the editing UI finds things. You can do it Data Sources.
Logically, you'd assume that if a relative query works for a Multilist field in a normal template, it should work in a Parameter Template too? Well, if you set up something like this:
NuGet is a really useful tool for managing external references for your .Net projects. It's also a tool that the Sitecore community are making good use of, with loads of useful Sitecore extensions available as packages. Plus it's been extended with the ability to deploy things into a Sitecore instance. Another potential use in Sitecore projects (that I've not found much discussion of) is for your references to the Sitecore DLLs themselves. I've been experimenting with this on some of my projects, so thought I'd write down what I've tried.
As I've mentioned previously, I'm finding that getting new instances of Sitecore installed on a development machine is a bit of a "horses for courses" thing. Quick instances needed to test something or do some development that's not sensitive to precise configuration can be created quickly and easily with SIM. But sometimes I need to do some work that relies on me setting up the instance in as close as possible a way to how the production instance should be. That usually involves running the Sitecore installer.
I was creating a quick package to transfer some content between Sitecore instances the other day, and happened to scroll down to the bottom of the Metadata page in Package Designer. Not for any real reason – just some over-enthusiastic scroll-wheel action. But when I looked at the dialog, it struck me that there were two fields here I'd never paid any attention to before:
Last week I spoke at the London Sitecore Technical User Group, and discussed my experiences working on a project that had to provide a Faceted Search UI in Sitecore 6.6. As part of my example, I talked about how you can build Facets using Lucene when you don't have access to the newer search APIs available in Sitecore 7.x, and about how you can make your search UI configurable by editors to improve their user experience. And I said I'd post my example code and explanation. So here goes:
The last three posts have discussed some prototype code for a sitemap generator, and I want to wrap the series up with a few thoughts about how the size of your Sitemap build operation might affect your site.
Edit:
When I wrote this post I didn't know what the
SC_IISSITE_ID
parameter to the MSI was for. Since then I've discovered what it does. And it turns out that it and another parameter not discussed here are quite important if you want to install more than one instance of Sitecore on the same machine. If you want to make use of the automated approach below,
you should also read my more recent post about the parameters.
I got a question on twitter the other day about how you might go about using the automated install ideas I posted recently in a PowerShell script.
I'm not much of a PowerShell user, but here are a couple of suggestions:
