Locking issue with DLLs in Functions

I’m having issues of files locking within a Functions App, that is preventing Continuous Delivery. The issue presents itself when referencing a .NET DLL within the function, running a test, then attempting to deploy a new version of the referenced .NET DLL.

Here are the steps needed to replicate the issue:

1. Create a simple class library in Visual Studio called “FunctionsTest.Calculation” and build.

using System;
using System.Text;
namespace FunctionsTest.Calculation
{
    public class SomeWork
    {
        public string Execute(string inputTest)
        {
            return String.Format("result {0}", inputTest);
        }
    }
}

1. Create a new Functions App
2. Create a new Manually triggered C# Function called “ManualTriggerCSharp1”, with the following code

#r "FunctionsTest.Calculation.dll"
using System;
using FunctionsTest.Calculation;

public static void Run(string input, TraceWriter log)
{
    log.Info($"C# manually triggered function called with input: {input}");
    var somework = new SomeWork();
    var result = somework.Execute(input);
    log.Info("result:" + result );
}

1. Upload a copy of the generated DLL to the BIN directory of the Function App using FTP
2. Run the function … all should execute correctly.
3. Change the return parameter type of the method “Execute” within the local class library and rebuild the DLL.

using System;
using System.Text;

namespace FunctionsTest.Calculation
{
    public class SomeWork
    {
        public double Execute(string inputTest)
        {
            return 1f;
        }
    }
}

1. Attempting to FTP the new DLL to Azure returns: Command: STOR FunctionsTest.Calculation.dll Response: 550 The process cannot access the file because it is being used by another process. Wait a while, then try again … wait again… do this a few few times and you should get the same error.
2. Eventually, when you get tired of waiting, rename your locally generated DLL file to something else for example “FunctionsTest.Calculation1.dll” and FTP that to the server. This should work fine, so you now have two DLLs in the BIN directory.
3. Update the reference in the Function script to point to the new DLL (note line: **#r “FunctionsTest.Calculation1.dll” ** but continue to use old namespace using FunctionsTest.Calculation).

#r "FunctionsTest.Calculation1.dll"
using System;
using FunctionsTest.Calculation;

public static void Run(string input, TraceWriter log)
{
    log.Info($"C# manually triggered function called with input: {input}");
    var somework = new SomeWork();
    var result = somework.Execute(input);
    log.Info("result:" + result );
}

1. Run the script again and you get the error, showing the function is still working against the old DLL reference, even after modifying the code:

Exception while executing function: Functions.ManualTriggerCSharp1. mscorlib: Exception has been thrown by the target of an invocation. Method not found: ‘Double FunctionsTest.Calculation.SomeWork.Execute(System.String)’.

1. Change the namespace in Visual Studio of the local DLL to “FunctionsTest.Calculation1”, rebuild and FTP to the server under the filename “FunctionsTest.Calculation1.dll”.
2. Change the Function to use the new namespace (note line: using FunctionsTest.Calculation1) and success, we’re up and running again.

#r "FunctionsTest.Calculation1.dll"
using System;
using FunctionsTest.Calculation1;
public static void Run(string input, TraceWriter log)
{
    log.Info($"C# manually triggered function called with input: {input}");
    var somework = new SomeWork();
    var result = somework.Execute(input);
    log.Info("result:" + result );
}

This is perhaps a edge case; however it does seem to indicate that Functions are holding on to references to external resources, even after a shutdown/restart or recompile. With CI we are updating these DLLs continually and it’s a drawback that we can’t simply update the files.

[paulbatum]

Just a short note for anyone running into problems discussed in this issue. In Functions V2 there is no shadowcopy behavior (because it does not exist in .NET core) and so running into locking issues is more likely. However we have implemented support for the “take app offline” feature that is provided through msdeploy. To use this feature from VS, when you’re publishing look for the “take app offline” checkbox. If you can’t see it, you can specify the setting manually by going to your .pubxml file for your publish profile and make sure you have this setting:

<EnableMsDeployAppOffline>True</EnableMsDeployAppOffline>

[davidebbo]

When using msdeploy, can you try setting MSDEPLOY_RENAME_LOCKED_FILES=1 in your Azure Appsettings? This enables a mode that should allow it to deal with loaded assemblies.