Recently I created my own custom macro object for dasblog 1.9 but ran into a slight problem; it acted like the dll I created wasn't there.  Following this article (Creating custom macros for dasBlog) to a "T" still faired no better.  Not wanting to spend too much time on this and thinking that I was doing something wrong, I emailed Scott Hansleman (one of the main contributers to dasBlog) to see if he could spot my problem quickly.  Scott was great and we corresponded for most of the day trying different things to try and solve it.  He took a special interest in this because he said that this was the second inquiry in the same week about this error.

2006-09-29 14:00:18 PM
1
Error:
Error executing Macro: System.ArgumentNullException: Value cannot be null. Parameter name: type at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at newtelligence.DasBlog.Web.Core.MacrosFactory.CreateCustomMacrosInstance(SharedBasePage page, Entry item, String name) at newtelligence.DasBlog.Web.Core.TemplateProcessor.ProcessTemplate(SharedBasePage page, Entry entry, String templateString, Control contentPlaceHolder, Macros macros)
while processing .

2006-09-29 14:00:18 PM
1
Error:
Error executing macro: Test("hello", 1)|Extras. Make sure it you're calling it in your BlogTemplate with paratheses like 'myMacro()'. Macros with parameter lists and overloads must be called in this way. Exception: System.MissingMemberException: Member newtelligence.DasBlog.Web.Core.Macros.Test not found. at newtelligence.DasBlog.Web.Core.TemplateProcessor.InvokeMacro(Object obj, String expression) at newtelligence.DasBlog.Web.Core.TemplateProcessor.ProcessTemplate(SharedBasePage page, Entry entry, String templateString, Control contentPlaceHolder, Macros macros)
while processing .

From the looks of everything, it seemed that dasBlog could not find my custom class.  But why?  I made sure the changes in the web.config were correct because I thought for sure that was where the problem was.

Scott was able to duplicate the error once, then realized that he forgot to put his macro dll into the bin folder.  Emailing me again, he asked - as nicely as possible I might add - if I had forgot to put the dll in the bin directory.  Nope, I replied and even sent a screen shot of the servers bin directory.  To top it off, I sent him my solution to see if he could find anything wrong with my code or references.

While he was working away on solving this (thinking that there was something wrong with the macro factory code) I switched gears to see if building the macro using .NET framework 1.1 had anything to do with it.  I say this because the article on how to create custom dasBlog macros was using the .NET framework 2.0 so I did the same; why not, if the article did it in 2.0 why couldn't I?

Well the 1.1 solution worked!  Just then, I got another email from Scott asking if I was running dasBlog under 2.0 or not.  You see, creating macros under the 2.0 framework NEEDS dasBlog to be running under the 2.0 framework as well... DUH (as I smack myself in the forehead).

The problem all along was not with my code, not with the blog engine code but rather with the fact that I was trying to run a macro intended for .NET 2.0 under the 1.1 framework.

2 solutions presented themselves: A) Switch dasBlog to run under 2.0 or B) create the macro under 1.1.  Why is B even an option?  Because it is backward compatible with 2.0.  That's right, the 1.1 macro has more flexibility if I want to distribute this dll to others who, for one reason or another, are still running dasBlog under the 1.1 framework.

In summary, if you are trying to create a custom dasBlog macro and run into a problem, check to see that your website is running under the same .NET framework version as your solution (or lower).

A big thanks to Scott Hanselman for taking his time to help me with solve this dilema.