Sean Kearney

TDS Deployment Properties Report

Wed, 23 Mar 2016 04:25:00 +0400

In the Sitecore Slack Team's #TDS channel there was a Team Development for Sitecore feature request from Robbert Hock. It was:

On the Deployment Property Manager, being able to export the settings to Excel (so I can send someone a report of all the stuff that gets depoyed [sic] once, which items are deployed always etc..., and maybe also being able to export it as an image (long one) with all the settings

I'm happy to share a quick way to get such a report today! The TDS project file (`.scproj`) is just an XML file and the deployment properties are stored in that XML. We can simply run an XSLT transform on the TDS project file to get what we want.

I've put this XSLT file in a Gist. Please help make it better!

Run this XSLT through your favorite XSLT processor (download msxsl.exe from MS if you need one)

Here are the results.

Sitecore needs a NuGet feed for their assemblies

Mon, 04 Aug 2014 21:14:00 +0400

This is a call to action for Sitecore to start hosting a NuGet feed of all common Sitecore assemblies. However, lets take a look at how the Sitecore development process has changed over the years.

Historically, Sitecore told developers to work in the 'web root'. This meant that you had direct access to the Sitecore assemblies as they were already in your bin directory. Some developers would even go so far as to check the entire Sitecore application, along with their code, into source control (yuck!). Some more advanced shops had very complex processes in place to 'stand up' up a Sitecore instance (think Sitecore SIM) before deploying custom code. Builds and deployments of Sitecore sites were typically very haphazard consisting of developers building locally, xcopy code deployments, and manual Sitecore package creation and installation. There weren't many developers writing 'shared source modules' back then either. Developers who were doing it were working in a Sitecore provided SVN system. They built their module, created a Sitecore package and checked it in to SVN.

So what has changed over the last five years?

Team Development for Sitecore (TDS) (Sitecore serialization and other ways to source control your Sitecore items)
While Sitecore hasn't officially changed their stance about 'working outside of the web root', John West and a majority of the community has accepted it as best practice.
There are A LOT more Sitecore developers creating modules these days.
Git[Hub] has become the De facto standard for open source projects.
Sitecore has gotten out of the SVN hosting business; they created the Marketplace to aggregate modules.
Visual Studio changes (extensions such as Sitecore Rocks, Package web, Slow Cheetah, etc...)
Web Deploy technologies
Build (and deploy) server availability and adoption
NuGet

Let us consider the current process of developing an open source Sitecore Module.

The general approach, for me, would be to create a VS solution with a Web App project and a TDS project. I'd grab Sitecore DLLs from somewhere else on my system, copy them to my code workspace and put them in a 'lib' folder. I'd make the appropriate references to these libraries and begin coding. When I was all done, and ready to put the code in the public domain I'd have to remember to not commit the Sitecore DLLs and add a ReadMe telling other developers to add them. In fact, GitHub is filled with ReadMe files saying “grab the sitecore.kernel.dll from your Sitecore installation”. This is sooo 2009.

Now, once the code is up on GitHub, I would ideally have some automated build process that will build each commit that happens and make the module available to everyone. There are plenty of build server options out there these days (hosted TeamCity, Jenkins, VS Online, AppVeyor, etc...) and there really is no reason to not have this in place – except for the little problem of the build server not having easy access to the required Sitecore DLLs! Obviously, the thing that is building your code requires the dependencies; however, if we can't put the Sitecore DLLs in the source control repo, what are we to do?

Sitecore has the ability to fix that problem by 'simply' providing a NuGet feed of their assemblies! NuGet isn't going anywhere. In fact ASP.NET VNext (which is currently in CTP 2) is basically all package based. Rather than having a ReadMe file that tells the developer to go fetch the assemblies manually, the project should simply have a reference to a specific Sitecore NuGet package.

I understand that Sitecore may not want to make their assemblies publicly available on the main NuGet feed, so why not have a private feed? Hosting a NuGet feed is trivial or there are third party providers (as they know, since Sitecore Rocks is using one).

I've tweeted in the past asking for this, but a tweet has a short life. It is time to throw this out there to the community. Will, what I am proposing, make developing/building/distributing Sitecore sites and modules easier?

So what, you may ask, is the reason I bring this up again now? I'm glad you asked! There will be some upcoming blog posts outlining how I am revamping the build process for a Sitecore open source module.

TDS Code Generation Output Multiple Files

Mon, 08 Jul 2013 20:22:00 +0400

A very common feature request we get for Team Development for Sitecore at Hedgehog is that people want code generation to create a file per Sitecore template in their project. Currently, when TDS code generation runs it will create a single file with all of the code inside of it. Using partial classes it enabled developers to extend the class with their needs, in a separate file, all the while keeping the code generated part in a file that can be overwritten and updated at any time by TDS. This is very much like the way Linq-to-SQL works.

While I can't say that this feature will ever be fully implemented and supported I've decided to release an example of how you can get this functionality now. Let me stress that this is not supported by Hedgehog Development and use at your own risk.

The provided sample below (and https://gist.github.com/seankearney/5957503) can be added to your TDS project. When TDS generates code for the project this template will output the transformation to a file located underneath the

[TDS Project]\Code Generation Templates\MultipleOutputs

folder.

There are a few key pieces to this T4 template.

Line 1 - The template definition requires a 'hostSpecific="true"' attribute
Line 92 - There is a "SaveOutput" method that handles the creation of the directory structure and writing of the files.
Line 79 - Before the first "class feature block" we call the SaveOutput() method.
Line 114 - This prevents the normal TDS code gen process from rendering the transformation in the main file. Uncomment this line to generate the code in the main file and individual files.

When using this template be aware that you will likely start seeing orphaned files. Code generation will happily create the files for you, but when you delete a template from your TDS project the previously generated file will not be removed. Also remember to not modify the generated files as TDS will re-write those files and your manual changes will be lost!

TDS And Duplicate Items

Thu, 18 Apr 2013 16:17:00 +0400

From time to time we get feature requests for Team Development for Sitecore to support multiple sub-items with the same name as shown below.

- sitecore
    - content
        - home
            - article-1
            - article-1
            - article-2

This topic has been discussed internally at Hedgehog for the last few years and unfortunately it is a feature that we don’t plan on supporting. The reality is that we can’t find a good reason to ever have items at the same level with the same name. Examples would be:

Fields of a template with the same name: the field wouldn’t be accessible by its name since there are multiple
Templates with the same name: Again, using the Sitecore API you wouldn’t know which one you are getting
Content with the same name: There would be a single URL addressing two pieces of content. You wouldn’t know which one is served up.

There are a couple of cases where we hear requests for duplicate item support.

The ‘Divider’ items in the ‘core’ database
When there are issues with the actual items. An example of this would be somehow a template has multiple ‘__standard values’ items and the customer reports the problem. However, the problem in this case is actually in their Sitecore database and the extra item should be removed. Therefore, having lack of support for duplicate item names actually helped find a problem for them!

For times when people request support for duplicate item names in order to handle the ‘Divider’ issue we tell them to rename the dividers in the core database. The name of the ‘Divider’ item is irrelevant and if you rename them to Divider-1, Divider-2, etc… it will work as expected and TDS will not complain.

We have also worked with Sitecore about the ‘Divider’ issue and they said they will try to make the renames as part of a future release.

If you, or your colleagues, can come up with a good business reason to have duplicate item names in a Sitecore installation please let us know!

Update 12/3/2013
As of Sitecore 7.1, the dividers in the core database have been renamed so that they have unique names! http://sdn.sitecore.net/products/sitecore%20v5/sitecore%20cms%207/releasenotes/changelog/release%20history%20sc71.aspx See 381310

The Twitter Sitecore Scrum

Fri, 08 Mar 2013 15:32:00 +0400

Dan Galvez and I had come up with an idea for a, sort of, Twitter based Sitecore Scrum. In essence, people would post on Twitter what they are doing today with the hashtag #SitecoreScrum. Interestingly, another Sitecore developer (Mike Reynolds) started this exact same thing the very next day with this tweet. I’ve reached out to Mike and we are going to try and keep up with a daily #SitecoreScrum at 10am Eastern time. I don’t know what will come of this, but it can’t hurt knowing what others in our realm are doing with Sitecore.

I realize actually committing and sticking to these daily tweets is tough, but I would appreciate any Sitecore developer with a Twitter account to do it; it shouldn’t take anyone too long to type 140 characters.

If you use a multi-column Twitter client then take a moment and setup a column for the #SitecoreScrum search to keep tabs on one another! If the web interface is your thing, then setup a saved search. Alternatively, we can look to use a tool such as http://taghuddle.com/sitecorescrum to aggregate the hashtag.

Here is an ICS file you can add to your calendar to remind you! Twitter-Sitecore-Scrum.ics (3.43 kb)