While developing an Azure Function application, using this tutorial, I encountered a problem.

Ultimately, using func new generated my function (the run.csx file) which looked like this:

Side note: the mySbMsg is important – it’s defined in the function.json bindings, and must match.

However, there was a problem.
When sending messages to my topic, they weren’t being picked up by my function.

I was using some very simplistic code to send messages to my topic:

The messages were definitely being delievered to the topic – I could see that in the Azure portal.

However, the function wasn’t picking them up.

The issue was around the string mySbMsg parameter.
The scaffolding assumed that it would be a string – but it is in fact, a byte[] (due to me serializing the JSON)

Changing this parameter to be a byte[] – and my messages are now received by my locally running function.

Calling an api and deserializing the returned json into a type is something I have to do quite often.

I used to use the following:

If the JSON returned is large, we’ll often get an Out Of Memory Exception

From the docs

To minimize memory usage and the number of objects allocated, Json.NET supports serializing and deserializing directly to a stream.

To rectify this, we can instead use Streams


In my example, where the JSON has a nested ‘result’ element, you’ll also need a class to represent this (see TypeContainingMyResult above)

My current contract involves working on a project based on Umbraco.

Unit testing Umbraco, can be a bit tricky, especially given the existence of the static ApplicationContext.Current.Services class, which contains handy references to the Umbraco services – provided by a static type! We can’t mock this.

So, I created a little wrapper around this that would allow us to mock the returned service, via an interface

In the implementation, I use reflection to return the underlying service from ApplicationContext.Current:

In a rush, I’d called my migration “vendorServiceKEy”
Which had resulted in my migration being named 201512102031458_vendorServiceKEy

I then ran migrations with update-database.

Now, when I renamed the class manually, to sort out my OCD, the next time my application ran, I got

There is already an object named xxx in the database

My _MigrationHistory table contained the following entry:



Renaming this to the correctly camel-cased version allowed EF to know this migration (although renamed) had already been run, and to ignore it

I ran into this issue when deploying an application that uses the DynamicPDF Rasterizer.


After emailing support, who got back to me within the promised 24 hours, they offered some good suggestions.

The solution for me was to use the installer provided on their download page, which in turn installs the pre-requisites (Visual C++ distributable)
Secondly, I changed the reference in my project to the x64 version of the binary, and changed the build platform target



Page 1 of 5