Intranoggin

Blither, Blather, Web Content Management.
Blog » Converting Existing Azure Functions to Precompiled Functions

Converting Existing Azure Functions to Precompiled Functions

At this point Microsoft released Visual Studio and there was the telltale sign that the function project type was no longer supported. Worse yet, installing VS 2017 seemed to break compatibility within VS 2015 as well. No worries. After about a week, Donna Malayeri released this blog post: Publishing a .NET class library as a Function App.

First, I’ll create a new solution. Following the instructions from Donna’s post, this will be an Empty ASP.Net Web Application using the .NET Framework. I’ll give it the same name as my original, but put it in a temporary location.

New Project

Empty

Now, close down Visual Studio. Use Windows Explorer to navigate to where your new solution and project files were created. Copy the whole directory and dump it right over top of the original. This will clobber the .sln and project files., but all the code and folder structure we’ve created will be intact.

Overwrite Files

You can drill in and delete the .funproj and .funproj.user files. Then open your solution file in Visual Studio 2017.

A look at the changes right now will show just the few files we’ve added, the removed .funproj file, and the updated .sln.

Changes

Go back to your Solution Explorer and turn on “Show all files”. Then select all of our function folders and right click > Include them in the project.

Include More Files

I had also been using another class library, that I’ll be blogging about soon, so I needed to right click the solution and add an existing project.

Add Existing Project

Next, we’ll need to get all of our run.csx functions put into class files. The article above would have you rename your files and add in the class wrappers, but I come at it from the other side. I add a class file to the folder and then copy the function from the run.csx file into the class.

Copy:

Copy Run

Paste:

Paste Run

Don’t forget to update your using statement/assembly references at the top of your classes. You can then delete your run.csx file.

Note: You may see some issues about missing assembly references. Ignore these for now; we’ll add our NuGet packages shortly.

Repeat the process to create a new class file for each of your functions.

Right click your references list and select manage NuGet packages.

Search for and add in the following packages:

  • Microsoft.Azure.WebJobs
    • needed for function logging.
    • also adds several other packages, including
      • Newtonsoft.Json
      • Microsoft.Azure.WebJobs.Core
      • WindowsAzure.Storage
  • Microsoft.Azure.WebJobs.Extensions
    • needed for timer triggers – this is where the TimerInfo object is defined.
  • Microsoft.AspNet.WebApi.core
    • Includes some extension methods to system.net.http that are used throughout the http trigger examples.
    • Also adds Microsoft.AspNet.WebApi.Client
  • System.net.Http.Formatting.Extension (by andre.agostinho)
    • includes extension methods that allow awaitable tasks.

The previous version of the function compiler added in some references for us automatically. We’ll need to add these in manually now.

  • Anywhere you were using IAsyncCollector<T>, or the TimerInfo object, add in an assembly reference “using Microsoft.Azure.WebJobs”
  • Anywhere you were using a TraceWriter to log, you’ll need to ensure you add in an assembly reference “using Microsoft.Azure.WebJobs.Host” at the top of your class files.
  • Anywhere you were returning an async Task<T> add in an assembly reference, “using System.Threading.Tasks”
  • Anywhere you were using HttpRequestMessage or HttpResponseMessage, add in assembly references “using System.Net” and “using System.Net.Http”

You should be able to successfully compile your solution now, but we aren’t quite done yet. We need to go back and adjust all the function.json files to include our new entry points. They’ll each need an additional setting for the scriptFile (our .dll) and the entryPoint (the corresponding run function).

{
  "disabled": false,
  "scriptFile": "..\\bin\\AlexaFunctions.dll",
  "entryPoint": "AlexaFunctions.AlexaHelloWorld.HelloWorld.Run",

  "bindings": [
    {
      "authLevel": "function",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in"
    },
    {
      "direction": "out",
      "name": "res",
      "type": "http"
    }
  ]
}

 

Now we can set up our project to use func.exe to run local.

Configure F5

NOTE: If you don’t specify a port, the functions will run on 7071. There is a bug in windows that occasionally keeps a port blocked even when it’s no longer in use. If you run into the bug, you’ll see the functions cli open flash a red message and immediately close. Running the cli manually will show you this:

Port Error

You can add a –p <port number> to the command line arguments in Visual Studio to change to a different port. (host start –p 7072).


Posted: 3/21/2017 6:00:00 AM by Ryan Miller | with 0 comments