Thorarin.NET

Getting rid of an AL1703 warning

blog@thorarin.net — Fri, 8 Feb 2019 18:13:00 +0200

Yesterday I was converting an old work-related project to the new csproj structure (using this very helpful tool by Hans van Bakel). Tackling compilation warnings one by one, I was finally left with this one:

Warning AL1073 Referenced assembly 'mscorlib.dll' targets a different processor

Some Googling revealed that this was related to .resx files and x64 platform targeting. Unfortunately, the workarounds offered on Stack Overflow didn't quite work for me. The warning was replaced by two warnings. The original one, plus this:

Microsoft.Common.CurrentVersion.targets(3628,5): warning MSB3084: Task attempted to find "al.exe" in two locations. 1) Under the "x64\‌" processor specific directory which is generated based on SdkToolsPath 2) The x86 specific directory under "x64\‌" which is specified by the SDKToolsPath property. You may be able to solve the problem by doing one of the following: 1) Set the "SDKToolsPath" property to the location of the Microsoft Windows SDK.

Unfortunately the suggested solution (setting SDKToolsPath) also had no effect for me. A little more digging finally gave me a solution that removed all the warnings though. Just put this somewhere in your csproj file:

<Target Name="FixAL1703Warning" BeforeTargets="GenerateSatelliteAssemblies"
        Condition="'$(PlatformTarget)' == 'x64'">
  <Message Text="Adjusting SDK tools directory to use x64 version of AL.EXE">
  <PropertyGroup>
    <TargetFrameworkSDKToolsDirectory>$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\</TargetFrameworkSDKToolsDirectory>
  </PropertyGroup>
</Target>

I hope this saves somebody some time and frustration :) As far as I know the warning doesn't actually negatively affect anything, but having unnecessary warnings just adds noise.

<sarcasm>Thanks Microsoft, for giving me this opportunity to help people by not fixing this bug!</sarcasm>

Redux-connected React components in TypeScript

blog@thorarin.net — Fri, 5 May 2017 14:04:00 +0200

When I originally started using React together with TypeScript, I felt it was a great marriage of technologies. However, adding Redux into the mix (which is awesome, BTW) has created a lot of complexity to properly type my React Components. Type inference doesn't appear to work smoothly for the connect method in React Redux.

For simple stateless components, there is a pretty good solution by Silvio J. Gutierrez, which is pretty similar to something I had been using.

I've tried to come up with a good solution for more complex components as well. This is the best I've managed so far:

interface OwnProps {
  componentOwnProp: string;
}

function mapStateToProps(state: State) {
  return {
    someProperty: state.someProperty
  };
}

function mapDispatchToProps(dispatch) {
   // ...
}

// Magic happening here
const { propsGeneric, connect } =
    connectedComponentHelper<OwnProps>()(mapStateToProps, mapDispatchToProps);
type ComponentProps = typeof propsGeneric;

// Use the inferred ComponentProps type as generic type parameter
class MyComponent extends React.Component<ComponentProps, {}> {
  // ...
}

// Export the connected component
export default connect(MyComponent);

Wait... What?

The syntax is a bit confusing; the connectedComponentHelper higher-order function returns a function which is immediately called with the mapStateToProps and mapDispatchToProps functions as parameters^*. This returns two things:

A dummy value of the type to be used for the P generic type parameter when extending React.Component<P, S>. The return types of mapStateToProps and mapDispatchToProps are inferred by the compiler and the helper function returns the "type" that combines the components own props with the state and the dispatch props.
Unfortunately since types don't exist at runtime, you still have to use typeof to define the type alias to use.
A function that can be used to connect your component to the Redux store easily.

Also, take note that the connectedComponentHelper function itself is generic and requires you to pass in the type for the component's own properties.

^*: Yep, that means that function is actually also higher-order. Oh boy...

The Helper Function

Here's the implementation of the helper function, which can of course be reused for all your connected components:

import { connect } from 'react-redux';

interface Func<T> {
  ([...args]: any): T;
}

export function connectedComponentHelper<TProps>() {
  return <TStateProps, TDispatchProps>(
    mapStateToProps: Func<TStateProps>,
    mapDispatchToProps?: Func<TDispatchProps>) => (
    {
      propsGeneric: null as TProps & TStateProps & TDispatchProps,
      connect: (component) => connect(mapStateToProps, mapDispatchToProps)(
        component) as any as React.ComponentClass<TProps>
    }); 
}

Wrapping Up

