• CSS friendly HTML from Server Controls by default.
• EnableViewState does not work as you expect in ASP.NET 2.0. With the new ViewStateMode property with values: Inherit, Enable and Disable you get what you expect.
• ClientIDMode with value Predictable generates shorter ID attributes and possible for humans and javascript developers to handle.
• I think Auto-Encoding is going to be valuable for EPiServer Developers. The Auto encoding blocks “<%: … %>” and the IHtmlString marker interface that ensures you do not encode a string twice.
• For SEO there are properties on Page class for MetaKeywords and MetaDescription. Also support for both 301 and 302 redirects and Routing gives Friendly URL instead of path to aspx-files.

And much more at Dinos blog…

This evil code is then executed in the browser by your sites’ ordinary visitors. Scripts can steals passwords (maybe your own admin account), trick the user to give up other senestive data or download malvare because they trust your site.

This kind of security vulnerability is reffered to as XSS or Cross Site Scripting. 

Always have input validation and filter you input

A common aproach is to sanitize the data with a whitelisted or blacklisted characters to eliminate dangerous characters before storing or using the data. Another, is to always html encode data when it is rendered.  But it is harder than you think to get it right!

70 ways to write the same character

So you think you are smart and have a string replace or regular expression that removes “<” from the user’s input on your website to be safe? I guess you need to test again… I had too!

Did you know that there is 70 diffrent ways to write the “<” character in html? Read Robert Hansen’s good cheat sheet that lists known XSS attacks to get scared and take the problem serionsly.

Sometimes you can see a Yellow Screen of Death telling you that you application tries to use a version of an assembly that you know that you do not want to use. But why?

Visual Studio add <assemblies> to web.config

This can be a problem if you have several different versions of an assembly installed in the GAC at the same time. Under some conditions Visual Studio thinks that you must add references to assemblies to be able to successfully compile your asp.net files. Unfortunately the added references have the opposite effect – nothing compiles!

    <compilation defaultLanguage="c#" debug="true">  
      <assemblies>  
         <add assembly="EPiServer, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>  
         [ . . . ]  
      </assemblies>  
    </compilation>

As you know your asp.net files (global.asax, aspx-files, etc) are parsed and converted to C#-code that is then compiled with the C#-compiler when first accessed. The assemblies added in the <assemblies>-tag are added as references in the same way as you add references to a normal project in Visual Studio. You risk getting file not found errors or strange compilation errors. Since these references are parameters to the compiler, binding redirects in the runtime tag in web.config has no effect.

Tip: Remove the whole <assemblies>-tag or at least all EPiServer references.

Visual Studio adds <%@ Register %> to your markup

Another place where you can get references to unwanted versions of assemblies added by Visual Studio is in you markup. Automatically added <%@ Register %> with strongly named references to assemblies will sooner or later cause problems for you. With strongly named I mean assembly names including version number and public key. If it is just a name it will load whatever version that is placed in your bin-folder.

Tip: Always delete "<% @ Register TagPrefix ="EPiServer" … %>" from you markup.

The import of EPiServer controls are handled elsewhere. Take a look at the <pages><controls>-tag in your web.config and you will understand. This also has the side effect of making most of EPiServer classes available in front-end code without adding the <assemblies>-tags.

Tip: Consider adding you own controls to the <pages><controls>-tag in your web.config instead of adding a <%@ Register %>-tag on every page.

Tip: Remove the version number and public key from the assembly attribute.

Use <bindingRedirect> in your web.config

The key to be able to use a new version of an assembly without recompiling everything is the <bindingRedirect>-tag in web.config. EPiServer Manager updates this part of your web.config when you upgrade your site.

  <runtime>  
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="EPiServer" publicKeyToken="8fe83dea738b45b7" culture="neutral"/>
        <bindingRedirect oldVersion="5.0.0.0-5.65535.65535.65535" newVersion="5.1.422.4"/>
      </dependentAssembly>

FileLoadException

Sometimes it is not obvious why an assembly fails to load. Turn on logging in Fusion to get more information that might help you track down the issue. (Fusion is the name of the part of the dot net framework responsible for loading assemblies)

There is a property on System.IO.FileLoadException called FusionLog that contains details on why an assembly failed to load. The content of this property is displayed on the Yellow Screen of Death.

Tip: Enable assembly binding logging use Fusion Log Viewer (Fuslogvw.exe) or set the registry value EnableLog in HKLM\Software\Microsoft\Fusion to 1. Note that you have to restart your application (use iisreset) for the changes to have any effect.

Tip: Remember to turn off fusion logging when you are done since there is a performance penalty to have it turned on.

EPiServer PlugInException

Sometimes the FileLoadException is an inner exception of another exception so the Yellow Screen of Death does not show the details from the fusion log. This is a quite common scenario for EPiServer since the first thing that happens when the application start is that EPiServer loads ALL assemblies in the bin-folder and searches for PlugIn-attributes.

