Skip to main content

Posts

FakeDb, Layout tests and Sitecore 9

Following the previous post on this blog involving an issue we ran into upgrading a Sitecore project from 8.2 to 9, this one is also on the same subject. The issue this time was some unit tests that make use of the FakeDb  library began to fail following the upgrade. Noticing that it was just tests that involved checking the status of layout related fields, with the help of some de-compilation, it was clear that a change had occurred in the Sitecore.Data.Fields.LayoutField.GetFieldValue method that now involve the use of a pipeline components. I found it was possible to resolve this by adding the following to the app.config file, within the &lgt;sitecore&ggt; element, for the test projects containing the failing tests: <pipelines> <getLayoutSourceFields> <processor type="Sitecore.Pipelines.GetLayoutSourceFields.GetFinalLayoutField, Sitecore.Kernel" /> <processor type="Sitecore.Pipelines.GetLayoutSourceFiel...

Unit testing HttpRequestArgs with Sitecore 9

Working on a project currently with Sitecore CMS, which is currently undergoing an upgrade to version 9. We had this piece of code, used in the context of unit testing classes that inherit from HttpRequestProcessor , such as custom page resolvers. To use these classes you override a method Process() that takes an instance of HttpRequestArgs . Constructing these classes from a unit test isn't straightforward and up to now had relied on a method detailed by James-West Sadler on his blog here . public static HttpRequestArgs CreateHttpRequestArgs(string url) { var httpRequest = new HttpRequest(string.Empty, url, string.Empty); var httpResponse = new HttpResponse(new StringWriter()); var httpContext = new HttpContext(httpRequest, httpResponse); var requestArgs = new HttpRequestArgs(new HttpContextWrapper(httpContext), HttpRequestType.End); // Reflection used to call the private Initialize method on the HttpRequestArgs obj...

Let's Encrypt on Azure Web Apps - Key Expiration Issue

I run a side-project website on Azure PaaS, for a music library business called The Perfect Music Library . For a year or so this has had an SSL certificate provided by Let's Encrypt . The certificates provided for this service expiry relatively quickly, and so in order to keep this updated I've set up and deployed a site extension and web job using the excellent instructions provided by Nik Molnar. Recently though I noticed that the most recent update had failed which meant browser warnings of an outdated certificate were being seen by visitors that attempted to access the site. It turns out the issue was a key that's created as a process of setting up a "service principal" (step 5 of instructions linked above) had expired after a year or so. To diagnose this I opened up the Azure portal, located the web application in question and navigated to the list of web jobs. Within that, right-clicking on the letsencrypt.siteextension.job allows the view of the...

Gotcha with Updating .Net Core Using VS.Net 2017

A little while back I put together a very basic ASP.Net Core application and blogged about my first impressions in transitioning from "classic" ASP.Net - can we call it that now?! - here . Just today thought would be a good idea to update it to the latest version, particular the change in the format of the project file from JSON (project.json) to XML (.csproj). With VS.Net 2017 this was very straightforward, but I found one gotcha that may or may not affect others, so thought would record it here. When opening the project - originally created in VS.Net 2015 - in VS.Net 2017 a message comes up saying a one-way update needs to happen. I let that complete and it ran successfully. Unfortunately after that VS.Net froze. Closing and restarting the application a few times didn't seem to help - after a few seconds the IDE became unusable and had to be stopped using Task Manager. The issue seemed to be with a hidden .vs folder that VS.Net creates, containing various de...