image With BE.NET 1.5 release candidate out of the door, it is a good time to look at some of the new features. Most of them are small and incremental, but nevertheless are interesting. One such feature is support for compiled extensions. There are several reasons you want to compile extension rather than provide source code, such as security, protecting intellectual property, simplifying deployment (for large extensions) etc. If you find a reason to choose this route, this guide is for you.

cpld-1Let’s start with creating new code library project in Visual Studio or C# Express edition, I named mine “CompiledCsExt”.  When project is created, remove added by default Class1.cs and set reference to BlogEngine core library. You can copy BlogEngine.Core.dll from your website or set reference to local BlgoEngine source project if you have it set up and running, it does not matter. What matters is DLL version – you want to reference specific version for which you are going to distribute your extension. (it is possible to target multiple versions, I’ll get into more details down the road).

cpld-2 In this example, I’m targeting BE.NET version 1.4.5.17, but normally you would choose stable version like 1.4, 1.5 etc. – version that most of the bloggers use on their sites. You can check version number by right-clicking BlogEngine.Core.Dll in the Windows file explorer and selecting properties/details.

cpld-3 Make sure you have right version by examining its properties in the solution explorer (on the left). When reference is set, we are ready to create new extension. I added a class named “CompiledCsTest”, it is as simple as it can be because we just going to test compilation and nothing else. All this extension will do is just append few words to the end of post body so that we can verify that it works. You can take a look at this series of tutorials to familiarize yourself with extensions and the way they work in the BlogEngine. Source code for compiled extension listed down below, nothing ground-breaking there – hook up into the post serving event and manipulate text in the post body adding test message to the tail.

using System;
using BlogEngine.Core;
using BlogEngine.Core.Web.Controls;
 
namespace CompiledCsExt
{
    [Extension("Testing compiled extensions in BE 1.5", "1.0", "rtur.net")]
    public class CompiledCsTest
    {
        public CompiledCsTest()
        {
            Post.Serving += Post_Serving;
        }
 
        void Post_Serving(object sender, ServingEventArgs e)
        {
            e.Body += "<br />Added by <b>CompiledCsTest</b> extension.";
        }
    }
}

Another important thing is to tell BlogEngine to look at our assembly for extensions, it is not going to waist time examining every class in every DLL in the “bin” folder. Open AssemblyInfo.cs (project meta file added by Visual Studio) and set AssemblyConfiguration attribute to “BlogEngineExtension” to notify BE that this assembly actually contains extension(s).

// General Information about an assembly is controlled through the following 
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("CompiledCsExt")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("BlogEngineExtension")]
[assembly: AssemblyCompany("")]

That’s it. Compile class library and it will produce CompiledCsExt.dll. To distribute it to existing BlogEngine installation, simply copy DLL to the “bin” folder. ASP.NET will restart application and, when you navigate to the home page, you should see line added by our extension to the end of every post.

cpld-4

One last thing, when BlogEngine version differ with one you referenced while compiling extension, you’ll see something like this while trying to run web site:

cpld-6

Here I compiled DLL using BE core version 1.4.5.16 and deployed it to the site running BE 1.4.5.17. ASP.NET does not see these two versions as interchangeable, and rightly so – it has no way of knowing if there were breaking changes between these two versions. You’ll have to either re-compile DLL for each new BE release (safe but not always practical) or specifically tell compiler that you take responsibility and guarantee that both versions are compatible and loading new version at run time will not break anything in your extension’s code. To do this, you need to add section in web.config under configuration/runtime, similar as shown below: 

<configuration>
  <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="BlogEngine.Core" publicKeyToken="fed3cbd6fd4e62d0" culture="neutral"/>
          <bindingRedirect oldVersion="1.4.5.16" newVersion="1.4.5.17"/>
        </dependentAssembly>
      </assemblyBinding>
  </runtime>
</configuration>

With this taken care of, you should be able to use compiled extensions with BE.NET 1.5 pretty easily. It is not necessarily easier or more convenient than adding class to App_Code folder, but it gives you another choice in case you need it.

Share/Save/Bookmark
Signature

Comments

4/8/2009 1:08:49 PM #

Coose

What about ExtensionSettings?  ExtensionSettings, ExtensionParameter, and ExtensionManager are in the App_Code folder, so you can't use them from a compiled assembly.

Coose |

4/8/2009 9:27:14 PM #

rtur.net

Unfortunately, you can't use extension manager directly from another assembly exactly for reason you mentioned. I agree this is a huge limitation, it will be removed later (there will be another project in the BE solution). Now if you need persist any data, you'll have to provide implementation within extension itself.

rtur.net |

6/30/2009 9:40:59 AM #

cariaja

thanks for share, waiting for your next article, happy blogging

cariaja |

Comments are closed
<<  March 2010  >>
SuMoTuWeThFrSa
28123456
78910111213
14151617181920
21222324252627
28293031123
45678910
Enhanced with Snapshots

Subscribe to Rtur.net