So I have some Azure Functions I need to publish, which I want to do via a functions project. However, those functions rely on references to class libraries within my solution, and the references do not work within a functions project, is there a way around this?
Edit: After adding the references to the other projects, when "using" the namespaces in which the classes are kept, the compiler throws an error "cannot resolve symbol", it is as if the reference does not exist. The functions project will not build because it cannot find the namespace in which the classes exist
Verify that each project targets the same version of .NET framework. I had the same problem until I noticed that the referenced project targeted 4.7.1, but my Azure function project targeted 4.6.1. Changing the referenced project to match the Azure function project resolved the issue.
There are a couple more steps to consume assemblies if they're not exposed by default in Azure Functions. If it's a custom assembly you have to make sure it's included in the bin folder. Then you have to make sure you're using the #r directive. Are you doing both of those things? Include your code header and settings if so.
This page has the list of assemblies that are visible to Azure Functions, some still requiring the #r directive:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp#referencing-external-assemblies
The following assemblies are automatically added by the Azure Functions hosting environment:
mscorlib
System
System.Core
System.Xml
System.Net.Http
Microsoft.Azure.WebJobs
Microsoft.Azure.WebJobs.Host
Microsoft.Azure.WebJobs.Extensions
System.Web.Http
System.Net.Http.Formatting
The following assemblies may be referenced by simple-name (for
example, #r "AssemblyName"): Newtonsoft.Json
Microsoft.WindowsAzure.Storage Microsoft.ServiceBus
Microsoft.AspNet.WebHooks.Receivers Microsoft.AspNet.WebHooks.Common
Microsoft.Azure.NotificationHubs
Related
Guys I know that the azure functions cli has a dependency with RestSharp.dll and I think that is conflicting with one of my Azure Functions.
I am getting a runtime type exception
System.TypeLoadException: 'Could not load type 'RestSharp.IAuthenticator' from assembly 'RestSharp, Version=105.2.3.0, Culture=neutral, PublicKeyToken=null'.'
Now my azure function is dependent on RestSharp nuget Version 104.4.0.0. There is no reference in my project to Version 105.2.3.0. Here is the interesting thing. In my despair I searched my entire computer for the culprit dll version 105.2.3.0 and I found it at AppData\local\Azure.Functions.Cli\1.0.12
Is that it ? Is the Azure functions runtime trying to link with its RestSharp.dll version instead of the dll version of my project ?
Runtime should technically load version 104.4.0.0. However it is still loading the version referred by the runtime (105.2.3.0). I was able to verify this behavior. Have filed a bug for this https://github.com/Azure/azure-functions-host/issues/2832.
In the meantime is it possible to do one of the following:
Update the code to use 105.2.3.0, I see RestSharp.IAuthenticator type is present. It is under a different namespace. There should be another method exposing the same functionality
If the function app is not being used in prod. You could use the beta runtime. You should not encounter this issue in beta runtime (v2.x)
A .csx file inside an Azure Function can use a nuget package if it's listed in the function's project.json file. Ex:
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.ProjectOxford.Face": "1.1.0"
}
}
}
}
But what happens with shared .csx files that are placed under the Function App's root (i.e. not in a specific function)? Is there a way to introduce a nuget package at the App Function (root) level?
I've found a workaround in uploading the nuget package's dll to a shared bin folder as explained in the Azure Functions C# developer reference:
Shared assemblies are shared across all functions within a function app. To reference a custom assembly, upload the assembly to your function app, such as in a bin folder in the function app root.
Is there a way to do this better so my code depends on the nuget package and not on a dll?
The actual package references are managed in each function (i.e. there's no function app level set of package references), but when brought into your function by using the #load directive, shared CSX files become part of the same compilation unit, and are able to consume assembly/package references defined in your function. But you still need to manage those at the function level.
You can think of the #load behavior as a linked file in a regular C# project, where the file is brought in, but compiled within the context of the project. That applies to functions here.
We have an Azure function which references an external assembly via a private Nuget feed.
The problem we're having is that we have two different versions of Microsoft.Azure.WebJobs.dll - one which is a dependency of our nuget package and another which I'm assuming is being provided by the runtime.
error CS1503: Argument 2: cannot convert from 'Microsoft.Azure.WebJobs.ICollector<Microsoft.WindowsAzure.Storage.Table.ITableEntity> [D:\Program Files (x86)\SiteExtensions\Functions\1.0.10635\bin\Microsoft.Azure.WebJobs.dll]' to 'Microsoft.Azure.WebJobs.ICollector<Microsoft.WindowsAzure.Storage.Table.ITableEntity>
I found this question which says that binding redirects are not supported:
Azure Functions binding redirect
We could try to remove our dependency on that library, or we could match the version used by Azure Functions, but I think we're going to have the same problem with using Microsoft.WindowsAzure.Storage anyway.
Please advise!
You are correct that binding redirects are not supported. The runtime has its own dependencies on the WebJobs SDK and Storage libraries so objects passed into your functions will be from those versions. I recommend removing your dependencies on other versions and snapping to ours. Note that for these libraries, you don't have to add your own package reference, you can reference ours in your function code via:
#r "WindowsAzure.Storage"
You don't need to add explicit #r references for WebJobs SDK types (e.g. ICollector<T>) - the runtime adds that assembly implicitly. Of course this only applies for function code we're compiling for you, not code coming from your external packages.
In the future we might improve things in this area, but for now you'll be swimming up stream if you try to use conflicting versions.
I am facing strange issues with privates assemblies in azure functions, I have an Azure Function App with five functions which have a shared bin folder where I place my assemblies, these assemblies in turn depend on Entity Framework and LinqKit for which I have added dependencies in all the project.json files for each function but private assemblies are unable to get reference to these and failing. Please help.
Project.json --
{
"frameworks": {
"net46":{
"dependencies": {
"EntityFramework": "6.1.3",
"Newtonsoft.Json": "9.0.1",
"LinqKit": "1.1.7.2"
}
}
}
}
To clarify further in my Function App I have five different functions which depend on 2 private assemblies and I do not want to keep separate copies (as this might cause different versions of the same dll in different folder causing issues) in each function so I have created a shared bin folder from where the private assemblies are referenced but the issue happens as these private assemblies further depend on some nuget packages which they are not able to find them --
#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;
If you want to use your private assembly (not from nuget) you have to do this:
Connect to Functions App ftp
Create bin folder in folder with your function (where is run.csx)
Upload your custom assembly to newly created bin folder
Update function code and add reference
Unfortunately this dll needs to be in each function folder where needed.
Example
#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, "");
}
Will spend a bit of time trying to repro your scenario as, at a first glance, it should work as expected. In the meantime, a couple of options you have are:
1- When deploying your shared assemblies, copy all the binaries from your project output, including their dependencies. The shared assemblies folder will be in the probing logic and they would be resolved from there. This would also eliminate the need to have a project.json referencing the dependencies on each function.
2- Create a NuGet package for your shared assemblies and, on that package, specify your package dependencies (EF and LinqKit), publish that package to a private feed (which could be something like MyGet or even a folder in your function app). Your functions would only need to reference that package and not its dependencies, as those would be automatically resolved. You can find more information about using custom sources here: How do you use custom NuGet feeds with Azure Functions?
Although it may require a bit more work at first, both options have advantages over your original approach (including eliminating the need for the functions to be aware of indirect dependencies) and should be more reliable.
Hope this helps!
I am facing a strange problem with packaging an assembly for Azure worker role. I am building a sample Azure cloud application having one website and a worker role. I am referencing a third party assembly, myasm.dll in both website and worker role project. The myasm.dll has dependency on two other assemblies. When I build the project all three(myasm.dll and two dependent assemblies) third party assemblies are getting copied to bin directory for both website and worker role projects. So far so good.
When packaging is done for worker role, off the three third party assemblies, only two assemblies are included in the package, the third assembly is not included. Strangely enough, packaging of Website project includes all three assemblies. I created one more worker role to test the behavior but same behavior was seen again.
Is this a known issue or something? Any help is highly appreciated.
I use VS2012 Update 4.
Package will not include any dll which is not explicitly used in your project or referenced. I know this problem occurs when you do not use type explicitly in a your project(old bug raised - with won't fix status)
I guess your best option is to explicitly reference those missing dll's (see here) or try to add dummy usage of types from missing dependencies.