DEPENDENCY INJECTION & APP CONFIGURATIONS In AZURE FUNCTIONS⚡| Azure Series

dependency injection is a technique to achieve inversion of control also known as ioc between classes and their dependencies azure functions supports dependency injection patterns this means you can segregate responsibilities into different classes and inject them into your main function class dependency injection allows us to write loosely coupled well-maintained testable and reusable code in this video we will learn how to set up dependency injection in an azure function how the different lifetime scopes work in azure functions and also some common use cases like application configurations options pattern etc hello everyone my name is rahul and welcome back to this youtube channel in case you are new here i make videos around.net azure devops and also aws so feel free to check the rest of the channel and also the linked videos if you want to learn more without much delay let's head off straight into dependency injection in azure functions in a previous video i had talked about azure functions and how to get started so if you are completely new to azure functions i would highly recommend checking that out first it will be linked here or in the descriptions below now i will be using the exact same source code that i used in that video the source code is also available in the repository the links will be in the description again so let's open up that in visual studio and get started with dependency injecting some services i have the solution opened in visual studio so here we have two projects one is the queue storage and the other one is the weather data jester this is the azure function as you can tell by the icon in this project now the queue storage is simply an asp.net web api application that i had set up when i introduced azure queue storage i'll also link that in the descriptions below now here there is a simple web api that drops a message from the weather forecast controller using the post method to an azure storage queue this uses managed identities to establish the connection i walked through that in the video before now the azure function listens to messages inside this queue and gets triggered based on that now this is using a q trigger as you can see in the function code which is exactly on the same queue where we drop the message in the previous web api so anytime a message is dropped it simply reads that and logs it onto the console in case it contains the exception message it throws an exception this is purely for demonstration purposes now in your real life these functions might be doing much more meaningful and business valuable functions let's run this to make sure everything is working as expected before we get refactoring some of this code to use dependency injection pressing f5 i have set up both the projects as startup so it's going to run both these projects now while that's happening let's take a quick look at our azure subscription where i have a delete resource group which i'll be deleting of course after this video where i have the storage account that's getting used by these applications now in this storage account if i navigate to the queues section you can see there is a add weather data queue i have also set up connections for the azure functions and the web api using managed identity now if you are new to that i highly recommend checking out those previous videos this is done using the access control iam section in this particular ui and you can give relevant accesses here if i navigate to role assignments you can see the three contributors that i have added to the storage queue as a data contributor role there is the function and also my local user so that it works in visual studio both the azure function and the web api are running the azure function is running using the local function core tools that i had already installed now if you switch back to the api you can see the get and the post call now this post call is going to drop a message into the azure storage queue which is going to be picked up by this function that is running here i had a few messages already in the queue which got picked up here by default let's go and drop a fresh message using the web api post method so let's go here and say try it out and given a test string here so let's say new test so that we can see this inside this console here let's click execute which is going to drop the message into the azure storage queue once that's successfully dropped we should be seeing a log message in here which is going to pick up this message and write it into the log statement the message is successfully sent and it's also getting processed in here so you can see a new message which says new test and it says it's executed now that we have confirmed this application is working let's see how we can introduce dependency injection when writing azure functions so let's navigate back to visual studio and stop this and go into our functions1.cs class now this is where we have defined the function now let's refactor this so that we can introduce some dependencies now this particular condition which checks on the my queue item could be a big business decision for you in your application so let's refactor this into a different class so that it can be checked and contained inside there so i'll create a new class and call this message processor which will process the message so let's create a new class inside the azure functions and call this as message processor so let's add a new class let's make this as public and create a new method inside this to process a message so let's simply write public which returns nothing and say process this also stakes in a string message which will be the message from the queue item now we can easily move the code from our functions1.cs into this particular class so let's remove this from here and move this into the message processor class so all this is doing is check if the message let's replace this as message if it contains an exception inside that it will throw an exception let's extract this class into an interface so that we can inject it inside the functions class so let's go on to the message processor class and press alt enter in visual studio and say extract interface now this is going to create an interface with this process method i'll for now keep it in the current file so let's say ok now that's going to add a new interface imessageprocessor with the process method now i can start injecting the imessage processor into the functions class for this particular check so let's go into the functions1.cs and start adding this in now to dependency inject we know that it has to be a class that can be instantiated so first we'll have to remove the static from this class declaration so let's remove the static from the function class and also from the function method let's remove both these so that these are instance level methods and classes now to inject in the imessage processor let's use a new constructor so typing in ctor and pressing tab is going to create a new constructor inside this class now i have the functions one constructor where i can inject in the imessage processor let's call this message processor and use alt enter again to create and assign a property so let's create and assign a field which is message processor now that's going to be a read-only field and it's automatically assigned that to the message processor so let's start using this from the function again so let's call message processor dot process and pass in the my queue item now this line is going to do the exact same check but using the message processor which is now dependency injected inside this class now while we are here we can also replace the function one to match the name of the function so let's copy this process weather data and rename this as process weather data function which means i'll also have to update the constructor name now since both of these are updated let's also fix the file name again using alt enter i can say rename file to process weather data function now in the solution explorer we have the files renamed as expected with that all set up let's wire up the dependency injections inside this azure function to do that we need a new class which is the startup.cs now you can rename this as any file but generally startup.cs is where we use dependency injection in asp.net core i have a completely different video on walking you through dependency injection in dotnet i highly recommend checking that out if you are new to dependency injection in general so let's come here to the function and create a new class and call this a startup.cs let's make this public for being able to use this startup class as a startup for the functions we have to inherit from the functions startup class so let's use functions startup and make sure to include the missing using statements now again pressing alt enter it shows the available actions so we can install the microsoft.azure.functions.com new git package so pressing enter is going to find and install the latest version of that nuget package into our solution which makes this particular class available for us the nuget package is installed successfully and you can see there is a new using statements up here and also the functions startup class is resolved appropriately now let's make sure to implement this abstract class in our startup class so let's use implement abstract class this adds in a new method which is an override of the configure method which takes in the i function's host builder now this interface is injected into this class at runtime by azure functions we will start configuring dependency injection using this builder now to register this type for the function startup we also need to add in an assembly directive so let's say assembly colon and specify functions startup and specify the type of the class that's implementing in our particular assembly so let's say type off and specify the startup class so let's say weather data ingester dot startup so now here we have registered this using the assembly directive that this is the startup class that we need to use for this azure function now with that setup we can start registering inside the builder the dependencies that's used for this particular azure function removing this not implemented let's say builder dot services and it starts giving us ways to inject into the service collection very similar to asp.net applications so let's first register the ie message processor as a transient dependency we will come into scopes a while later in this video so let's add in add transient and if we resolve the missing interfaces which again needs some usings so if we include the using microsoft extensions.dependence injection we will get this method transient which is going to take in the interface and the type that is implementing this interface so let's say i message processor and specify message processor as the implementation of that now this is going to inject this into the service collection as a transient dependency with this implementation now that we have all of this working let's make sure to put a breakpoint inside the configure method and run this application again now we can also put a breakpoint inside the function class where we use this so let's make sure to put a breakpoint on line 20 as well and let's press start both the azure function and the web api is running successfully now with the azure functions it has hit our breakpoint inside the startup class so now this is going to set up the transient dependencies for this particular azure function now once this is run it's going to set up these dependencies as expected so let's continue the execution which will continue the azure function as well now let's go back to our web api and drop a message inside the queue so let's use the post method and click try it out and say execute this is going to drop a message with the summary string to the message queue the message is successfully dropped and the azure function has picked it up which is why this particular debug point has been hit now this injects in the message processor inside this class and we have this set up inside our class as a read-only variable which is getting used inside here so if we step in we can see this calls in to the process message since this doesn't contain an exception this continues execution as expected and it locks the message inside this console now if you drop any number of messages that's going to get picked up again by this function let's change the summary to be new message and click execute again now this is going to run the azure function again and it is going to log this message inside the console note that the startup.cs class ran only once at the startup of this function now this is very similar if you're running an asp.net application as well now whenever the host is getting instantiated which is this cli in this case then the startup.cs is invoked once for each message that's coming into the azure functions only the azure function is getting invoked we will see more about this when we learn about lifetimes a while later in this video so let's stop execution we have successfully set up dependency injection in azure functions by injecting the i message processor now if you look at this azure functions we can see that there is a log being used here this is getting injected by the azure function's runtime as the i logger we can also inject this using dependency injection so let's see how that would work let's remove the i logger from the function definition and use it from the constructor injection so let's use i logger now if you are familiar with logging in.net go we use the one with the generic type that also takes in the category name now this is what is by default injected by the dependency injection in dotnet core if you're new to logging i highly recommend checking out my video on that where i detailedly show different configurations and options that you can set on logging for now let's use i logger specify the class name in this case that is the process weather data function and use the name as log let's make sure to add a read-only property so again using alt enter i can use create and assign a field log now this again creates a read-only property and this uses it inside this function since we are injecting the i logger we need to go into the startup.cs and configure logger for the services collection so inside here let's say builder.services and call the method add logging this is going to configure the default log providers into this application so let's run this to see if this is working as expected let's remove these breakpoints so that it continues execution without stopping here and go back to our web api and drop a new message so let's click try it out change this message to be log and click execute the message is successfully picked up by the azure function and we have the log injected in here so if you look at the logger we can see there is a logger instance coming in here you can also see the different loggers that's configured inside this particular log instance now these are the different configuration sources like the file logger the null logger the azure monitor diagnostic logger etc now there is a default set of loggers that's getting injected by the add logging method let's continue the execution and see if this is getting logged but if you see here inside the console we cannot see the message c sharp q trigger function processed which was using the log that was injected in now this is because of an existing visual because of which it is filtering out all the external categories that we are logging to fix this we can stop this application go to the host.json file and update it for the logging configuration now inside the logging we can specify a log level and specifically call out the log level for our custom namespace so if we go to our startup.cs class we can see our namespace is weatherdata ingester so let's copy that come back to the host.json and set that as the log level information now if you're logging this to a file we can also specify file logging mode as always now with the log level specified in the host.json let's save this and run the application again and make sure it's working as expected now both the apps are running so let's go to post try it out and send a message again so let's specify new log as the message and click execute the message is successfully picked up by the azure function and let's continue execution which should be logging this inside again now with the log level configurations we can see that the message c-sharp q trigger also appears inside this console now if you deploy this into azure functions you should be even seeing this inside the diagnostic console or the log stream of the azure functions the startup class that we have used is meant only for setup and registration we shouldn't try and use the services that's registered within the startup class like the logger for example also the dependency injection container only has the explicitly registered types so if you're trying to resolve things like the binding context execution context etc those aren't available as part of the dependency injection now that we have successfully injected in a transient dependency let's understand a bit more about the different servers lifetimes now as with the asp.net core dependency injection this also supports the same three level of lifetime scopes which are transient scoped and singleton with the transient a new class is created whenever a class is requested for with the scope it's only created once in the scope of that execution in our case it means a function getting run and the singleton is just injected once which is at the start of the host let's try and understand these service lifetimes a bit better with an example so let's come back to our azure functions and create a new class in here so let's create a new class and call this service lifetimes now inside this class let's simulate a few of these transient singleton and scoped services for that let's make this first public make this as an interface and call this as an i transient service let's add a method write which takes in a message of type string to implement this let's create a class public class call that as transient service and implement the i transient service so let's make sure to implement this interface and which has the right method again now to understand how this works inside the constructor let's also have a simple guide property so let's call this as random and specify good dot new guide and convert that as to string so we can simply log this to understand how the scopes are working let's make sure to specify a read-only field for this particular property so that's getting added inside this class as well now if you want to log this message we can also inject in a logger so we can use a i logger and specify transient servers just like we did inside the previous example so let's make sure to include the appropriate usings so this is the microsoft extensions.logging and specify this as a logger let's again add a read-only field and use this logger inside the right message so i'm going to call logger dot log information since this is the transient service let's specify the message as transient let's also specify the message that's coming in so let's use structured logging and also the random id that we have generated now to set these i have to set them as parameters so let's make sure to pass in the message and the random in the correct order now all this is doing is simply takes a message and it logs it as a transient and the message and with the guide inside here we will be using this to understand the lifetime scopes now we need similar interfaces for scoped and singleton so let's simply copy and paste this so let's name this as scoped and singleton services appropriately so let's remove transient specify this as scoped and remind this and name this as singleton since we need different implementations let's simply copy this class and paste this again two times and create the appropriate implementations now in this case this is going to implement a i singleton service instead of transcn servers let's name this as singleton again let's make sure that the constructor is also fixed and instead of this let's name this as a scope service and use the interface i scoped service so let's make sure the constructor is fixed again and give the appropriate names inside the log messages so that's singleton and this is scoped now i have three classes which each of them represents a singleton the transient and the scoped services now in your real application these might be different implementations like a connection to an http client or a database connection or some business function validations that you need to do etc now depending on how you want you will have to use different scopes and lifetimes for that which you will understand how it works in a moment now with all of these defined let's make sure to use them inside our message processor so let's come back to our message processor and inject each of these inside the message processor so let's again define a constructor for this and take in the i transient service which is going to be a transient service let's also add in the singleton service call that as singleton service add a field again and similarly let's also add in a i scope service which is going to be named as scope service and make sure to again add a field for this we will be using all of these from the process method so let's make sure to align this appropriately and each of these parameters in new line now once we have successfully checked for the exception we can simply use the transient service and call write and specify the type name in this case so let's say we are calling this from the message processor similarly we can do that for our scope and the singleton servers let's make this as scope and let's make the last one as singleton now we have successfully created three different types of services injected it into our message processor and logging out these messages from the processor now the last thing is to register these services inside the startup.cs class so let's come back here and say builder dot services and register each of these types so the transient is going to be registered as a transient type so let's specify add transient specify the i transient service and also specify the transient service implementation now for the scope we'll be using the builder.services dot add scoped method which again has a similar interface and specify the i scoped interface method in this particular case now we have the scope servers so let's use that for the implementation now for the last one it's going to be builder.services and going to be the add singleton method which is again going to take a similar kind of interface structure so let's say i singleton and specify the singleton service as its implementation now if you're not familiar with these extension methods i highly recommend checking out my dependency injection video where i show different ways of registering these scoped lifetime methods and instances now with all of these registered we should be able to use this from our application so let's run this and make sure it's working as expected we have the web api and the function running so let's click post try it out and specify lifetimes inside here because we're testing lifetimes and click execute the message is successfully picked up so let's step into the message processor and we can see the transient service the scope service and singleton servers are all assigned a value so let's continue the execution and see how the log looks like now we have three values getting logged here which are the transient scoped singleton it specifies these are from message processor and has three different goods inside here to understand how the lifetimes is working let's send one more message so let's name this as lifetime's new and click execute this again gets picked up so let's resume the execution with the transient message you can see that go it is unique every time a new message is coming up so if you see this starts with 57 and the next one has a different id which starts with c0 now for the scope also this is same it is different between different messages that's getting picked up now for the first message it started with 299 and the second time it started with 265. with the singleton instance we can see this starts with 5f6 and the next message also has the same instance which means it is using the same singleton instance of that particular class in all the functions that is getting executed so once the host starts up it creates a single instance of that class and injects into the dependency injection any message that is getting processed by that particular host will get this same good this is typically useful when you're using connections and objects like that in your real applications where we want to reuse that connection and keep it open inside that particular function host now you will have to make sure that you are handling timeouts etc but this is generally what's preferable to understand more about scoped we will have to create one more dependency so that we can see what's the difference between scope and transient we know that both of them will be different for different message executions but within the same message execution there is a difference between transient and scoped to understand that let's come back to our application and create a new dependency very similar to the message processor so let's open the solution explorer and create a new class and for this let's name this as another dependency just to indicate this is some other dependency that you have in your application now i can similarly create a write method so let's first make this as a public let's add in a method which is going to be very similar so let's say public process and call this as string now this is going to again process a similar message and write this into the console let's also specify a name which is message now another dependency let's go and create an interface so let's say extract interface add to the current file which is going to add an i another dependency inside this file now i can inject this in into the function as well now to use the same lifetimes let's go back to the message processor and copy these message processor implementations so let's copy all of that come back and paste this inside our another dependency let's make sure to rename the constructor in this case this will be another dependency let's also add in the read-only properties that we need so let's copy that again from the message processor and paste that inside our another dependency class now this is going to have the similar services injected in here now inside the process let's simply call the write statements like we did inside here so let's copy these three and paste this inside our process method which is calling on to the transient scoped and singleton now since this is coming from another dependency let's rename this as another dependency and make sure to apply this in each of these functions so let's rename that paste it and also the last one since we've added a new dependency let's make sure to use this from our functions so let's go back to our process weather function instead of just injecting the my message processor let's also inject in i another dependency let's add a read-only field for this and start using this inside our run method so let's call another dependency dot process and pass the myq item now in your real application this might be completely different and doing something else i'm using this simply to demonstrate the lifetime scopes and how it works now both of the my message processor and the another dependency takes in all the dependencies of those lifetime scopes before we run the application let's go to startup.cs and register in the i another dependency as well so let's specify builder dot services and specify add transient and specify i another dependency now this is going to have the implementation as another dependency let's run this and see this in action so for every message execution we expect two sets of log messages for the transient scope and service lifetimes one from the message processor and the other one from the i another dependency class that we just added both the apps are running so let's go to the post click try it out and say life times again and click execute the message is successfully processed let's look at the goods again so this time we have two sets of logs so we have the transient scope and singleton coming from the message processor and also the trans-cn scope and singleton coming from the another dependency now if you look at the transient guide this starts with b451 which is different from the transient guide from the another dependency this is as expected because with transient registrations anytime you request for a class in this case the transient service it creates a new instance of that because of which it creates a new good and that is what is getting logged now with the scope servers if you look at the good this time it starts with 0 9 1 and also the one from another dependency starts with 0 9 1. both of them are exactly the same instance with scoped within the execution scope of that particular function message the same instance would be reused so when the message processor asks for the transient servers it creates an instance and reuses that same instance when another dependency also asks for it which is why the grids are same in this case this is same for singleton with singleton a single instance is created even if any number of messages are handled by the same host which is this console application that you're seeing here now if i go and execute one more message let's call this as lifetime's new and click execute this is again going to be picked up here you can see these ids are slightly different again the transient which is b for one is different in each of these cases so let's see for fc in the transient here it starts with c e and this one is d a so every time a new instance is created with the scope it's same for the first message execution but it's different from the next but you can see it's the same for the next message in both the message processor and also the another dependency both of them starts with 508 but this is definitely a different instance than the one that was used to process the first message whereas with the singleton you can see it remains the same for all the messages so you can see this is 6 cb and also the first one used 6 cb in all the classes that is message processor and another dependency i hope this gives you a good understanding about service lifetimes and how you can choose what you want for different implementations of your business functionalities when we develop azure functions we also need to use configurations now these configurations could be connection strings urls to other websites or apis and also secret keys let's see how we can use this inside the app settings.json file that we are normally used to when building asp.net core applications so to do that let's go into our azure function and add a new app settings.json file so let's select add and search for the json file template and let's call this as appsettings.json so appsettings.json file now this is going to create a json file inside our azure function so let's say i have a config like this which is myconfig which has a url and a secret key now one thing to make sure is that by default these appsettings.json file is not copied over into your bin folder so it doesn't get packaged so you'll have to right click and say properties and mark this to be copied always so we can say copy to output directory and say copy always this makes sure that this file gets copied into the bin directory and is available when we package and deploy as well now to start using appsettings.json file we need to configure the configuration sources inside this azure function so let's see how we can do that so going back to the startup.cs class we need to override the configure app configuration method so if we type in overwrite you will see a new method as well which is the configure app configuration now using this we can override the configuration sources that's used by this function by default it doesn't use the app settings which is why we will be configuring this explicitly here this injects in i functions configuration builder which is done by the azure functions runtime now to configure the appsettings.json i have some code already written so let me copy and paste this here and i'll walk you through it now in this particular case this is adding a json file so let's make sure to include the appropriate usings and it also use the path from the system.io let's make sure to include that as well now all this is doing is from the builder it's getting the context to determine the root path for these files and it expects these files inside there it uses the configuration builder which is the same configuration that builder that we use in asp.net core and specify the add json file now if you're not sure about configuration and the sources i highly recommend checking out my video on configuration in asp.net core where i walk you through all these different options now all this is doing is adding a json file with the app settings.json specifying it as optional and it says reload on change as false which means if you change the file it doesn't reload the azure function now similarly if you have environment specific configuration values like appsettings.development.json or prod.json or test.json you can specify those files as well here this also configures for the environment variables if any from the particular environment that this azure function is running now with these specified we can start using the appsettings.json file within our application now if you're familiar with the options pattern which ties in with the configuration use cases you can also use that with your azure function now if you're not that familiar with options pattern i highly recommend checking out the video link here or in the description below the options pattern is just a way to start using the configurations from these files inside your application now in this particular case since we have the my config let's go and create an options class that is going to be my config options you can name this anything you want but for convention purposes i am going to name this as my config options let's make sure this is public and we need two properties inside here to capture these values of url and secret so let's come here and create a string value so let's type in prop and tab and say string and specify the property name which has to exactly match with that in your configuration let's also add in for the secret so let's specify string and a secret as the name now both of them has to have a public get and set so that this thing will work now again check out that video if you want to learn more about options pattern in dot net core to start using this i can go to one of our services let's say inside our message processor and use this from here now i can inject in an i options class and specify the my config options so let's specify this as config options make sure to include the missing usings which is the microsoft.extensions.options in this case now you can add this as a backing property so let's say assign a field and start using this from your applications since this is just for demo i'll put a breakpoint to see how the value comes here now to register the options let's go back to startup.cs and do that from our configure method i have already written the registration code so let's copy and paste that here and i'll walk you through it so this is calling the builder.services the add options specifying the options class and specifying how to get this particular options class so this is using the configure method which takes in a i configuration which is the settings and the configuration now using the configuration object this settings class is nothing but the my config options instance which is getting bound from the configuration section now if you see in the app settings.json file we have the my config as the section here which is exactly what is referred to inside this get section now with the configuration we have different sources defined using the configure app configuration this is going to use the json file and also the environment variable so this method is going to look for all the configuration sources get the section for my config and bind it with this settings property which is nothing but a default myconfig options class so all these properties will get populated from appsettings.json in this particular case let's run this i have a breakpoint inside the processor so see how this works in this case both the apps are running so let's go to post try it out and specify the summary as configuration and click execute the message is successfully processed now you can see we have the config options automatically injected in here so let's do a quick watch on this using shift f9 which shows the values of that my config options you can see that it has the secret as my secret key and the url that's coming from appsettings.json file now this is automatically read from the configuration settings bounded to a strong type in our case the my config options and we can use this from our application code now anywhere you want these config options all you need to do is inject the i options and you will get these options values as well now in this particular case if we go to the appsettings.json we can see we have the secret value specified inside the app settings.json this is not recommended now in an earlier blog post and a video i had shown you five different ways that you can handle application configuration and secrets when you're working with azure now this has different examples by using the devops pipeline or using keyword and also using azure app configuration i highly recommend checking this post and the associated videos if you want to learn more about managing sensitive information like secret keys etc but one of the options that i show you for local development is to use the secrets manager now azure functions also supports the secrets manager now if you're new to secrets manager i highly recommend checking my video on that but i'll show you quickly how to use it from an azure function so if we come back to our functions go into our solution explorer and right click on the azure functions project and specify manage user secrets if you click that it is going to automatically create a new file which is in a specific location in your local computer now click yes to install the required packages for this it also creates a secrets.json file which is in a specific location inside your computer if you can see this is under the app data roaming and a folder that's dynamically created which i walk you through in my secrets manager video now one thing you need to note is using the secret manager is not a sensitive way to use it in your production environment this is simply a way on your local computer to keep the secrets outside of your app settings file so that you don't have to check it into a source control now if we go back to our appsettings.json let's copy all this and paste it inside our secrets.json file as well now since we are okay with the url to be in the app settings let's remove that and specify the secret as secret from secret store we can also go to appsettings.json and remove this from here i usually have this as empty so that anyone looking at the application.config can clearly know what all configurations is supported by these apps where this is set is up to me to decide finally it could come from key vault or it could come from azure app configuration or when i'm using local development it will come from the secrets.json so let's make sure to save all these files and run this application again so this time when the application runs it should pick the secret from the secrets.json which is living in your computer now if some other developer is pulling the same source code they can set up the secrets in their local machine as well this way you don't have to share the secrets using your source control both the applications are running so let's go into the post try it out and specify the message as secrets in this case and click execute the message is successfully picked up so let's select the config options and do quick watch using shift f9 and we can see the value as secret from store now in this case only the secret is getting replaced from the store and the url is coming from app itself now similarly you can have app settings.development.json etc overriding these values as well if you want different values in different environments i highly recommend checking out that blog post where i walk you through five different ways where you can configure sensitive information and configuration in general for applications running on azure infrastructure i hope this helps you to understand more about dependency injection in azure functions and how to set it up from scratch we saw the different lifetimes transient scoped and singleton and how it differs with the running instances of azure functions when these functions are hosted in the azure functions in the cloud it behaves exactly the same which is why i haven't demoted this in this particular video but when i do a video on hosting and scaling i will show some of this again we also learned how to use application settings.json file and use the app configurations that we are used with when we are building asp.net web api applications we also saw how to use options pattern and to use the secrets manager if you like this video please make sure to hit the like button and if you want to be notified in the future of similar such videos make sure to hit that subscribe button it also helps me to grow this youtube channel thank you and see you soon

Channel: Rahul Nath

Views: 17,070

Keywords: azure functions, azure functions tutorial, azure function app, dependency injection c#, dependency injection in azure functions, appsettings.json in azure functions, azure functions configuration settings, configuration in azure functions, logging in azure functions, azure functions startup class, getting started with azure functions, DI in azure functions

Id: m_jrALXcrXc

Length: 45min 12sec (2712 seconds)

Published: Mon Jan 03 2022