Azure Functions : .NET Standard or .NET Portable issues

Azure functions are the new kid on the block as Cloud technologies are pushing towards Serverless architectures. Azure functions is a powerful way to execute simple code blocks which need to be run on demand instead of requiring a dedicated hardware. It supports multiple programming languages e.g. C#, JavaScript, F# etc.

If you writing an Azure function using C#, there can be a case that you need to refer a dependency code block which is already part of a .NET dll. Well, if that is compiled is against different .NET flavors (remember Portable Class Library, .NET Standard, .NET Framework, .NET Framework client profile) then you might be wondering if that will work or not. Good news is that it works alright.

Here is a simple test. Create a simple timer based Azure Function from portal. I used C# as language.

As you see in the above function definition, I have referred to multiple DLLs, all compiled against different .NET Target Framework. Those DLLs are uploaded under "bin" folder.

All of the libraries have single class "Class1" and single method "SayHello" which prints different outputs for each library.

When you run the function, you can see that it is able to make use of all DLLs and print correct output.

So fear not and make use of available capabilities of Azure Functions.

Debug in release mode

Imagine there is a scenario where you need to check the values of different variables at runtime - your usual response will be to run the application in debug mode and put a breakpoint at appropriate place. However, there are situations where code needs to be run in "release" mode because your code has compilation directives e.g. #if DEBUG. In such cases it becomes difficult to run the application and expect to know the values without some sort of trace/log statements.

There is a way to achieve this through Visual Studio as well. 

You can uncheck the option to "Optimize Code" and run the code in release mode. You will be able to hit the breakpoint and check values.

Caution: Do not make these changes for non-localbox environments as there is performance penalty and you lose the goodness of compiler optimization that help boost performance of application in release mode.