2

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 ?

Emmanuel DURIN
  • 4,803
  • 2
  • 28
  • 53

2 Answers2

7

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.

Fabio Cavalcante
  • 12,328
  • 3
  • 35
  • 43
2

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)

Martijn Stolk
  • 151
  • 1
  • 4
  • thanks for the answer, it helps. My next objective is to use a Mail custom class instead of a string - the custom class works pretty well with csx files - but I don't get deserialization working without csx. I ve got a deserialization problem. Have you got an idea ? – Emmanuel DURIN Feb 13 '17 at 13:53
  • I haven't used argument binding to custom classes (which I think you're referring to), so I can't speak from experience. Make sure the class you're using is public and its properties all have public getters/setters. The [Azure Functions developer reference](https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp) might have some additional suggestions. – Martijn Stolk Feb 13 '17 at 14:37
  • Actually I don't have to make a custom binding. As i didn't before in other Azure Functions. I just had to fix some deployment options amd it works without any extra development effort. – Emmanuel DURIN Feb 13 '17 at 15:17
  • Thank you very much. This helped me a lot. I'm wrapping my PreCompiled function now as well. The main reason I had trouble, was the differences between local development (working) and Azure (not working). It seems that there's a version mismatch in the Azure Web Jobs SDK used in Azure (old). https://github.com/projectkudu/AzureFunctionsPortal/issues/908 – Mark Monster Feb 14 '17 at 09:01