Tip: In these cases you can change the setting in the Assembly Binding Log Viewer to "Log bind failures to disk" and get all the details you need to track down the issue. I also recommend using a custom log path.

Fix your references by editing your csproj-file

Finally, take a look at your csproj file using notepad (or unload the project in Visual Studio to be able to open it as text). When you add references using Visual Studio you will get a assembly reference with both version number and public key and this can give you some trouble when you upgrade a vendor assembly to a newer version.

    <Reference Include="StarSuite.Core">  
      <SpecificVersion>False</SpecificVersion>  
      <HintPath>..\Lib\StarSuite.Core.dll</HintPath>  
      <Private>True</Private>  
    </Reference>

Tip: Edit your csproj-file as text and keep only the assembly name. When you have removed the version and public key.

Tip: Create a Library-folder and store a copy of all references assemblies. It can be very nice to have if Visual Studio decides that it want to clean the bin folder and removes files that you need there.

If you put web.config under version control and would prefer if changes to singe attributes are easy to detect with a diff tool, this is not the optimal.

It is possible to change formatting in Visual Studio to get one attribute per line and that works much better for text diff tools. (This requires that you do your changes with Notepad or Visual Studio and not use EPiServer Manager or the Admin Mode to change the settings.)

Go to Tools -> Options -> Text Editor -> XML -> Formatting and select “Align attributes each on a separate line”

Click Edit -> Advanced -> Format Document (or Format Selection if you only want to adjust a part of the file) before you check in your web.config to reformat.

Voilà! Your web.config is readable!

(See also discussion in EPiServer Developer Forum)

The usual sollution to this is to to either use a feedback form (that do not use the mail address in clear text as a parameter) or a use a Captcha to reveal it.

I found a new good Captcha service and API that I would like to recommend: http://mailhide.recaptcha.net/

Here is an example of how it could look like using my e-mail address:
fred???@inexor.se

EPiServer is using this for its own need to store information on a per user basis. (The built-in values EPiServer needs are accessible through the class EPiServerProfile that is a subclass of the ASP.NET class ProfileBase).

You can get access to the current users EPiServer’s Profile instance accessing the static property Current on the EPiServerProfile class. There is also a default indexer property inherited from ASP.NET’s ProfileBase class that you can use for you own values.

EPiServer.Personalization.EPiServerProfile.Current["MySetting"] = "Test123";
			

For performance reasons use only string, int, DateTime and avoid objects that must be serialized. There is also support for handling anonymous users (not logged in) if needed.

Read more: http://msdn2.microsoft.com/en-us/library/at64shx3.aspx

Update: Read more about changes to Profile information in SP1 for EPiServer CMS 5 R1.

Today it happened again. I noticed that I could not recompile my application because the new textbox I added to my ASPX-file did not appear as a member in the corsponding designer.cs-file.

First, I double check that I installed SP1 for Visual Studio 2005 so I have the latest version of Web Application Projects.

The Usual Trick

When this happens it is in most cases an indication of a syntax error in the ASPX-file. In many cases you get so many strange errors and warnings in Visual Studio’s Error List so you do not understand what is wrong. A quick way to get a good error message and be certain that the designer.cs-file is in sync is to first delete it and then regenerating it by right-clicking the ASPX-file in the Solution Explorer and selecting “Convert to Web Application”.

This works in most cases. Either you will get an error you will understand how to fix or it just regenerates the designer.cs-file for you.

Permanent Frustration

Sometimes you will fail to generate the file and nothing you do seem to help. Everything is in order. No syntax errors in the ASPX-file. It just refuses to regenerate the designer file because it cannot find component X.

Obviously I’m not alone getting this problem. I’m not sure why it stops working but I guess part of the problem is related to the ASPX-file must be parsed first and something is wrong with the environment.

Tim McBride on the ASP.NET team hints how to get more information by turning on debugging for Web Application Projects.

REGEDIT4
[HKEY_CURRENT_USERSoftwareMicrosoftVisualStudio8.0WebApplicationProjectsDebug]
"LogFile"="C:logfile.txt"
"Enabled"=dword:00000001"
LogFieldGeneratorFailures"=dword:00000001

And with a call stack we have more information where it goes wrong:

System.Web.HttpParseException: Unknown server tag 'EPiServer:Property'.
   at System.Web.UI.TemplateParser.ProcessError(String message)
   at System.Web.UI.TemplateParser.ProcessBeginTag(Match match, String inputText)
   at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)
   --- End of inner exception stack trace ---
   at System.Web.UI.TemplateParser.ProcessException(Exception ex)
   at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)
   at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)
   --- End of inner exception stack trace ---
   at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)
   at System.Web.UI.TemplateParser.ParseInternal()
   at System.Web.UI.TemplateParser.Parse()
   at System.Web.UI.DesignTimeTemplateParser.ParseTemplate(DesignTimeParseData data)
   at Microsoft.VisualStudio.Web.Application.Parser.Parse()
   at Microsoft.VisualStudio.Web.Application.Generator.UpdateDesignerClass(String document, String codeBehind, String codeBehindFile, String[] publicFields, UDC_Flags flags)

