When you create a new Azure Function with a Service Bus queue trigger, the initial run.csx takes a string as input and looks like this:
The benefit of this is that the function infrastructure hides all of the complexity of the service bus from you making everything nice and simple. However, I like to get the real message object instead of its payload because the messages properties support a number of useful scenarios. Among these properties is the message’s ContentType which is useful when the bus delivers more than one type of message.
It isn’t obvious from the documentation how to get the brokered message instead of a simple string, and there is a wrinkle involved if you like to do as I do and deliver the bulk of your functionality in complied assemblies.
Scenario #1 – C# Script Only
As your function is being triggered by a service bus message, it makes sense that Microsoft.Azure.ServiceBus.dll is loaded by default. You don’t need to do anything other than reference it and change the method signature and you can leave your function.json file alone. In this case I changed the binding in function.json so that the name is receivedMessage instead of myQueueItem, but that’s only because I felt like it! J
You can write your function as follows:
Notice that the assembly import line does not include an extension. If you include one, you will get a compile error!
Scenario #2 – Compiled Assemblies
If you are using compiled assemblies, the story is a little more nuanced and also potentially more dangerous because the potential for a version mismatch exists.
Assemblies deployed to the function go into the bin folder below the run.csx file. Generally, what this entails is copying all of the build output from your project to bin. When you do this, it becomes possible to reference the assembly using the dll file extension as follows:
This compiles because the assembly is in bin. You can still leave the file extension out. But, should you?
To test this out I made a little test assembly that references a very old version of Microsoft.ServiceBus.dll; version 184.108.40.206. It returns a string that contains the assembly name along with the message’s content type.
The calling function logs the assembly name and then the output of the compiled function.
Somewhat surprisingly, this works and the output of the function’s compilation and execution looks like this:
As expected, everything is using the version of the assembly that was loaded by Azure Functions (220.127.116.11) and not the version referenced by the compiled project (18.104.22.168). I actually expected to get a runtime error or at the very least a warning!
If I remove the file extension, it still works, but at least this time I get a warning!
The Moral of the Story
That this works at all has a lot to do with the fact that what I am using of the BrokeredMessage class is compatible between versions 1.8 and 3.0. Had I written the test differently, it would not have worked.
There is clearly some danger here that requires a function developer to know when they are using assemblies that will already be loaded and have the potential to not match the build. The function compilation does not recompile the deployed assemblies and has no way to know about this potential runtime mismatch, but it can know that what the C# Script file is using conflicts with what is in the bin folder as long as you leave the file extension off of the reference.