Question

I am attempting to convert a C# implementation of an emailer class using the RazorEngine to parse a razor template and subsequently send an email into VB.NET. This works great in C#, but I am running into issues with the conversion of a C# dynamic type to a VB.NET ‘object’ type (which from what I can discern is the closest equivalent).

For example, this code works wonderfully in C#:

public static string GetEmailBody(string templatePath, dynamic model)
{
      var template = File.ReadAllText(templatePath);
      var body = Razor.Parse(template, model);
      return body;
}

In my conversion to VB.NET, I ended up with a function call that looks like this:

Private Shared Function RenderEmailBody(strTemplate As String, model As Object) As String

  Dim template As String = File.ReadAllText(strTemplate)
  Dim body As String = Razor.Parse(template, model)

  Return body

End Function

And my call to it looks like this:

RenderEmailBody("mytemplate.vbhtml", New With { .Var1 = "1", .Var2 = "2" })

When I run this, however, the following exception is thrown:

TemplateCompilationException was unhandled by user code
Unable to compile template. 'object' does not contain a definition for 'Var1' and no extension method 'Var1' accepting a first argument of type 'object' could be found (are you missing a using directive or an assembly reference?)

When I inspect model while on a breakpoint, it seems to have Var1 and Var2 assigned correctly, but when I get to the call to Razor.Parse I continually have issues with it not interpreting my dynamic object correctly.

Am I doing something incorrectly here? Or there an inherent incompatibility between the two types?

Answer 1

Object and dynamic are two completely separate things. In the VB case, what you’ve done is unbox your model completely. They dynamic keyword in C# preserves the actual type without actually knowing it (humanly) at design time. However, when you use Object in this fashion you remove all actual reference to the type. You would need to recast your model to its specific type in order to have access to .Var1 in this case. Your best bet would be to adjust the signature of your method call either to have the specific type you’re looking for or use an interface that your common models can implement that defines the .Var1 or .Var2 properties.