Failure to execute C# Lambda sample

[timheuer]

Trying to get C# Lambda service working, fails with http://pastebin.com/9D64pNAB  when using https://docs.aws.amazon.com/lambda/latest/dg/lambda-dotnet-create-deployment-package-toolkit.html 

[normj]

How are you calling your Lambda function? Is it with the SDK or through the Visual Studio toolkit? When sending a plain string to a Lambda function it needs to be quoted to make it a valid JSON document. When you do a function invoke in the function view inside the toolkit we auto add the quotes if we see the string does not start with a bracket.

[timheuer]

I'm doing it through the VS toolkit. Because of #6 I can't validate this again, but once I solve that (saw you responded) and I will screen record what I'm seeing.

[normj]

Thanks, that would be great

[timheuer]

Ok, please seen screencast of what I'm doing and the error I'm seeing: http://www.screencast.com/t/fgDeOTt9mxT

[PavelSafronov]

I think this is an issue with the Toolkit.

If I try the ToUpper sample, the following inputs appear to work without issue:

• foo
• "foo"
• "{ \"key3\": \"value3\", \"key2\": \"value2\", \"key1\": \"value1\" }"

The last is the Hello World example request, with all the inner quotes escaped and the entire JSON document on one line.

[normj]

So here is what I think is happening. I'm assuming your Lambda method is taking in a string. Lambda will use the Newtonsoft JSON library to convert the incoming request to the matching input type. If you pass in a full JSON document like

{ "key3": "value3", "key2": "value2", "key1": "value1" }

Newtonsoft will complain that it can't convert this JSON document into a string. You would either need a input type of type Dictionary<string, string>, Dictionary<string, object> or an object with Key1, Key2 and Key3 properties.

When you escape the JSON Document like this "{ \"key3\": \"value3\", \"key2\": \"value2\", \"key1\": \"value1\" }"

Now you run into problems of JSON's lack of support for multi line JSON documents. I'm looking to see what we can do in the toolkit to make this experience better since we know it is a string at this point and can detect the newline characters.

[timheuer]

@normj how would you suggest handling the Alexa payloads with the C# Lambda support? Given that the request may have different parameters, the 'string' input is the easiest way so that we could de-serialize into our own objects in the function, etc. Would you recommend having the function have Session, Version, Request properties?

ex: intent request:

{
  "session": {
    "new": false,
    "sessionId": "session1234",
    "attributes": {},
    "user": {
      "userId": null
    },
    "application": {
      "applicationId": "amzn1.echo-sdk-ams.app.[unique-value-here]"
    }
  },
  "version": "1.0",
  "request": {
    "intent": {
      "slots": {
        "Color": {
          "name": "Color",
          "value": "blue"
        }
      },
      "name": "MyColorIsIntent"
    },
    "type": "IntentRequest",
    "requestId": "request5678"
  }
}

[PavelSafronov]

The String input type will only work if data is sent to your function as a JSON string, for instance "test" or "{ \"data\": \"escaped data\" }". If you need to work with the exact JSON, use Stream as the input parameter. This stream will contain the payload and you can then deserialize it (or not) as appropriate. You can also easily get the string representation of the data using the StreamReader.ReadToEnd() method.

[timheuer]

Thanks @PavelSafronov -- I managed to whip up a modified SDK with some annotations that allows me to accept 'skill request' as my input. Blog post forthcoming.

[normj]

Please pass along the blog post. We are always excited to read about what people are doing with C# Lambda.

[chadbr]

@normj http://timheuer.com/blog/archive/2016/12/12/amazon-alexa-skill-using-c-sharp-dotnet-core.aspx

[timheuer]

@normj -- btw, in the test console in the toolkit as well, the results are escaped. Seeing that view tripped me up as well. Something to think about in this regard as well.

[normj]

Cool thanks for the post and your feedback. I'm going to close this issue because the immediate problem has been remedy but I see we have some usability in this view to work on.