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

[JustinGrote]

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("test@mytestfunction.azurewebsites.net","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)

[TylerLeonhardt]

This is the result of PowerShell function apps running out of process in the PowerShell worker while C# functions run inside the Azure Functions Host process itself. This means that:

• PowerShell functions don't have access to the types you want
• Any object must be serialized to JSON before the PowerShell worker process sends the response back to the Azure Functions Host process... And since we're not checking for this SendGrid type, we just run the object through the same code used for ConvertTo-Json.

I think this is one of the scenarios where live object support would be nice and would fix this issue.

We can close this issue to that one... But before we do, we could consider fixing just this issue - if the Value of a SendGrid binding is the SendGrid .NET type, we can call Serialize() on it... Instead of the normal ConvertToJson call.

[TylerLeonhardt]

I'd like to see what @AnatoliB thinks - let me know if you want me to supply code links. I'm just on my phone atm so I didn't have time to grab them

[JustinGrote]

@tylerleonhart this was less about the grpc serialization, and more about auto adding the dll assemblies relevant to the loaded output bindings so they don't have to be hunted down like my awkward workaround. Maybe it's too case-by-case, I don't know if the extension bundles have any kind of "hints" in this regard.

[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

[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.

[JustinGrote]

Related for Posterity, if you're using the output binding in table storage, it has to be in JSON format, though it comes in from the table as a hashtable (probably because it was auto-converted from JSON), not intuitive but it works.

Basically, my operating philosophy on working with output bindings has been to follow the Javascript example and replace context.bindings.myOutputBinding.push with Push-OutputBinding -Name myOutputBinding

[daxian-dbw]

if you're using the output binding in table storage, it has to be in JSON format, though it comes in from the table as a hashtable (probably because it was auto-converted from JSON)

I assume the NodeJS worker does the same (auto-convert the JSON string to an object), no?

[Edited] We actually copied that behavior from NodeJS worker -- when the string payload is JSON format, convert it to an object before passed it on to the user.

[JustinGrote]

Probably, I have no idea honestly :) Also confirmed at least for table output that just passing a hash table works, you don't have to convert to json first (assume the worker does it on the backend)

…

On Mon, Jun 17, 2019, 11:41 AM Dongbo Wang ***@***.***> wrote: if you're using the output binding in table storage, it has to be in JSON format, though it comes in from the table as a hashtable (probably because it was auto-converted from JSON) I assume the NodeJS worker does the same (auto-convert the JSON string to an object), no? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#260?email_source=notifications&email_token=ADUNKURUHF6MXVE2Z34JA43P27LEHA5CNFSM4HYJC5E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX4CUCA#issuecomment-502802952>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADUNKUXMWHEYYCIP7VCWST3P27LEHANCNFSM4HYJC5EQ> .