So, that code was definitely more complex than I would have liked it to be. Still, it beats manually defining the StateProps and DispatchProps types, plus the intersection type OwnProps & StateProps & DispatchProps, only to spend 15 minutes getting the call to connect to compile properly before chickening out and casting to any.

What do you think of this solution? Have you come up with something better?

Auto-configuring mail clients

blog@thorarin.net — Tue, 17 May 2016 19:38:00 +0200

Although I tend to prefer Microsoft .NET for my programming projects, I've used a large number of programming languages throughout the years. Last weekend I did a minor project in PHP for a change.

It involves helping users to configure their mail clients pretty much automatically. Outlook combined with Exchange does this really nicely, but that functionality is not limited to Exchange. Or Outlook, for that matter. I've run my own Linux based mail server at home for years, and this little project makes things a little bit easier for users of that mail server.

If you're at all interested in this sort of stuff, check out the project on GitHub.

PS: yes, this is the first article in a long time. I've started several, but decided against them halfway through. I always write about fairly niche things, but sometimes it turns out to be a bit too niche :)

Now, I could have done all this stuff in .NET of course. I personally have ASP.NET running even on my Linux box. Since this was such a tiny project and would usually run on a Linux based mail server rather than a dedicated web server, I figured that using .NET Core or Mono would make it a bit too niche again. Besides, using PHP every now and them makes me appreciate .NET all the more.

Capturing method arguments on your fakes (using FakeItEasy)

blog@thorarin.net — Thu, 18 Sep 2014 21:08:00 +0200

There are many isolation frameworks around that make writing unit tests relatively simple. It's highly unlikely that any single framework will meet all your needs, so writing your own utilities can be useful in order to make your tests easier to write and – perhaps more importantly – read.

I regularly find myself wanting to verify that a certain dependency is called in the right way by my system under test. This includes passed argument values, which can be complex objects themselves.

Suppose I want to verify that my fictitious SUT Circle.CalculateArea calls ICalculator.Square with the radius of the circle. This would be pretty easy with FakeItEasy:

var calculator = A.Fake<ICalculator>(); 
A.CallTo(() => calculator.Square(3)).Returns(9);

var sut = new Circle(3, calculator);
double area = sut.CalculateArea();
Assert.AreEqual(9d, area);

Now imagine that this parameter value is a whole lot more complicated than a double. FakeItEasy provides a syntax for that too. Say I want to verify that the product being saved has the right name:

