2016-10-19 1 views
0

У меня возникли проблемы с рядами рядовых сборок в лазурных функциях, у меня есть приложение Azure Function с пятью функциями, которые имеют общую папку bin, где я размещаю свои сборки, эти сборки в очередь зависят от Entity Framework и LinqKit, для которых я добавил зависимости во всех файлах project.json для каждой функции, но частные сборки не могут получить ссылку на них и провалиться. Пожалуйста помоги. Project.json -Где разместить зависимости для общих сборок в Azure-функциях

{ 
    "frameworks": { 
    "net46":{ 
     "dependencies": { 
     "EntityFramework": "6.1.3", 
     "Newtonsoft.Json": "9.0.1", 
     "LinqKit": "1.1.7.2" 
     }  
    } 
    } 
} 

Для дальнейшего уточнения в моей функции App У меня есть пять различных функций, которые зависят от 2-х частных собраний, и я не хочу, чтобы отдельные копии (так как это может вызвать различные версии одного и того же dll в разных папках, вызывающих проблемы) в каждой функции, поэтому я создал общую папку bin, из которой ссылаются частные сборки, но проблема возникает, поскольку эти частные сборки в дальнейшем зависят от некоторых пакетов nuget, которые они не могут найти.

#r "..\bin\Marketware.Domain.dll" 
#r "..\bin\Marketware.AzureIntegration.dll" 

using System; 
using System.Collections.Generic; 
using System.Data.Entity; 
using System.Diagnostics.Eventing.Reader; 
+0

Возможный дубликат [Выполнение предварительно скомпилированного .NET-кода как функции Azure] (http: // stackoverflow.com/questions/36436917/execute-pre-compiled-net-code-as-azure-function) – Thomas

ответ

1

будет потратить немного времени, пытаясь Репрографический ваш сценарий, как, на первый взгляд, он должен работать, как ожидалось. В то же время у вас есть несколько вариантов:

1 При развертывании общих сборок скопируйте все двоичные файлы из вашего проекта, включая их зависимости. Папка общих сборок будет в логике зондирования, и они будут решены оттуда. Это также устранит необходимость иметь проект. Json, ссылающийся на зависимости от каждой функции.

2- Создайте пакет NuGet для ваших общих сборок и в этом пакете укажите свои зависимости пакетов (EF и LinqKit), опубликуйте этот пакет в приватном канале (который может быть чем-то вроде MyGet или даже папки в вашем функциональное приложение). Ваши функции должны были бы только ссылаться на этот пакет, а не на его зависимости, поскольку они будут автоматически разрешены. Дополнительную информацию об использовании настраиваемых источников вы можете найти здесь: How do you use custom NuGet feeds with Azure Functions?

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

Надеюсь, это поможет!

+0

Думая о первом подходе, поскольку код в моем функциональном коде также зависит от EF и LinqKit, кроме общих сборок, он сможет получите ссылку на них, если я поместил их в общий ящик вместе с общими сборками. – akhil

+0

Да, вы могли бы добавить эти ссылки так же, как с общими сборками, или продолжать использовать nuget. –

+0

И, чтобы быть уверенным, что это понятно, второй подход сделает эти косвенные зависимости доступными для вашего кода функции. –

4

Если вы хотите использовать свою частную сборку (не из NuGet), вы должны сделать это:

  1. Подключение к функциям приложения FTP
  2. Создать бен папку в папке с вашей функцией (где находится run.csx)
  3. Загрузить пользовательскую сборку вновь созданную папку бен
  4. Обновить код функции и добавить ссылки

к сожалению, эта длл должна быть в каждой папке функций, где это необходимо.

Пример

#r "CustomAssembly.dll" 

using System.Net; 
using CustomAssembly; 

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log) 
{ 
    CustomAssemblyClass.MethodName(); // here call your method 
    return req.CreateResponse(HttpStatusCode.OK, ""); 
}