Sitecore Coveo Search Resource Component and Dictionary Items


Recently, I am working on a bug reported by one of our tester. The issue stating none of the Coveo pages on few of the SXA websites working post upgrade of Coveo SXA module.

The Issue

The website suddenly started showing error message “The component is not available at this moment. Please contact the site administrator.” under Coveo’s Search Resources Component on the website pages.

Strangely, the same functionality(or rather I say partial design) used by other SXA website are working like charm. But only 2 websites which has whole Coveo Search functionality has been broken.

The Finding

First obvious thing I did was open the Google and search for the error message. After some time spending on reading multiple blogs and articles, I come with this link on Coveo’s articles.

As Article suggested, I have verified both the conditions, firstly checked extranet/Anonymous(user and domain configure with Site Definition) has read access to both Sitecore/System/Dictionary items and additional dictionary item configured at the Coveo Search Resource Data source item. Secondly, checked we have correct dictionary item selected under the field Additional Dictionaries for Coveo Search Resources item configured as data source to respected UI component.

Now, I was trying to isolate the issue, to make sure the issue is due to either dictionary or its child items. So, I tried to remove the dictionary item form the additional dictionary field, publish the item and magically all the broken Coveo Pages started working…!!!

So now, I am sure there is something to do with the dictionary item for that SXA website.

The Solution

I started decoding the Coveo Search Resources SXA UI component and found the logic for getting the component properties have a validation which validates the unique dictionary keys under the selected dictionary.

This is a great lead…..!!!(it took me fair few hours of dotPeeking to find this out) That left me with great confidence that there are some dictionary entry item which has the duplicate value in the Field Key.

I did first obvious check of unique item name by turning validation rule on via Sitecore’s Content Editor’s left gutter.

But none of the dictionary entry items have duplicate name. So now, I need to relay on my Poweshell skills to find the duplicate value on Key field of item /sitecore/templates/System/Dictionary/Dictionary entry.

I did created and executed the script to find the duplicate value in the field and found there is one entry under the dictionary which has exact same value present in the Key Field.

I removed that unwanted entry item which is lately added by one of the content editor while copying dictionary entries from older SXA website to the new one.

Happy Coveo Sitecore search…!!!

References

https://connect.coveo.com/s/article/7419?

Sitecore Launchpad icons missing


Recently, I am working on an upgrade project (which you must have been knowing if you read few of my recent blogs) and we encountered one very weird issue on Sitecore CM.

The Issue

After successful login to CM, the Launchpad is not showing any icons.

The Solution

First obvious thing I did was open the developer toolbar and inspected the icon image requests under the network tab and it was looking like below image.

All the request to icon images were getting HTTP500 internal server errors. Also observed that .aspx extension is being added at the end of the image extension. For example, /-/icon/LaunchPadIcons/48×48/desktop.png.aspx.

Just dig around the issue, and it turned out, we recently updated the Nuget page reference for the SharpZipLib library to the latest version 1.3.3 for one of the project in customization solution.

The OOTB(vanilla) Sitecore 10.2 also uses the same library but with different version of it.

We matched the version of ICSharpCode.SharpZipLib.dll with the version number come as Vanilla Sitecore Version 1.3.2 and magically all the icons on launch page started appearing again.

Happy Sitecore upgrade…!!!

Configure .Net Remote Debugging Service in Sitecore 10.2 Docker


Hi Sitecorians,

It’s been very long since, I last blog. But the wait is over and I am here with some of my learning while upgrading our Siteore platform from 9.3 to 10.2( latest and greatest). With this project, there are lots of learning and I’ll try to share it with you community.

The Issue

After deploying the customisation on top of the vanilla Sitecore 10.2 (huge applaud to Developers of Sitecore and the vibrant community to create and maintain the Docker sample repository), the first obvious step is to do a quick sanity test to check whether or not anything is broken??…. and the unexpected happens, one of the custom written pipeline code was complaining and logging errors in the CM log file.

So the next best handy tool for a developer in Dot Net world is the .Net debugger( thank God). While, I was trying to attache to w3wp process of CM container the following error appeared.

Unable to connect to the Microsoft Visual Studio Remote Debugger named 'XXX.XXX.XXX.XXX'.  The Visual Studio 2022 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging.

The Solution

