Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Azure Function App - private assembly gets cached - updating file has no effect #953
Uploading private assembly to Azure Function /bin works, but subsequent updates don't take effect until the I kill the service process in Kudo. Restarting the app service in the Azure portal has no effect - service process must be killed. The symptom is that related changes in the Azure function will build after the assembly has been updated, such as accessing a new property in the assembly from the function, however the function will fail during runtime.
same behavior for .config files, except that changes to .config files never take effect, even after killing the service processes.
I would expect any update to any file in the bin folder to be reflected in the behavior of the function.
See repro steps
Kill app service processes from Kudo.
Much more info and some sample code here:
Hey @marklauter, thank you for following up with the requested details here.
As mentioned on SO, I'll try to repro this as versioning the assembly should behave as expected and use the new version.
One question and one point of clarification:
referenced this issue
Dec 9, 2016
added a commit
Dec 13, 2016
Has this rolled out yet? I feel like I'm seeing the same problem.
As a workaround, how do you kill the app in Kudu? I go to process explorer, and then command line and try taskkill pid or kill pid but I always get permission denied.
How can I force a reload of the app?
@xmark I have been manually creating and then deleting an app setting to get it to refresh - I noticed in a recent Azure Function blog post they mentioning something about fixing a file locking issue which could very well be what is happening here.. https://blogs.msdn.microsoft.com/appserviceteam/2017/03/16/publishing-a-net-class-library-as-a-function-app/
Ok, so that didnt work for me. But I did find the issue. I have 3 different functions that all reference the same DLL (a common set of domain objects and functions). I updated ONE of the DLLs in the bin directory for one of the functions only. (i.e. the other 2 functions still had the old version of the DLL, but I didnt think that it would make a different since I wasnt running them). I got the runtime error, but then just for a test I updated all the DLLs to the same version and it worked.