ZeroSharp

Robert Anderson's ones and zeros

Replacing a Class at Runtime Using Ninject and Roslyn - Part 3: Dependency Injection

| Comments

This is the third part of a series about using Roslyn with dependency injection to create a flexible and powerful plug-in framework. Here I review the parts of the solution that deal with dependency injection. Check out the working example on GitHub.

Previously

Dependency injection

The first trick is to use dependency injection to create any instance of the HelloWorldGenerator class. Then if we need to add a new dependency to the class, we can just add it to the constructor without breaking anything.

HelloWorldGenerator.cs
1
2
3
4
5
6
7
8
9
public class HelloWorldGenerator : IGenerator
{
    public HelloWorldGenerator(
        ISomeDependency dependency,
        IAnotherDependency another,
        INewDependency new // a new dependency!!!)
    {
        ...
    }

We’ll use Ninject here, but you ought to be able to achieve the same with any dependency injection framework.

So normally, we’d have a binding something like:

1
Bind<IGenerator>().To<HelloWorldGenerator>();

Instead we’ll replace this with a binding to a factory method instead.

1
Bind<IGenerator>().ToMethod(context => CreatePluginInstance(context));

The CreatePluginInstance(context) method will try to find an IGenerator class within any available plug-ins. If it finds one, it will ask the Ninject framework to create an instance of the plug-in class. Otherwise it falls back to the default type (the original implementation of the generator). The PluginLocator it is responsible for searching any runtime-compiled assemblies for candidate plug-ins. We’ll look at it in more detail later.

1
2
3
4
5
6
7
8
9
10
11
private IGenerator CreatePluginInstance(IContext context)
{
    var pluginLocator = context.Kernel.Get<PluginLocator>();
    Type roslynPluginType = pluginLocator.Locate<IGenerator>();

    /// if we found a plug-in, create an instance of it
    if (roslynPluginType != null)
        return (IGenerator)context.Kernel.Get(roslynPluginType);
    else ///otherwise create an instance of the original implementation
        return context.Kernel.Get<HelloWorldGenerator>();
}

By convention

Of course, you might have dozens of IGenerator descendants, in which case you can use Ninject’s convention-based binding module. (Don’t forget to add it with NuGet). My version looks something like the following.

1
2
3
4
5
6
7
8
9
10
11
/// If you have a lot of IGenerator subclasses, you can use Ninject's
/// convention based module.
/// 
///   For each Generator, bind to IGenerator. 
///   For example, Bind<IGenerator>.To<SomeGenerator>();
/// 
Kernel.Bind(scanner => scanner
    .FromThisAssembly()
    .SelectAllClasses()
    .InheritedFrom(typeof(IGenerator))
    .BindToPluginOtherwiseDefaultInterfaces()); //This is a custom extension method (see below)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public static class ConventionSyntaxExtensions
{
    public static IConfigureSyntax BindToPluginOtherwiseDefaultInterfaces(this IJoinFilterWhereExcludeIncludeBindSyntax syntax)
    {
        return syntax.BindWith(new DefaultInterfacesBindingGenerator(new BindableTypeSelector(), new PluginOtherwiseDefaultBindingCreator()));
    }
}

/// <summary>
/// Returns a Ninject binding to a method which returns the plug-in type if one exists, otherwise returns the default type.
/// </summary>
public class PluginOtherwiseDefaultBindingCreator : IBindingCreator
{
    public IEnumerable<IBindingWhenInNamedWithOrOnSyntax<object>> CreateBindings(IBindingRoot bindingRoot, IEnumerable<Type> serviceTypes, Type implementationType)
    {
        if (bindingRoot == null)
        {
            throw new ArgumentNullException("bindingRoot");
        }

        return !serviceTypes.Any()
         ? Enumerable.Empty<IBindingWhenInNamedWithOrOnSyntax<object>>()
         : new[] { bindingRoot.Bind(serviceTypes.ToArray()).ToMethod(context => context.Kernel.Get(context.Kernel.Get<PluginLocator>().Locate(serviceTypes) ?? implementationType)) };
    }
}

Next we’ll look at the Roslyn part in more detail.

Replacing a Class at Runtime Using Ninject and Roslyn - Part 2: The Solution

| Comments

Previously: Part 1: The Goal

The solution

The code for the example is available on GitHub.

How it looks

So here’s the Hello World page in production:

.

We navigate to the plugins view and create a new replacement for the HelloWorldGenerator:

.

Without restarting, we can return to the HelloWorld page and see that the new class is being used because the output has changed.

.

If you delete the row from the plugins page, the behaviour reverts to the original implementation (the code that was originally shipped with production).

Basic project setup

First, I created a new ASP.NET MVC 5 application. I added a HelloWorldContrroller and a View. I added a Plugin model and corresponding views. To get started I followed the tutorial here (http://www.asp.net/mvc/tutorials/mvc-5/introduction/getting-started). Once I had the basics in place, I added the following NuGet packages.

Stable

  • EntityFramework
  • Ninject
  • Ninject.MVC5
  • Ninject.Conventions

Pre-release

  • Microsoft.CodeAnalysis.CSharp

The Microsoft.CodeAnalysis.CSharp is the ‘Roslyn’ package. It is still in beta, so you have to switch to the pre-release.

Next we’ll look at the dependency injection part in more detail.

Replacing a Class at Runtime Using Ninject and Roslyn - Part 1: The Goal

| Comments

The goal

How can we replace a given class’s code with new code at runtime? In particular, how we can we do this while allowing dependency injection and sidestepping assembly versioning issues.

Let’s say you have bunch of classes like this:

SomeGenerator.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
public class SomeGenerator : IGenerator
{
    public SomeGenerator(ISomeDependency dependency, IAnotherDependency another)
    {
        ...
    }

    public void Generate()
    {
        ...
        // generate some output
    }
}

Now let’s assume that you need the ability to modify the behaviour of these classes at runtime without upgrading. And change the dependencies. Without restarting the application.

Old school - The MEF approach (and most other plug-in frameworks)

One approach would be to place each generator in a separate assembly and then you could load them at runtime. (This was my first effort - oh how I struggled).

You can make use of something like MEF to help with the grunt work, but can still be very complex.

One difficulty is the dependencies. The dependencies are often defined in other assemblies and you have to be very careful to avoid ‘dll hell’. It is very easy to get message like:

Could not load file or assembly 'SomeAssembly, Version=1.2.9.1, Culture=neutral, PublicKeyToken=ad2d246d2bace800' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

Or even exceptions like

Object (of type 'SomeGenerator') is not of type 'SomeGenerator'.

You either have to write your plug-in code so that it is totally independent (i.e., has no dependencies), or you need to resort to a heap of <bindingRedirect> tags in your web.config.

Also, with one assembly per format, you can end up with a huge proliferation of assemblies. If you have 50 different formats, that would be 50 assemblies.

New school - The Rosyln approach

An alternative is to use the compiler-as-a-service features of Roslyn.

Can we upload a modified SomeGenerator.cs and get it to reference the deployed assemblies and thereby avoid dll hell? With Roslyn we can do this.

If the compilation fails, we can immediately inform the user that the file is not compatible. If it succeeds, we can use it in lieu of the version that was originally deployed.

Also, you do not need separate assemblies for the plug-ins. Your production code contains, within it somewhere a class named SomeGenerator. At runtime, we are going to create an in-memory assembly which contains only a single class (still named SomeGenerator), but which can nevertheless reference any other class available to the original implementation. Then we will get the dependency injection container to ‘replace’ the old generator with the new one.

The plan

  • Build an ASP.NET MVC 5 web application. It will use an instance of HelloWorldGenerator to generate some output. (This is the original implementation).
  • Allow a replacement for the HelloWorldGenerator class to be uploaded into the application as raw C# code. (This is the plug-in implementation.)
  • Store the C# code in a database. If the application is restarted, the plug-in code will be reloaded.
  • When the output is next requested, compile the new C# class. Any dependencies will be instantiated by the IoC container. If there are any compilation errors, these will be displayed.
  • Show that the plug-in class is now being used and the output has changed. The originally shipped HelloWorldGenerator class has been replaced by our plug-in.
  • Delete the plug-in from the table and show the output has reverted to the default (the originally implementation code).

Over next few posts I’ll guide you through building the application and demonstrate the runtime replacement of the generator class.

See Part 2 for screen shots of the working application and an overview of the basic project set up.

Persisting Changes to Config Files Within NuGet Packages

| Comments

Whenever NuGet updates or restores a NuGet package, the config files within it are overwritten. Here’s a method to make sure the changes are reapplied via a config transform whenever the solution is built.

I’m using the NUnit.Runners NuGet packages. To get our coverage tool to play nicely, I need to replace <supportedRuntime "v2.0.50727"> with <supportedRuntime "v4.0.30319"> within the NUnit-console-x86.exe.config.

Normally, a config transform is for modifying the web.config or app.config files. Here, we need to modify a config file within the packages subdirectory.

In my .csproj file, I have added the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
  <PropertyGroup>
   <NUnitRunnerDir>$(SolutionDir)packages\NUnit.Runners.2.6.3\tools\</NUnitRunnerDir>
  <PropertyGroup>

  <!-- Default NUnit test runner requires a modification to the config file-->
  <UsingTask
    TaskName="TransformXml"
    AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.Tasks.dll" />

  <Target Name="AfterBuild" Condition="exists('$(NUnitRunnerDir)NUnit-console-x86.exe.config')">
    <TransformXml
        Source="$(NUnitRunnerDir)NUnit-console-x86.exe.config"
        Destination="$(NUnitRunnerDir)NUnit-console-x86.exe.config"
        Transform="$(SolutionDir)UnitTests\Transforms\NUnit-console-x86.exe.CLR4.config" />
  </Target>

And the transform file itself looks like this:

NUnit-console-x86.exe.CLR4.config
1
2
3
4
5
6
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <startup>
    <supportedRuntime version="v4.0.30319" xdt:Transform="Replace" />
  </startup>
</configuration>

By the way, Web.config Transformation Tester is a handy tool!

Now whenever I build the project, the AfterBuild event ensures the supportedRuntime version is set correctly.

Pardon the Interruption

| Comments

I left my laptop on a train a couple of months ago. Good thing I remembered my brain. I’m back now. This blog still lives.

A Web UI Performance Tip for XAF Web Applications

| Comments

The purpose of this post is to raise your awareness of a toggle which exists in the DevExpress XAF framework which can significantly improve UI performance in the web application.

The biggest XAF project I work with has one very complex business object. The layout for this screen includes about 100 properties, several nested tabs, some custom editors, several collection properties and a whole lot of Conditional Appearance rules. It was very sluggish to navigate - it was taking several seconds to load the detail view and then it was very slow switching between tabs. Switching to edit mode was also slow.

Last week, I almost accidentally changed the value of DelayedViewItemsInitialization to false and noticed that the UI speed was much much better. In fact the general responsiveness of the entire web-application seems much better.

In order to give it a whirl, navigate to the WebApplication.cs file (normally in the ApplicationCode subfolder of your web project) and modify the constructor as follows:

1
2
3
4
public MainDemoWebApplication() {
    InitializeComponent();
    this.DelayedViewItemsInitialization = false;
}

Certainly this is not without consequences, and I would urge a careful reading of the relevant documentation. To be honest, I still don’t really understand why my detail view is so much slower without this change. I have tried to isolate the cause without much success and I will update this post if I find anything new. But if some of your detail views seem overly slow, certainly try it out.

Provisioning a New Development Machine With BoxStarter

| Comments

I’ve been playing around with Boxstarter to configure my entire development environment with hardly any user intervention.

Here are the steps:

  1. Install Windows 8.1 on a new machine.
  2. Login.
  3. Open a command prompt and enter the following.
1
START http://boxstarter.org/package/nr/url?http://bit.ly/1kapDXI

That’s it!

Boxstarter will self-install via ClickOnce, asking for various confirmations and ultimately it will prompt you for your login password. (This gets saved and encrypted to allow for unattended reboots and re-logins during the installation). Then the real magic begins. Boxstarter downloads and installs all your tools and configures your environment, rebooting as necessary. An hour later your full development setup is installed, including Visual Studio 2013, any VS extensions, any other programs and tools, all the browsers you need, all critical Windows updates, etc. You just saved yourself a couple of days of work and a lot of hassle.

How does Boxstarter know what to install? There’s a Powershell script located at that bitly address. Let’s take a look at the script.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
# Boxstarter options
$Boxstarter.RebootOk=$true # Allow reboots?
$Boxstarter.NoPassword=$false # Is this a machine with no login password?
$Boxstarter.AutoLogin=$true # Save my password securely and auto-login after a reboot

# Basic setup
Update-ExecutionPolicy Unrestricted
Set-ExplorerOptions -showHidenFilesFoldersDrives -showProtectedOSFiles -showFileExtensions
Enable-RemoteDesktop
Disable-InternetExplorerESC
Disable-UAC
Set-TaskbarSmall

if (Test-PendingReboot) { Invoke-Reboot }

# Update Windows and reboot if necessary
Install-WindowsUpdate -AcceptEula
if (Test-PendingReboot) { Invoke-Reboot }

# Install Visual Studio 2013 Professional 
cinstm VisualStudio2013Professional -InstallArguments WebTools
if (Test-PendingReboot) { Invoke-Reboot }

# Visual Studio SDK required for PoshTools extension
cinstm VS2013SDK
if (Test-PendingReboot) { Invoke-Reboot }

cinstm DotNet3.5 # Not automatically installed with VS 2013. Includes .NET 2.0. Uses Windows Features to install.
if (Test-PendingReboot) { Invoke-Reboot }

# VS extensions
Install-ChocolateyVsixPackage PowerShellTools http://visualstudiogallery.msdn.microsoft.com/c9eb3ba8-0c59-4944-9a62-6eee37294597/file/112013/6/PowerShellTools.vsix
Install-ChocolateyVsixPackage WebEssentials2013 http://visualstudiogallery.msdn.microsoft.com/56633663-6799-41d7-9df7-0f2a504ca361/file/105627/31/WebEssentials2013.vsix
Install-ChocolateyVsixPackage T4Toolbox http://visualstudiogallery.msdn.microsoft.com/791817a4-eb9a-4000-9c85-972cc60fd5aa/file/116854/1/T4Toolbox.12.vsix
Install-ChocolateyVsixPackage StopOnFirstBuildError http://visualstudiogallery.msdn.microsoft.com/91aaa139-5d3c-43a7-b39f-369196a84fa5/file/44205/3/StopOnFirstBuildError.vsix

# AWS Toolkit is now an MSI available here http://sdk-for-net.amazonwebservices.com/latest/AWSToolsAndSDKForNet.msi (no chocolatey package as of FEB 2014)
# Install-ChocolateyVsixPackage AwsToolkit http://visualstudiogallery.msdn.microsoft.com/175787af-a563-4306-957b-686b4ee9b497

#Other dev tools
cinstm fiddler4
cinstm beyondcompare
cinstm ProcExp #cinstm sysinternals
cinstm NugetPackageExplorer
cinstm windbg
cinstm Devbox-Clink
cinstm TortoiseHg
#cinstm VisualHG # Chocolatey package is corrupt as of Feb 2014 
cinstm linqpad4
cinstm TestDriven.Net
cinstm ncrunch2.vs2013

#Browsers
cinstm googlechrome
cinstm firefox

#Other essential tools
cinstm 7zip
cinstm adobereader
cinstm javaruntime

#cinst Microsoft-Hyper-V-All -source windowsFeatures
cinst IIS-WebServerRole -source windowsfeatures
cinst IIS-HttpCompressionDynamic -source windowsfeatures
cinst IIS-ManagementScriptingTools -source windowsfeatures
cinst IIS-WindowsAuthentication -source windowsfeatures

Install-ChocolateyPinnedTaskBarItem "$($Boxstarter.programFiles86)\Google\Chrome\Application\chrome.exe"
Install-ChocolateyPinnedTaskBarItem "$($Boxstarter.programFiles86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe"

Boxstarter works with Chocolatey and you can install anything with a Chocolatey package very easily. As you can see, most of the lines begin with cinstm which is a shortcut for install with Chocolatey if missing. You will notice there are also commands for configuring Windows and IIS options. There is plenty of additional information on the Boxstarter documentation.

What about DevExpress?

Want to install your registered CodeRush and DexExpress components? Easy. Since the installation packages are not available on chocolatey, you will have to put them on a network share accessible from the newly provisioned machine.

Then add the following to your boxstarter script:

1
2
3
4
5
6
7
8
9
10
11
12
13
# Set the following to the network location of the DevExpress installers
$pathToDevExpressComponentsSetup = "\\somewhere\DevExpressComponents-13.2.7.exe"
$pathToDevExpressComponentsSetup = "\\somewhere\DevExpressCodeRush-13.2.7.exe"

# Command line options for unattended installation
# (/EULA is not required for versions earlier than 10.2.10)
$silentArgs = "/Q /EMAIL:myaddress@company.com /CUSTOMERID:A1111 /PASSWORD:MYPASSWORD /DEBUG /EULA:accept"

# Install .NET Components
Install-ChocolateyInstallPackage "DevExpressComponents_13.2" "EXE" $silentArgs $pathToDevExpressComponentsSetup

# Install CodeRush
Install-ChocolateyInstallPackage "DevExpressCodeRush_13.2" "EXE" $silentArgs $pathToDevExpressCodeRushSetup

Warning! don’t put your DevExpress passwords on a public website.

There are plenty of other ways of launching Boxstarter. You can install Boxstarter via Chocolatey. You can run Boxstarter remotely. If you are putting passwords in the installation script, you should choose one of the other options.

Advantages

  • I save time!
  • I can now version control the exact development environment along with the source code!
  • Onboarding new and junior developers is much quicker.
  • In a pinch, I can use this method to quickly provision a development machine with Azure or Amazon Web Services

One Last Hiccup

While I was testing my BoxStarter script I used the Windows 8.1 image from http://www.modern.ie/. Much later in the process I realised that Modern.IE only supplies 32-bit images and the chocolatey installer for Visual Studio extensions currently works only with 64-bit Windows.

CruiseControl Notifications on Your iPhone

| Comments

CCWatcher is a great iPhone app for any developer who is using CruiseControl.NET, Jenkins or Hudson for their continuous integration.

We have used CruiseControl.NET for several years to automate all builds. The build kicks off automatically whenever we push changes and this frequently happens a few times a day. We aim to have everything green at the end of every day.

A full build with unit tests and functional tests takes about an hour, so often, I will leave the office while the build is still running. But then I wouldn’t know if I’d broken the build.

For a long while I was looking for a better way of being informed of build failures on my phone.

Enter CCWatcher. It’s a simple application which allows you to enter the address of your build server and it will tell you the status of the projects you’ve configured.

Whenever I need to check whether I’ve broken the build, I can just pull to refresh.

When I first discovered the application it had a problem with CruiseControl.NET’s remote services (which we needed because the actual build server is on a network machine not visible from the internet). I contacted SixAfter and was very impressed with the helpful response from Michael Primeaux. Within a couple of weeks there was a new version of the app with support for the remote services configuration. Hats off.

Glimpse With DevExpress XAF

| Comments

I have finally got around to getting Glimpse working with XAF. Glimpse is an amazing extensible ASP.NET plug-in which gives you valuable information about what is going on within your server in production. It’s also very pretty.

Let’s jump right in and have a look at what XAF looks like with Glimpse running.

That banner along the bottom of the screen is the Glimpse heads up display (HUD). Hovering over various sections of it pops up more information:

If you click on the Glimpse icon in the bottom right, you get even more goodies. Here’s the Timeline view.

And there are many other tabs available. The Configuration tab shows the contents of the web.config file. Here’s the Control Tree tab: The Page Life Cycle tab: The Request tab: The Session tab: And the Trace tab including the DevExpress log items that were added to the trace during this page load: As you can see, this is a very valuable glimpse into the server which can be turned on as needed in production.

Adding Glimpse to an XAF application

First install the Glimpse Nuget package into the project.

The Nuget installation will make various incorrect changes to the web.config. The corrected sections are below:

First, add Glimpse to the <configSections>.

web.config
1
2
3
4
5
6
7
8
  <configSections>
    <sectionGroup name="devExpress">
      <section name="compression" requirePermission="false" type="DevExpress.Web.ASPxClasses.CompressionConfigurationSection, DevExpress.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
      <section name="themes" type="DevExpress.Web.ASPxClasses.ThemesConfigurationSection, DevExpress.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
      <section name="settings" type="DevExpress.Web.ASPxClasses.SettingsConfigurationSection, DevExpress.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
    </sectionGroup>
+   <section name="glimpse" type="Glimpse.Core.Configuration.Section, Glimpse.Core" />
  </configSections>

Next, <system.webserver> should look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
  <system.webServer>
    <handlers>
      <add name="TestControls.axd_*" path="TestControls.axd" verb="*" type="DevExpress.ExpressApp.Web.TestScripts.TestScriptsManager, DevExpress.ExpressApp.Web.v13.2, Version=13.2.5.0, culture=neutral, PublicKeyToken=b88d1754d700e49a" preCondition="integratedMode" />
      <add name="ImageResource.axd_*" path="ImageResource.axd" verb="*" type="DevExpress.ExpressApp.Web.ImageResourceHttpHandler, DevExpress.ExpressApp.Web.v13.2, Version=13.2.5.0, culture=neutral, PublicKeyToken=b88d1754d700e49a" preCondition="integratedMode" />
      <add name="SessionKeepAliveReconnectHttpHandler" verb="*" path="SessionKeepAliveReconnect.aspx*" type="DevExpress.ExpressApp.Web.SessionKeepAliveReconnectHttpHandler, DevExpress.ExpressApp.Web.v13.2, Version=13.2.5.0, culture=neutral, PublicKeyToken=b88d1754d700e49a" preCondition="integratedMode" />
      <add name="WebWindowTemplateHttpHandler" verb="*" path="*.aspx" type="DevExpress.ExpressApp.Web.WebWindowTemplateHttpHandler, DevExpress.ExpressApp.Web.v13.2, Version=13.2.5.0, culture=neutral, PublicKeyToken=b88d1754d700e49a" preCondition="integratedMode" />
      <add name="ASPxUploadProgressHandler" verb="GET,POST" path="ASPxUploadProgressHandlerPage.ashx" type="DevExpress.Web.ASPxUploadControl.ASPxUploadProgressHttpHandler, DevExpress.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" preCondition="integratedMode" />
      <add name="ReportExportResource.axd_*" preCondition="integratedMode" verb="*" path="ReportExportResource.axd" type="DevExpress.ExpressApp.Reports.Web.ReportExportHttpHandler, DevExpress.ExpressApp.Reports.Web.v13.2, Version=13.2.5.0, culture=neutral, PublicKeyToken=b88d1754d700e49a" />
 +    <add name="Glimpse" path="glimpse.axd" verb="GET" type="Glimpse.AspNet.HttpHandler, Glimpse.AspNet" preCondition="integratedMode" />
    </handlers>
    <validation validateIntegratedModeConfiguration="false" />
    <modules>
      <add name="ASPxHttpHandlerModule" type="DevExpress.Web.ASPxClasses.ASPxHttpHandlerModule, DevExpress.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
 +    <add name="Glimpse" type="Glimpse.AspNet.HttpModule, Glimpse.AspNet" preCondition="integratedMode" />
    </modules>
  </system.webServer>

NuGet added some incorrect definitions to system.web. Make sure to restore this section to the DevExpress default:

1
2
3
4
5
  <system.web>
    <httpRuntime requestValidationMode="2.0" />
    <sessionState mode="InProc" timeout="2" />
    <httpHandlers configSource="HttpHandlers.Web.Config" />
    <httpModules configSource="HttpModules.Web.Config" />

And now we’ll add the corrected changes to HttpHandlers.Web.Config and HttpModule.Web.Config

HttpHandlers.Web.Config
1
2
3
4
5
6
7
8
9
10
<?xml version="1.0" encoding="utf-8"?>
<httpHandlers>
+ <add verb="GET" path="glimpse.axd" type="Glimpse.AspNet.HttpHandler, Glimpse.AspNet" />
  <add verb="*" path="TestControls.axd" type="DevExpress.ExpressApp.Web.TestScripts.TestScriptsManager, DevExpress.ExpressApp.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
  <add verb="*" path="ImageResource.axd" type="DevExpress.ExpressApp.Web.ImageResourceHttpHandler, DevExpress.ExpressApp.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
  <add verb="*" path="SessionKeepAliveReconnect.aspx*" type="DevExpress.ExpressApp.Web.SessionKeepAliveReconnectHttpHandler, DevExpress.ExpressApp.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
  <add verb="*" path="*.aspx" type="DevExpress.ExpressApp.Web.WebWindowTemplateHttpHandler, DevExpress.ExpressApp.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
  <add verb="GET,POST" path="ASPxUploadProgressHandlerPage.ashx" validate="false" type="DevExpress.Web.ASPxUploadControl.ASPxUploadProgressHttpHandler, DevExpress.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
  <add verb="*" path="ReportExportResource.axd" type="DevExpress.ExpressApp.Reports.Web.ReportExportHttpHandler, DevExpress.ExpressApp.Reports.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
</httpHandlers>
HttpModules.Web.Config
1
2
3
4
5
<?xml version="1.0" encoding="utf-8"?>
<httpModules>
+ <add name="Glimpse" type="Glimpse.AspNet.HttpModule, Glimpse.AspNet" />
  <add name="ASPxHttpHandlerModule" type="DevExpress.Web.ASPxClasses.ASPxHttpHandlerModule, DevExpress.Web.v13.2, Version=13.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
</httpModules>

Next, there is an outstanding problem with the current release version of the Glimpse ASP.NET NuGet package (1.6.0) which prevents it from working with the development webserver. (Apparently it’s fixed in 1.7.0 which should be released soon). If you try to run MainDemo.Web you will get the following error:

Type 'System.Web.HttpContextWrapper' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.

However it works fine against IIS Express (or full IIS). Go to the MainDemo.Web and change the debug properties as follows:

Then run the web application. Glimpse is off by default. In order to turn it on, you need to set a cookie, which you can do by navigating to Glimpse.axd. This is the Glimpse configuration screen.

Additional Glimpse extensions

Glimpse is extensible and there are many additional plugins available. Many of these take the form of additional tabs with details about a particular aspect of your application: SQL Queries, Elmah errors, ASP.NET caching, logging, dependency injection, etc.

MainDemo Sample Project

I have uploaded a modified XAF MainDemo to this GitHub repository with all the above changes. (Don’t forget to debug against IIS Express).

DevExpress 13.2 Review - Part 2

| Comments

This is the second part of a review of the new DevExpress 13.2. In the last part we looked in-depth at the new Reports V2. In this part I’ll go over some of the other new features including the support for warnings and confirmations in the validation module.

Soft Validation Rules

With 13.2, DevExpress adds support for warning/confirmation messages to the validation engine. Warnings can be used to handle an unusual but valid data entry. An example would be:

The date of birth results in an age of over 100. Are you sure?

Here the age of the contact is unusual but not impossible, so instead of prohibiting it entirely, we ask the user for confirmation before saving.

Let’s add this rule to the MainDemo. Open the model and navigate to the Validation node. Add a RuleValueComparison and configure it as follows

Of course you could instead also define the same rule with an attribute on the Birthday property. Something like:

1
2
3
4
5
6
[RuleValueComparison("IsOlderThan100_Warning", 
    DefaultContexts.Save,
    ValueComparisonType.GreaterThan, "AddYears(Now(), -100)",
    "Birthday makes this Contact older than 100. Are you sure?",
    ParametersMode.Expression,
    ResultType = ValidationResultType.Warning)]

Notice the new ResultType parameter is set to ValidationResultType.Warning.

Another typical use is to provide better handling of duplicates. Consider the following:

1
2
3
4
5
6
7
[RuleCombinationOfPropertiesIsUnique("DuplicateName_Warning", 
    DefaultContexts.Save, 
    "LastName;FirstName", 
    "There is already a Contact with the name {FullName}. Are you sure?", 
    ResultType = ValidationResultType.Warning)]
public class Contact : Person {
  //etc ...

And then this is what happens if I try to add another John Nilsen.

Another scenario would be to warn the user of something which needs attention. Such as “Warning! You are running out of funds in your current account.” Or “Warning! Deleting this record will format your hard drive.”

List Views

Soft validation also works in the list views, even with multiple selection, but there are a couple of things that don’t work very smoothly yet and I would expect the web implementation to evolve over the coming releases.

In order to demonstrate this I need to use a context which allows multiple selection such as deletion. So let’s decorate our class with the following simple rule.

1
[RuleCriteria("Deletion_Warning", DefaultContexts.Delete, "1=0", "Warning! Are you sure?", ResultType = ValidationResultType.Warning)]

Then I select all the contacts and press Delete, after the confirmation window, I get this:

Web Application

Soft validation is also available in the web application. This is what a warning looks like.

I would prefer to see a Confirm button rather than the current Ignore checkbox since a button requires a single click to validate.

When there are several warnings and errors at the same time, the current implementation displays them all. I think it would be preferable if warnings were not displayed unless there are no errors. Unless DevExpress provide this as an option soon, I will attempt to extend the controller in this regard in a future post.

Other new features

In the 13.2 release, there is now support for runtime extension of the model. DevExpress is calling this feature custom fields and (again) it is marked as beta. This is not a feature I’ve looked at, but there are a few other non-XAF DevExpress novelties which I’d like to see working within XAF. These include new themes and support for grid batch editing.

One warning

The default directories for the installation have changed again. I’m sure DevExpress has some good reason for this, but if, like me, you have several different versions installed you end up with a confusing directory tree. Whenever this happens I always end up having to modify build scripts and config files so that all my tools work as expected. For those of you who use Red Gate’s .NET Reflector, you can find my config file in this gist.

Conclusions

For the 13.2 release, DevExpress have focused on making the existing functionality work better rather than developing new modules.

Better reports. Better validation. A better framework all round.