A.CallTo(
    () => repository.AddProduct(A<Product>.That.Matches(p => p.Name == "MyName")).
    Returns(productId);

Still pretty readable. However, you can imagine if the number of properties to verify grows, this becomes increasingly difficult to read. I prefer to use Assert-methods from my unit testing framework instead. While it's perfectly possible to put these statements into a method and use it when I configure my fake, it's starting to get messy:

A.CallTo(
    () => repository.AddProduct(A<Product>.That.Matches(p =>
    {
        Assert.AreEqual("MyName", p.Name);
        Assert.AreEqual(100m, p.Price);
        // Etcetera
        return true;
    }).
    Returns(productId);

A better solution: capturing the argument value

Rather than using this syntax, you can capture the value passed for the parameter instead. This makes it easier to write a test that follows Arrange-Act-Assert more closely as well. Using some background magic with a helper class it can be pretty easy to read:

// Arrange
const int productId = 42;
var sourceProduct = new Product { Name = "Source Product", Price = 100m }
var productArg = new Capture<Product>();
A.CallTo(() => repository.AddProduct(productArg).Returns(productId);

// Act
sut.DuplicateProduct(sourceProduct);

// Assert
var copy = productArg.Value;
Assert.AreEqual("Copy of Source Product", product.Name);
Assert.AreEqual(sourceProduct.Price, product.Price);

I hope you agree that this scales a lot better than a predicate.

How it works

There's a small amount of magic being done by the Capture<T> class. Take a look at the source code. The amount of code needed for the actual capture is a one-liner, but there is an implicit conversion that enables the terse syntax and then some checks to prevent you from shooting yourself in the foot. There's also a Values property for multiple captures, and HasValues as a shortcut for Values.Count > 0.

Note that the implementation is not thread-safe. Unit tests should avoid dealing with threading if at all possible, but if you need the class to be thread-safe, it is easily added.

How it really really works

For those taking a close look at the implementation: You may be wondering what happens in this case:

var productArg = new Capture<Product>();
A.CallTo(() => repository.SetProductStock(productArg, 0));
A.CallTo(() => repository.SetProductStock(A<Product>._, 1));

repository.SetProductStock(new Product(), 1);

I fully expected the product argument to be captured, even though the constraint on the second parameter is not met. Surprisingly, I could not reproduce this potential problem. FakeItEasy appears to do some deep magic to check the constraints without executing the predicate I'm passing. I've even tried some more complex cases where all constrains were predicates, but all of them seemed to work as desired. Going through the FakeItEasy code I still don't fully understand, so if you can either give me an example which breaks, or explain why it doesn't, I would be most grateful :)

Files:

Capture.cs (3KB)

Virtual events in C#

blog@thorarin.net — Wed, 11 Jun 2014 08:06:00 +0200

Yesterday I ran into an interesting (and dangerous) little detail about the C# compiler regarding virtual (field-like) events; they do not behave as you might expect. Consider this code, which I've simplified from a real world example of some refactoring gone wrong:

public abstract class MyClassBase
{
    public virtual event EventHandler<EventArgs> MyEvent;

    public void DoStuff()
    {
        if (MyEvent != null)
        {
            MyEvent(this, EventArgs.Empty);
        }
    }
}

public class MyClassDerived : MyClassBase
{
    public override event EventHandler<EventArgs> MyEvent;
}

To my surprise, when one subscribes to MyEvent, it will never be called:

MyClassBase obj = new MyClassDerived();
obj.MyEvent += (s, e) => { /* Never gets called */ };

// Call method on base class that raises MyEvent
obj.DoStuff();

For reasons that are not clear to me, the compiler actually creates a new field for the overridden event; both of them are highlighted in the QuickWatch screenshot below.

This behavior would be expected when the new keyword had been used, but it goes against the expected semantics of the virtual keyword.

Now, luckily is is rarely necessary to make an event virtual, so this is not usually a problem. However, I would suggest that it would have been helpful for the compiler to produce a clear warning, to prevent developers from shooting themselves in the foot. Instead, the compiler only shows a seemingly innocuous warning message:
The event 'MyClassDerived.MyEvent' is never used.

After some searching on MSDN, I ran into a warning for exactly this situation, which unfortunately does not provide a satisfactory explanation either (emphasis mine **shudder**):

Do not declare virtual events in a base class and override them in a derived class. The C# compiler does not handle these correctly and it is unpredictable whether a subscriber to the derived event will actually be subscribing to the base class event.

ReSharper to the Rescue

Okay, so the C# compiler isn't being particularly helpful in this case. How about third party tools?

Personally I use ReSharper a lot, and fortunately it is aware of this problem and tries to warn the programmer of their mistake, by displaying a squiggly line with the message Invocation of polymorphic field-like events.

It's definitely better than nothing. Usually these squiggly lines indicate code issues that should be taken seriously. However, many of these messages are a missed oppurtunity to educate the developer; ReSharper makes no attempt to explain to me why my code is bad.

Back to my real world code for a bit: this warning message was not appearing here because I tend to follow a pattern when raising events:

public void DoStuff()
{
    RaiseEvent(MyEvent, EventArgs.Empty);
}

private void RaiseEvent<T>(EventHandler<T> evt, T eventArgs)
{
    if (evt != null)
    {
        evt(this, eventArgs);
    }
}

This pattern cleans up code a little bit when events are used a lot. At the same time, it improves thread safety of the code. Unfortunately, it also stops ReSharper from making this particular analysis. At the place of declaration in MyClassDerived, ReSharper does not show any type of warning.

When first writing the code for MyClassDerived, ReSharper does offer some assistance. Normally what I do when I want to override something is that I merely type override and let IntelliSense do the work by selecting the member I want. ReSharper changes the code that gets generated when you do this, into the following:

public override event EventHandler<EventArgs> MyEvent
{
    add { base.MyEvent += value; }
    remove { base.MyEvent -= value; }
}

Rather than using a so-called field-like event declaration, an explicit implementation is given. Roughly analogous to auto-implemented properties versus regular properties, this code does not result in the compiler automatically creating a backing field for the event. Instead, we implement the event by reusing the event in the base class.

Obviously in this particular case the behavior is not being changed at all – so the override is not useful here – but I hope it illustrates the difference.

Conclusion

The only reason I can think of why one might want to declare an event as virtual, would be to include some non-standard behavior; for example some doing some checking before actually adding a subscriber. In this case, the overriden event would never be field-like in the first place. It's hard to come up with a practical application for even this case, however.

All in all, this behavior of the C# compiler is not a big problem, but it was certainly enough to raise an eyebrow for me. I was surprised to find something that seems to be a rough edge in the language or its compiler after all these years and I wonder why the current implementation was ever chosen. What do you think?

XapReduce 1.1

blog@thorarin.net — Sun, 1 Jun 2014 14:06:00 +0200

Last December I created a small utility to reduce the size of XAP files for modular Silverlight applications. It served my purpose at the time, but more recently I've been using the tool in the context of a new application, which revealed a problem related to localization. In some cases the application could crash because of satellite assemblies that are embedded into the XAP files.

The new version takes satellite assemblies into consideration: they are removed whenever the main assemblies is also removed. There are a small number of other issues that were fixed, like an incorrectly described command line parameter.

The new source code is available on GitHub again for those interested in how things are implemented, otherwise get the binary download instead.

Files:

XapReduce-1.1.0.0.zip (32.9KB)

XapReduce: Optimizing Modular Silverlight Applications

blog@thorarin.net — Sun, 15 Sep 2013 05:30:00 +0200

Even though Silverlight has fallen out of grace with the powers that be, there are still some companies using it today for entertainment or line of business applications. Particularly for that last category, modularity can be a powerful tool in creating a flexible solution.

Over the past few years, I've worked with modular Silverlight applications based on Microsoft Prism. Every module is it's own XAP file, which is loaded on demand by the framework. Over the years, people have also rolled their own lightweight modular applications, also making use of XAP files. This article is about a specific problem with building these types of applications: optimization of the total application download size.

The Issue

Every individual XAP module, including the main Silverlight application, will depend on a number of assemblies. Normally, these assemblies (except the ones that are included in the Silverlight runtime) as included in the XAP file. This is fine for single XAP applications, but if we have multiple XAP files (a main application and several modules), there is likely to be an overlap in these dependencies. It would be a waste of download time and bandwidth if these assemblies were included in each and every XAP file.

Silverlight has a feature called Application Library Cache which looks like it might help us with this problem. It makes it possible to place dependencies in a ZIP file outside the normal XAP file which will then be loaded on demand. Unfortunately, Prism does not support this mechanism unless you do some heavy customization. Even with the feature, it's rather difficult to control exactly what gets put into the XAP file however. Visual Studio seems to ignore the .extmap.xml files that are supposed to control the behavior under some circumstances.

There is another way of controlling which assemblies get included into your XAP file: the Copy Local property on the reference inside each of your projects. If you set Copy Local to false, the file will not be copied to the project's output directory and it will also not be included in the XAP file. It sounds pretty straightforward, but unfortunately it's not. Visual Studio only takes the Copy Local options that are on the XAP project into account. Suppose your application has a dependency structure like this:

Main Application
- Microsoft.CSharp.dll
- System.Xml.Linq.dll
Module A
- MyLibrary.dll (Copy Local = false)
  - Microsoft.CSharp.dll (Copy Local = true)
  - System.Xml.Linq.dll (Copy Local = true)

These standard assemblies will end up both in MainApplication.xap and ModuleA.xap, wasting 221 KB in downloads (compressed) for each of your users. After all, any module is always loaded after the main application, so this particular assembly is already loaded into the application domain. You cannot put MyLibrary.dll on Copy Local, because it too will not be included in the XAP file and the application will fail.

There is a way to trick Visual Studio to exclude the duplicate assemblies. You can add them as a reference on the Module A project and then set Copy Local to false there. This works fine, but unfortunately, it's incredibly unmaintainable. What if a new assembly dependency is added on the main application, so the module no longer needs to include it? What if your colleague decides to use his favorite refactoring tool to remove unused references? You can start all over with your optimization. Very uncool.

XapReduce

To address this issue, I've written a simple command line tool which analyzes the contents of your XAP files and removes any unneeded assemblies. The idea is that you can easily include this tool in a post-build step for your module and have it take care of this optimization.

You will have to provide the list of XAP files that need to be analyzed on the command line. The tool cannot determine which module will be loaded before which, so you have to provide this information on the command line:

You've just reduced the size of your module to a mere 11% of the original size! You can specify more than 1 source file, and you can provide a filename for the output as well if you prefer to not overwrite the original. Use XapReduce --help for a full list of options.

How it Works

Basically, XAP files are ZIP files with an AppManifest.xaml embedded in them, so it is quite easy to modify them using the new .NET 4.5 ZipFile class. Full source code can be found on GitHub (under MIT license), including unit tests for 100% code coverage. I've used this as a trial project to familiarize myself with the NSubstitute isolation framework .

If you don't want to bother with source code, there is a binary download as well.

Unpredictable Loading Orders

What if there are common assembly dependencies between two modules, but there is no fixed order in which these modules are loaded? You can solve this by defining a third module and loading it before either other module. If you're using Microsoft Prism, you can do this by defining a dependency between the modules in configuration. This utility will not save you from doing some manual optimization, but you can still use it after creating this common module:

XapReduce --input ModuleA.xap --sources MainApplication.xap CommonModule.xap XapReduce --input ModuleB.xap --sources MainApplication.xap CommonModule.xap

Files:

XapReduce-1.0.0.0.zip (33 KB)

Advanced base constructor calls in C#

blog@thorarin.net — Thu, 5 Sep 2013 14:00:00 +0200

Note: This article was edited after a Gonçalo Lopes presented me with a better solution. Thanks!

Every now and then you run into a situation where you wish your programming language of choice was just a tad more flexible than it actually is. For example, constructors in C# always have to directly call one of the base type constructors as the first thing they do (or do they? keep reading).

Yesterday I ran into a situation where I would like my derived class to always use the same implementation^* for a certain injectable dependency. No problem:

public class FooBase
{
    public FooBase(IDependency dependency)    { /* stuff here */ }
}

public class MyFoo : FooBase
{
    public MyFoo() : base(new MyDependency()) { }
}

The dependency is created on the fly and my base class constructor is happy. However, my derived class also needed to make use of this dependency and my base class does not expose any property or field for me to access it. So before calling the base constructor, I would have liked to store a reference to this newly created MyDependency object.

If we switch to Java syntax for a moment, it would be something like this:

public class MyFoo
{
    private MyDependency _dependency;

    public MyFoo()
    {
        // Note that this is not actually valid in Java either.
        // The call to super must be the first statement in the constructor.
        _dependency = new MyDependency();
        super(myDependency);
    }
}

Now, the reason why this isn't allowed makes perfect sense. We'd be accessing a field of this type before the base constructor is initialized, but for technical reasons the compiler is enforcing initialization to occur from base type to more specialized types. Now, I'm not an expert at compiler creation, but I think this would have been perfectly fine to allow the use of local variables:

public MyFoo()
{
    MyDependency dependency = new MyDependency();
    super(myDependency);
    _dependency = dependency;
}

It even seems like a easy enough thing to let the compiler to automatically park the reference on the stack temporarily, but alas.

My original workaround

So far I've neglected to mention a lesser known feature of C#, which is to include a method call in the base constructor call:

public class MyFoo : FooBase
{
    public MyFoo() : base(CreateDependency())
    {
    }

    private static IDependency CreateDependency()
    {
         return new MyDependency();
    }
}

This code is essentially identical to the first code snippet. If you were paying attention, you noticed that the method I'm calling is static. This is again to prevent access to fields prior to initialization of the base type. So how does this help me? Well, originally I wrote something like this:

// =========================
// Warning: evil code inside
// =========================

public class MyFoo: FooBase
{
    private static IDependency _tempDependency;
    private readonly IDependency _dependency;

    public MyFoo() : base(CreateDependency())
    {
        _dependency = _tempDependency;
        _tempDependency = null;
        Monitor.Exit(typeof(MyFoo));
    }

    private static IDependency CreateDependency()
    {
        Monitor.Enter(typeof(MyFoo));
        _tempDependency = new MyDependency();
        return _tempDependency;
    }
}

The locks in here (Monitor.Enter and Monitor.Exit) are just in case you'd be mass creating these objects in multiple threads. Performance wouldn't be good, but at least it would be error free. Use of ThreadStaticAttribute would be another option.

A better solution

Using the code above seemed like a very bad idea. Luckily, there was a better solution to my presented problem, as Gonçalo Lopes pointed out after I posted the original article: Just use a private constructor to both create an object and put it on the stack:

public class MyFoo : FooBase
{
    public MyFoo() : this(new MyDependency()) { }

    public MyFoo(IDependency dependency) : base(dependency)
    {
        _dependency = dependency;
    }
}

Wrapping up

In the end, I didn't actually need any nasty workarounds, which I'm really glad about. Trying to solve the problem once again made me aware of this ability to call static methods before the base constructor however, which has plenty of other uses. You could do string manipulation, constructing complex object structures in a more readable fashion, code reuse, etc.

^*: That doesn't sound very Liskov, does it? The reality is a bit different, but it is beside the point of this post.

The CAPTCHA reinvented: PlayThru

blog@thorarin.net — Wed, 14 Aug 2013 00:42:00 +0200

The evolution of spam

Many blog owners will be familiar with one particular pest on the internet: spam bots. This blog is no exception, but I was determined to keep my pages clear of digital graffiti even when I don't have much time to post regularly.

Fortunately there are some nice and unobtrusive countermeasures available, like Akismet. They work pretty much like the spam detection for your email. For some time, this used to be enough to keep the spam bots at bay, but spammers are constantly changing their angle of attack. Many comments that are posted nowadays don't even contain any links anymore. With some luck, they can even pass for a comment from an interested reader. I'm not completely sure how exactly this helps the spammer, but no doubt they are trying to raise the reputation level of the IP address or email used to post the comment with, so t hey are more likely to pass through filters like Akismet later. In any case, spam filters are not as effective against these messages as they are against something containing one or more actual links.

One day I decided enough was enough. I caved and added a CAPTCHA to the comment form, in this case provided by reCAPTCHA (now owned by Google). Unfortunately this wasn't nearly as effective as I had hoped: OCR techniques, together with dictionaries no doubt have made this type of CAPTCHA surprisingly easy to circumvent. I was still receiving 150 to 200 spam comments each day on this humble website. Akismet filters most of them, but BlogEngine.NET makes me look at potential spam for approval or permanent deletion anyway.

Alternative CAPTCHA: PlayThru

While it seems that Google is aware that reCAPTCHA is no longer secure enough, their improvements are not yet publicly available. I went looking for alternatives. I found an interesting one on AreYouAHuman.com, called PlayThru. In order to pass as a human, the user has to play a simple game, which usually involves dragging the right objects onto another object. In the background it keeps some data on things like your mouse movement, to see if they appear sufficiently human-like.

How effective is this method at stopping spam? I can only speak for my personal situation, but so far it has reduced the spam from 150-200 comments a day to 0 (zero, zilch, nada). That sounds pretty awesome, right?

Long term effectiveness

I guess the real question here is: How long will this success last?

At least one person has already managed to successfully attack this new type of CAPTCHA using existing computer vision libraries. This person rightly comments that in the end, it depends on how many different types of games will be presented to the user. Also, it is currently possible for the bot to reload the CAPTCHA until a game appears that it knows how to solve. This seems like a design flaw to me, but I expect that once this would be abused, it would be easily fixed by the people at AreYouAHuman.

I cannot escape the idea that as this type of CAPTCHA becomes more popular, bots will be made to solve them. In the end it is the same old arms race between spammers and spam detection companies. However, for the time being I am satisfied with the results.

Using PlayThru in BlogEngine.NET

AreYouAHuman.com has examples available for a variety of platforms, as well as ready to use components for well known web applications such as Wordpress, Drupal, vBulletin and phpBB. I figured integrating into BlogEngine.NET would be extremely easy using the AyahControl they provide for ASP.NET WebForms. Unfortunately, the control did not work together with the custom built form submission of BlogEngine.NET. I had more luck with the AyahServiceIntegration class that is also provided.

Unfortunately the flexibility of BlogEngine.NET leaves something to be desired when it comes to CAPTCHAs. It supports two types built-in, which both appear as an extension. However, in reality key parts of the code are actually part of the main application. To add a third CAPTCHA type, I needed to mess with these bits. This means that if you want to use this prototype extension, you should first backup your files. You should also update to BlogEngine 2.8.0.1 before applying the changes.

Files:

AreYouAHuman.BlogEngine-0.5.zip (23.37 kB)

Updates to the Website

blog@thorarin.net — Thu, 27 Jun 2013 04:17:00 +0200

Just a quick note: I've updated the software for this website to BlogEngine.NET 2.8. Not a lot has changed since I've kept my original theme, but it does fix a few issues.

It also means that from now on you'll need to enter a CAPTCHA (provided by reCAPTCHA) in order to post comments. This is unfortunately necessary to stop excessive spamming that has been going for a while now. On BlogEngine 2.7 the reCAPTCHA plugin refused to work properly, but this seems to be fixed now.

If you happen to run into issues trying to post a comment – or anything else – drop me a note using the Contact form or on Twitter (@mveldhui). Also, authenticated users don't need to fill in a CAPTCHA for the moment, so you could also create an account. Thanks!