ProcessBeginTag cannot map a tag to a control. The tag EPiServer:Property control is not registered on the page but in the <system.web><pages><controls> section in web.config. This indicates that something fails either in TemplateParse.PrepareParse when trying to get hold of the RuntimeConfig or in Microsoft.VisualStudio.Web.Application.Parser.ParseConfig when it tries to get to web.config through the designer host.

Adding a Register directive manually to the Page will remove the first error and reveal another.

System.Web.HttpParseException: The expression prefix 'Resources' was not recognized.  Please correct the prefix or register the prefix in the <expressionBuilders> section of configuration.
   at System.Web.Compilation.ExpressionBuilder.GetExpressionBuilder(String expressionPrefix, VirtualPath virtualPath, IDesignerHost host)
   at System.Web.UI.ControlBuilder.AddBoundProperty(String filter, String name, String expressionPrefix, String expression, ExpressionBuilder expressionBuilder, Object parsedExpressionData, Boolean generated, String fieldName, String formatString, Boolean twoWayBound)
   at System.Web.UI.ControlBuilder.PreprocessAttribute(String filter, String attribname, String attribvalue, Boolean mainDirectiveMode)
   at System.Web.UI.ControlBuilder.PreprocessAttributes(ParsedAttributeCollection attribs)
   at System.Web.UI.ControlBuilder.Init(TemplateParser parser, ControlBuilder parentBuilder, Type type, String tagName, String id, IDictionary attribs)
   at System.Web.UI.ControlBuilder.CreateChildBuilder(String filter, String tagName, IDictionary attribs, TemplateParser parser, ControlBuilder parentBuilder, String id, Int32 line, VirtualPath virtualPath, Type& childType, Boolean defaultProperty)
   at System.Web.UI.TemplateParser.ProcessBeginTag(Match match, String inputText)
   at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)

The code in GetExpressionBuilder gives the same indication and strengthens my suspicion that the parser fails to get hold of any configuration at all since the <expressionBuilders> tag is in the global web.config.

I’m too tired to continue the hunt for the real reason tonight but I did test one final thing:

1. I shut down the IIS service and close Visual Studio.
2. And then do I delete all files under “Temporary ASP.NET Files”.
3. I restart Visual Studio and re-open the Project.
4. I change Project Settings to use Visual Studio Development Server instead of IIS.
5. Finally do I click “Convert to Web Application” and this time it generates without errors…

Why? Maybe you know… Please, leave a comment if you have any clues!

I have tried to figure out why a customer get a strange error message on their ASP.NET web site that stops the whole site from working until you restart the whole IIS.

The exception “The WebResource.axd handler must be registered in the configuration to process this request” occurred quite randomly at first sight. After some investigations I found that the site usually stopped working if you called some of the pages immediately after a restart of the web application. This happens for example when you change in web.config but an unload of your AppDomain can be triggered by other mechanisms, too.

I found no clues to the cause when I searched on the error message, only a lot of question and other desperate people.

Looking closer at the call stack and browsning around with Roeders Reflector I found that the cause of our problem with WebResource.axd is in the method EnsureHandlerExistenceChecked in the class System.Web.Handlers.AssemblyResourceLoader:

As you can see in the code above, if the test fails once it will never re-test since handlerExistenceChecked is true and the site will stop working forever.

This check is called for several reasons. One of them is because components like the RequiredFieldValidator uses the ClientScriptManager to insert links on the page to JavaScript that is embedded inside a resource in an assembly somewhere. To make the resource available from the browser the generated link contains a reference WebResource.axd that is registered as a HttpHandler in machine.config redirecting calls with that filename to the AssemblyResourceLoader class.

The only way to recover from the error I have found is to stop the site, run iisreset /restart and wait for a while before you start the site again.

I have not manage to find the exact reason for why the test fails initially. I have some theories but they are hard to validate since used classes and methods are private or internal. One guess is that FindMapping returns null because the HttpHandler collection has not yet been loaded. Another guess is that HttpHandlerAction has not been correctly initialized so TypeInternal is null. It could even be possible that there is a problem with the type system (because ASP.NET applications unloads the AppDomain, generat assemblies dynamically and loads them, etc) so you actually have two instances of the same underlying system type making the Equal operator give an incorrect result.

It really does not matter why it does not work since we can not patch Microsoft’s framework ourself or wait for a hot fix. If anyone else has some clues or have done some research on this problem, please let me know!

My workaround to recover from the error is to use reflection to clear one of the private static flags so it re-runs the test. (Use of reflection like the requires that your application does not run with a low trust level so it might not work everywhere.) Since it is expensive to use reflection I only run the check in the Error event handler in my Application object.

Any feedback is appreciated.

Download example code here.