As per the error message above, it’s clear, there is something not right with the MSVSMON.EXE.

Immediately fire up following PowerShell commands to look into running processes under the CM container.

PS> Docker exec -it <<CM Container name/id>> powershell
PS> Get-Process

The output of the Get-Process command was not showing any currently running process with name msvsmon. uuhhhh… that is the issue, I guess…!!!

So to get the .Net remote debugging working on the CM container, I did checked how we had it working in our 9.3 sitecore Docker Environment. Found 3 different steps to get it working. I wanted to document is in my diary but did not got chance. It is never to late.

Lets have a look at those 3 steps one after another.

Step 1.

Open the docker-compose.override.yml file, add below line under the volumes

 cm:
    image: ${REGISTRY}${COMPOSE_PROJECT_NAME}-xp0-cm:${VERSION:-latest}
    build:
      context: ./docker/build/cm
      args:
        BASE_IMAGE: ${SITECORE_DOCKER_REGISTRY}sitecore-xp0-cm:${SITECORE_VERSION}
        SPE_IMAGE: ${SITECORE_MODULE_REGISTRY}sitecore-spe-assets:${SPE_VERSION}
        SXA_IMAGE: ${SITECORE_MODULE_REGISTRY}sitecore-sxa-xp1-assets:${SXA_VERSION}
        TOOLING_IMAGE: ${SITECORE_TOOLS_REGISTRY}sitecore-docker-tools-assets:${TOOLS_VERSION}
    volumes:
     - ${REMOTEDEBUGGER_PATH}:C:\remote_debugger:ro
Step 2.

Next step to add the REMOTEDEBUGGER_PATH variable to the .env file. To do so open your .env file in VS Code or your choice of text editor and add below line to it.

REMOTEDEBUGGER_PATH=C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\Remote Debugger\x64

Now, you need to change the path of debugger folder in above with the VS version you are using. For, now I am using VS 2022 Professional but we have some developers still using VS 2019 Professional for them the path will be C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Remote Debugger\x64

Step 3.

Now, in the third and the final step, we will try to execute multiple processes at the entry point for CM container. To do so, I have added few commands to the existing Powershell entry point command.

 cm:
    image: ${REGISTRY}${COMPOSE_PROJECT_NAME}-xp0-cm:${VERSION:-latest}
    build:
      context: ./docker/build/cm
      args:
        BASE_IMAGE: ${SITECORE_DOCKER_REGISTRY}sitecore-xp0-cm:${SITECORE_VERSION}
        SPE_IMAGE: ${SITECORE_MODULE_REGISTRY}sitecore-spe-assets:${SPE_VERSION}
        SXA_IMAGE: ${SITECORE_MODULE_REGISTRY}sitecore-sxa-xp1-assets:${SXA_VERSION}
        TOOLING_IMAGE: ${SITECORE_TOOLS_REGISTRY}sitecore-docker-tools-assets:${TOOLS_VERSION}
    volumes:
      - ${REMOTEDEBUGGER_PATH}:C:\remote_debugger:ro
    networks:
      dev.local:
        aliases:
          - cm.dev.local
    entrypoint: powershell -Command "& Write-Host 'Starting Debugger Service...'; & Start-Process -FilePath 'C:\remote_debugger\msvsmon.exe' -ArgumentList '/nostatus', '/silent', '/noauth', '/anyuser', '/nosecuritywarn', '/wow64port 4026'; & C:\tools\entrypoints\iis\Development.ps1"

With the above alteration firstly, I am writing to host to get to know that it is trying to start debugger service and secondly executing MSVSMON.EXE file with few arguments as Start-Process powershell command.

With the argument wow64port mind that each Visual Studios have their own ports assigned as default debugging port for msvsmon.exe. See the references in section below.

Verification

As verification of both w3wp and msvsmon services running we need to check the output of Get-Process command on CM container

Note

Also make sure in the web.config of your CM container, the debug is set to true for compilation node. configuration/system.web/compilation[debug=’true’]

Note

Notice that I am using (;) semicolon as the command terminator for powershell command. If you are using CMD, use & (ampersand)

References

https://docs.microsoft.com/en-us/visualstudio/debugger/remote-debugger-port-assignments?view=vs-2022

https://ss64.com/ps/call.html

https://github.com/microsoft/DockerTools/issues/91