C# Azure Function in Dll doesn't work in Azure (but in emulator)

Question

Because I want an Azure Function totally compiled before deploying, and because I want to have all the benefits of refactorings (automatic renamings) before deploying, I want to get rid of the Csx file and use a Dll.

And I want all my code to be in .Dll - fully compiled.

So it works fine in the local emulator, but I can't get it to work in Azure

I always get the same error message in the log file :

MailSenderFunction: Unable to determine the primary function script.
Try renaming your entry point script to 'run' (or 'index' in the case of     Node),
or alternatively you can specify the name of the entry point script explicitly by adding a 'scriptFile' property to your function metadata.

And I don't see my function appear in the Function App in the portal.

function.json :

{
  "disabled": false,
  "scriptFile": "./bin/MailSenderFunctionLib.dll",
  "entryPoint": "MyCompany.MailSenderFunctionLib.MailSenderFunctionProcessor.RunCsxLess",
  "bindings": [
    {
      ...
    }
  ]
}

The Dll code :

namespace MyCompany.MailSenderFunctionLib
{
  public class MailSenderFunctionProcessor
  {
    public static void RunCsxLess(Mail mail)
    {
      // ...
    }
}

The dll is in the bin directory of the function, not the bin directory of the App Function

Any Idea ?

Answer 1

I had to put the dlls in the same directory as the function.json and remove the directory prefix from scriptFile. I was unable to get it to work in a subdirectory.

A workaround in which I'm able to get it to work in a subdirectory is to use a run.csx file that imports the .dll and just executes the static method in that dll. Such as:

#r "DLLs\MyFunction.dll"

using System;

public static void Run(string myEventHubMessage, TraceWriter log)
{
    MyFunction.Program.Run(myEventHubMessage, log);
}

(In this example I was using an eventHubTrigger)

Answer 2

This will be fully supported on the next release of the runtime ( > 1.0.10690).

You can find more information about that enhancement here

The reason you observed the different behavior when running locally is because the CLI preview is (unfortunately) ahead of the hosted environment at this point and using the new runtime bits. We're changing the process to ensure those releases are in lockstep with each other moving forward.