Dusty Eves

dusty.eves@techno-babble.net

Sitecore Architect with Paragon Consulting

Ideal Initial Sitecore Solution Setup

The initial Sitecore solution setup, day one, slogged through and forgotten.  It’s something the veterans in the field take for granted, and as such there’s not much on how it’s done put to paper.  For anyone new to Sitecore this is the bare-bones project setup that we use:

Bare-bones Solution

  • External References
  • Project.Data
  • Project.TDS.Core (optional / as needed)
  • Project.TDS.Master
  • Project.TDS.Content
  • Project.Web
  • Project.com directory (outside of solution)

External References

This doesn’t need to actually be a project per-se, but does need to be a directory check into source control.  This directory contains all the references on which your project relies.  At a minimum, this directory will have the Sitecore.Kernel.dll for the Sitecore version on which your developing.

Project.Data

If you’re developing an MVC solution Project.Models also works well for this.  This is where your Sitecore template wrappers will live.  If you’re using Sitecore Glass Mapper and auto-generating code templates this is where your GlassModels.cs as well as any class extensions are maintained.

Project.TDS.Master

This is where all your Layouts, Renderings, Templates, Branches, Workflow, and Meta-Content will live.  A good general rule of thumb is if the item is created by a developer and is something that you would never expect a content author to modify, it probably belongs in this project.

Project.TDS.Content

What goes in TDS.Content will vary depending upon the nature of your project.  If the initial content load is an effort disconnected from the development process, the TDS.Content project should contain working examples of development deliverables.  If the development effort works hand in hand with the initial content, then those items live in the project.

Project.Web

Self-explanatory, you can hardly have a Sitecore project without a web project.

Project.com Directory

This directory will be where Sitecore lives.  Rather than point IIS at the Project.Web directory and run directly out of there, we create a .com directory.  The .com directory initially contains just the initially Sitecore installation and the files unique to our Sitecore solution are copied into the .com directory as part of the build process.

Setup Steps

  1. Download the version of Sitecore you’re intending to run and install it to your .com directory.  Once the installation is complete, navigate to your .com URL and verify the initial Sitecore sample page loads.
  2. Create your Sitecore solution and create your Web and TDS.Master projects.
  3. Set your TDS.Master project up to deploy your Web project to the .com directory.
    • Open the properties of the TDS project and under the “General” tab select your web project in the “Source Web Project” field.
    • Under the “Build” tab, fill in the fields “Sitecore Web URL”, “Sitecore Deploy Folder” (your .com directory), and check “Install Sitecore Connector”.
    • Attempt to sync the project with Sitecore to verify the above setup.  There’s no need to actually execute the sync.  if the configuration is correct TDS will be able to scan the Sitecore tree.
  4. Build the project and verify files from the Web project copy over to the .com directory.
  5. Setup remaining projects.

Conclusion

The .com deploy directory for the development environment tends to be a significant departure from stand-alone web development.  It has several benefits in Sitecore though.  It eliminates the need to check files that are just part of the Sitecore solution into Sitecore and it makes upgrading Sitecore post development much easier.

Like what you see? Something I missed? Have an even cooler way to do the same thing?!?! Let me know in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *