Azure Functions & DLL hell reborn

Part of the project I am engaged with involves developing Azure Functions.  The dev team have created a single function and have it working perfectly triggering every 10 minutes during the day.  It is for the processing of surveys that are being managed by our system but have connectors into various survey platforms.

I was asked to create a new process that would interrogate the Verint API and look for new surveys that have certain properties so that they could be automatically added to our system for automated extraction and analysis.

As this was a specific requirement that came from a single customer, I decided that it was best not to alter our generic code that was already developed and working, but rather stand up a new process that will handle the specific need.  I chose to also implement an Azure Function (timer job).

As the API for adding surveys to our system was not yet delivered (coming in the next phase), I needed to implement the code that would insert the data into the database myself.  Rather than re-invent the wheel, I copied the relevant projects from the source code and included them in my separate solution.  I deployed the function into the same function app as the other one and all worked well.

However during a demo it transpired that the original function was not executing and throwing errors about missing types.  So we redeployed the original function and it started working.  Then my new function stopped working…

After a bit of inspection and thought we realised that the problem was with the project that I had copied as it produced a dll with the same name but obviously not the same signature.  It was at that point that we realised that the functions are loaded into the same place within the function app and are not isolated at all.

Conclusion

Best practice would dictate that all functions for a function app should be contained in the same solution – this makes sense as then there will never be any conflicts like this.  However, care should be taken between functions that they do not step on each other’s toes so to speak as they share a common file space and could influence each other.

If functions must be in separate solutions, then minimise the amount of dependant dlls you have, ensure your NuGet dependencies are at a compatible level and test, test, test!