webconfig

Sitecore – The type or namespace name ‘WebViewPage’ could not be found

Andy BurnsLeave a comment

A gentle note to myself – If I suddenly start getting errors from Sitecore of the form:

Exception: System.InvalidOperationException
Message: Error while rendering view: ‘/Views/Common/Layouts/WebLayout.cshtml’ (model: ‘Sitecore.Mvc.Presentation.RenderingModel, Sitecore.Mvc’).

or

Exception: System.Web.HttpCompileException
Message: c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4f078900\f158f9a6\App_Web_weblayout.cshtml.b31435e0.agxyl06t.0.cs(44): error CS0246: The type or namespace name ‘WebViewPage’ could not be found (are you missing a using directive or an assembly reference?)

… check that you’ve not delete the /Views/Web.config file. Again.

I keep causing this when I clear out my Views folder of old, obsolete, or test views.

Advertisement
Sitecore – The type or namespace name ‘WebViewPage’ could not be found

NullReferenceException in Sitecore.ExperienceExplorer.Business.Pipelines .HttpRequest.EnableExperienceModePipeline.Process

Andy Burns, , Leave a comment

Recently I was upgrading a site to Sitecore 8.2.1, and I received the following error:

Okay, WTF? There’s not a lot of information about this error, and I’d never seen it before. I ended up doing my usual trick – decompiling Sitecore to see what this method does. Here’s what I found…

…and the bit underlined in red set my “stupidity radar” screaming. This line is:

string database = SiteContext.GetSite(Settings.Preview.DefaultSite).SiteInfo.Database;

If GetSite() returns null, you’ll get a null reference exception, because they didn’t bother to check the returned variable before trying to use its ‘SiteInfo’ property.

It does offer a clue, though. Our upgraded system lacks a site called ‘website‘. That is, in our config, under the <sites> node, there is no <site ... > called ‘website‘. However, the DefaultSite setting in Sitecore.config still had its default value of ‘website‘.

We changed it to the name of our site, and this error was resolved.

NullReferenceException in Sitecore.ExperienceExplorer.Business.Pipelines .HttpRequest.EnableExperienceModePipeline.Process

Awkward Page Request Validation in Sitecore

Andy Burns, Leave a comment

I was configuring a new Sitecore 8.1 instance. It’s a vanilla, straight-off-the-installer instance, and yet I noticed that the node’s request validation was off:

<pages validateRequest="false">

This did, at least, come with a comment above it:

If requestValidationMode attribute of httRuntime node is set to 2.0, Sitecore requires this setting to be set to “false” for Sitecore client to work and it shouldn’t be changed. You can however set ValidateRequest attribute in the @Page directive to “true” for your layout .aspx files.

This is bonkers. The default configuration for this site is to remove request validation on my brand new Sitecore instance on the off-chance I should want to configure it to use an older, non-default requestValidationMode. Instead, I should stumble across this comment in the web.config file and add the appropriate attribute to all the layouts of my solution. And someone thought that this was a good idea?

Even if I were upgrading and I did rely on the httpRuntime requestValidationMode being 2.0, I would prefer that this was set to true, with instructions for how I should handle it in the case of an upgrade.

Crazy. One to be aware of.

Awkward Page Request Validation in Sitecore

Disable trace.axd

Andy Burns, Leave a comment

This is annoying misconfiguration I’ve come across a few times – tracing has been enabled on production systems.

Having tracing enabled allows an attacker to view the last 50 web requests made to the server, including information like Session ID values and the physical path to the requested files.

Nasty.

One can easily turn this off, though, by setting the <trace> node of web.config…

<trace enabled="false"...

However, you can do a bit more than that. I believe that this problem occurred on live sites because configuration files were promoted from development to production. To this end, you can set localOnly="true" – this means that trace is only available on the local developer’s machine. This doesn’t substitute for disabling trace, but it does help reduce that risk.

Disable trace.axd