Back to basics: Versioned, Unversioned and Shared fields

It is well-known that each field of a template can be versioned (default option), unversioned or shared. The Template Builder UI exposes the Unversioned and Shared properties as two independent checkboxes. And thus, despite it’s a very basic Sitecore concept, it is sometimes asked what’s the point of marking a field both shared and unversioned. The answer is “a field marked both shared and unversioned is still a shared field”. Think about “shared” as a superset of “unversioned” – the field can’t be shared (between all versions of all languages) without being unversioned (between all versions of one language).

Let’s see how it works under the hood when the field “sharing” level is changed. Let’s create a simple template with just a single field. We’ll keep the defaults so far (versioned). Now create a content item based on this template and fill in the field.

Sitecore fields are stored in three different tables inside the database: VersionedFields, UnversionedFields and SharedFields. The names are quite self-explanatory. Let’s run the following SQL query:

      SELECT * FROM VersionedFields WHERE FieldId = '{GUID-GOES-HERE-…}'

As a result, one record is returned – the field information of the item we’ve just created is stored in the VersionedFields table. The similar queries for UnversionedFields and SharedFields give 0 records.

Now change the field to be Unversioned and run all 3 queries again – it will return 1 record for UnversionedFields table and 0 for others. Change the field to be both Shared and Unversioned and repeat the experiment – the field info now resides in SharedFields table. Now if you uncheck Unversioned and leave it just Shared, it will still show 1 record for SharedFields table and 0 for others. So, here’s the evidence!

NOTE: changing the field “sharing” level might result in a data loss (similar to type cast operation in C#), and Sitecore warns you about it.

You might think that two checkboxes are to be blamed for this confusion. Check out the hot VS extension called Sitecore Rocks – a brand new tool (CTP for now) for developers working with Sitecore projects in VS 2010. It seems to look more natural in this way, isn’t it?

Torch.exe confuses the language validation and ProductCode validation

This week I faced with another issue with torch.exe. As you might know, there’s a “type” option (-t) to apply a predefined set of validation flags to the generated transform. If you’d like to generate a language transform, you should use “-t language”. It should suppress all the errors plus validate that language in both MSI packages corresponds. But it doesn’t…

The reason is just a simple bug in the tool. When you set “-t language” in the command line, this option is mapped to the TransformFlags.LanguageTransformDefault value. It is a combination of atomic values (those you can set via –serr and -val), and it mistakenly takes “validate product code” bit instead of “validate language bit”. I’ve never noticed this unless my installation uses both instance transforms and language transforms.

The workaround is quite simple: use literally “–serr” and “–val” to achieve the same result. For instance, for language transform it should be:

       torch.exe … –serr a –serr b –serr c –serr d –serr e –serr f –val l …

[By the way, does it look too long just for me? I would prefer –serr abcdef :-)]

I’ve also filed an issue to the WiX toolset. Hope this can help somebody.

Torch.exe throws scary error message unrelated to the real problem

Today I’ve been working on the localization of my installation project, and I had to create a number of language transforms. The following simple call of torch.exe

            torch -t language setup.msi setup_ru-ru.msi -out mst\ru-ru.mst

returned the scary error message:

            error TRCH0001 : The Windows Installer service failed to start. Contact your support personnel

I’ve seen this kind of errors a couple of times, and it was a serious problem with Windows Installer engine on the target machine in all cases. Once, it indicated that Windows Installer service is completely broken, and only OS reinstall helped (fortunately, it was virtual PC)… But mighty Google gave a single, but exact hint. It is just a single line, and one can miss the point since that’s another problem which is discussed there.

So, the actual problem: if –out switch points to a folder which doesn’t exist (‘mst’ in this case), torch.exe can’t create it and returns the error. That’s okay behavior to live with, but the error message should be changed to something more appropriate: “The folder ‘mst’ can’t be found. Make sure it exists before referencing in –out switch”. I’ve also created an issue to the WiX inbox at sourceforge.net.

Hope this info is helpful until the message text is fixed.