Auto Import Related Types for Output Bindings (e.g. Sendgrid)

While trying to work with the SendGrid output binding, the JSON example works, but I’d prefer to use the SendGrid C# object because it provides a lot more functionality and a lot less boilerplate work.

However, I found the sendgrid types were not natively available in my session. As a workaround, I did this (in Azure Functions Core Tools):

Add-Type -Path C:\Users\JGrote\AppData\Local\Temp\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle\1.0.0\bin\sendgrid.dll -verbose

And now I can work with a sendgrid object like the C# example.

Would it be possible to just have these available for ease of use depending on the registered output bindings? At a minimum some higher-class Powershell cmdlets could then be made to wrap around the object and make things like constructing a SendGrid email more structured vs. scraping a raw JSON file together.

Issue with using native C# object

At least for SendGrid, I can’t make this work currently using the default example. Its almost as if the powershell worker just parses the object into JSON, because when it hits the API it says it needs a “To” instead of “Tos” and “Content” instead of “Contents”

(To: specified in outputbinding and API key specified in local.settings.json)

# Write out the queue message and insertion time to the information log.
$isTestEnvironment = $env:FUNCTIONS_CORETOOLS_ENVIRONMENT
if ($isTestEnvironment) {
    $ExtensionBundleBinPath = join-path $env:LOCALAPPDATA "Temp\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle\1.0.0\bin"
} else {
    $ExtensionBundleBinPath = join-path $env:ProgramFiles "FuncExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle\1.0.0\bin"
}
$sendGridDllPath = join-path $ExtensionBundleBinPath "sendgrid.dll"
Add-Type -Path $sendGridDLLPath


$message = New-Object Sendgrid.Helpers.Mail.SendGridMessage
$message.AddContent("text/plain", "This is a test message")
$message.setFrom("[e-mail]","Azure Functions Test Mail")
$message.setSubject("Test Azure Functions Message")
$message | convertto-json | fl | out-string
Push-OutputBinding -Name "SendGridOut" -Value $message

System.Private.CoreLib: Exception while executing function: Functions.NotifyUDPMessage-EmailDirect. Microsoft.Azure.WebJobs.Host: Error while handling parameter _binder after function returned:. Microsoft.Azure.WebJobs.Extensions.SendGrid: {"errors":[{"message":"Unless a valid template_id is provided, the content parameter is required. There must be at least one defined content block. We typically suggest
both text/plain and text/html blocks are included, but only one block is required.","field":"content","help":"http://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/errors.html#message.content"}]}.

Workaround

The message object has a serialize method that emits the proper json, so you can still at least use it as a “factory” of sorts to prepare the message.

Push-OutputBinding -Name "SendGridOut" -Value $message.Serialize()

EDIT: Updated example to work in Hosted Azure Functions as well (bad example using “hardcoded” path)

[daxian-dbw]

The "adding assemblies relevant to declared output binding" part can be helped with by implementing the function.proj support (#173). Then we probably can update the host to generate the appropriate funciton.proj that references to the nuget package corresponding to the output bindings declared in function.json.

[TylerLeonhardt]

Right, this issue is two fold though for the complete user experience

1. The types should be available if you add the extension to your Function App
2. You shouldn’t have to call a method like .Serialize() in order to get an output binding working. It should “just work” because we know what type of output binding it is

This, to me, is how we properly support types pulled in by func extensions