Функция C# Azure в Dll не работает в Azure (но в эмуляторе)

Поскольку я хочу, чтобы функция Azure была полностью скомпилирована перед развертыванием, и поскольку я хочу получить все преимущества рефакторинга (автоматического переименования) перед развертыванием, я хочу избавиться от файла Csx и использовать Dll.

И я хочу, чтобы весь мой код был в.Dll - полностью скомпилирован.

Так что он отлично работает в локальном эмуляторе, но я не могу заставить его работать в Azure

Я всегда получаю одно и то же сообщение об ошибке в файле журнала:

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.

И я не вижу, чтобы моя функция появилась в приложении Function на портале.

function.json:

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

Код Dll:

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

DLL находится в каталоге bin функции, а не в каталоге bin функции приложения

Любая идея?

Источник

2 ответа

Решение

Мне пришлось поместить dll в тот же каталог, что и function.json, и удалить префикс каталога из scriptFile. Я не смог заставить его работать в подкаталоге.

Обходной путь, при котором я могу заставить его работать в подкаталоге, состоит в том, чтобы использовать файл run.csx, который импортирует.dll и просто выполняет статический метод в этой dll. Такие как:

#r "DLLs\MyFunction.dll"

using System;

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

(В этом примере я использовал eventHubTrigger)

Источник

Это будет полностью поддерживаться в следующем выпуске среды выполнения ( > 1.0.10690).

Вы можете найти больше информации об этом улучшении здесь

Причина, по которой вы наблюдали различное поведение при локальном запуске, заключается в том, что предварительный просмотр CLI (к сожалению) опережает размещенную среду на данный момент и использует новые биты времени выполнения. Мы меняем процесс, чтобы гарантировать, что эти выпуски находятся в шаговой доступности друг с другом.

Источник
Другие вопросы по тегам