Helix Publishing Pipeline - file locks issue on deploy

On my last project when I was implementing Helix Publishing Pipeline I found really bizarre issue. Almost every time I was deploying code by publishing it from Visual Studio, some dlls were locked by w3wp process.

No surprise IIS uses those assemblies but I didn't have such locking problem earlier.

I was digging for hours in the Internet and I found out that IIS uses assembly shadowing. So basically it doesn't use directly dlls from webroot bin, but from its the temp folder.

It can be disabled by this setting

<hostingEnvironment shadowCopyBinAssemblies="false" />

When I set this for test, file locks were all over the place.

Earlier I used Process Explorer and I saw that w3wp locks not only shadowed dlls but as well those from webroot bin, so something was not right there!

More digging eventually gave me information that our issue was self-inflicted: https://stackoverflow.com/a/28019475

In GlassMapperScCustom assemblies were loaded by invoking method

Assembly.LoadFile(assemblyPath) 

which loads exact assemblies and it doesn't take into account shadows.

Instead of that we should always use

Assembly.LoadFrom(assemblyPath) 

which loads shadows as it should be.

That fixed issue with file locks for good!

Read More

Azure Search provider - Results ordering issue

I was implementing Azure Search lately into my last project and I found some strange issue in the provider (we're using Sitecore 9.0.2 rev. 180604). When I wanted to order my search results using Linq like this:

searchQuery.OrderBy(x => x.JobRole).ThenBy(x => x.LastName)

it was translated to:

$orderby=last_name_s,job_role_i

So it looks like it's taking argument of ThenBy as first and OrderBy as the second. Inverting parameters:

searchQuery.OrderBy(x => x.LastName).ThenBy(x => x.JobRole)

gave me desired query:

$orderby=job_role_i,last_name_s

And search result as well were sorted like I wanted.

Azure Search documentation states nothing unusual, but I had to confirm this:

$orderby=[string] (optional)

A list of comma-separated expressions to sort the results by. When calling via POST, this parameter is named orderby instead of $orderby. Each expression can be either a field name or a call to the geo.distance() function. Each expression can be followed by asc to indicate ascending, and desc to indicate descending. The default is ascending order. Ties will be broken by the match scores of documents. If no $orderby is specified, the default sort order is descending by document match score. There is a limit of 32 clauses for $orderby.

https://docs.microsoft.com/en-us/rest/api/searchservice/search-documents#orderbystring-optional

I have raised an issue on Sitecore Helpdesk and guys from support checked and reported the issue. It has a reference number 309333. Current resolution is to invert parameters like I did.

Read More

Issue with Final Layout and Experience Editor: The layout for the requested document was not found

Recently I have found some bug with Sitecore 8.1 Update-2 and Experience Editor.

When I add some rendering and save the page, it appears and it's all ok. But when I remove it and save, I am getting this error:

The layout for the requested document was not found

Also all Final Renderings are gone:

I have found out that when I edit 'Final renderings' field by hand, save it, and then remove all contents of this, the same issue appears.

I am resolving it by resetting the Final Layout. I think it may be some inconsistency with checking null or empty string.

I also find out that this case is known issue: https://github.com/Sitecore/Habitat/issues/136
With public reference number 108023

I have asked support about  this issue and I get a fix for that. Unfortunately it didn't help me.
However I also got an information how to workaround this issue.

There is a "Reset blank" checkbox field in __Final Renderings item. It is located in
/sitecore/templates/System/Templates/Sections/Layout/Layout/__Final Renderings
Purpose of this option is to reset field value to default when saving field is set to empty value.

And the information that I got from Support:

This is very handy in situations where it doesn’t make sense to have the field blank. And, as the initial issue led to erasing the contents of the __Final Rendering field, ticking this checkbox allows Sitecore to use the Standard Values of the item's template. And this fixes the issue.

 Hope this will be helpful for someone :)

Read More