Let’s take a look at some practical differences for both options.<\/p>\n
Both are examples of a simple C# HttpTrigger.<\/p>\n
Method signatures<\/h4>\nC# function<\/h5>\n\r\n[FunctionName("Function1")]\r\npublic static async Task<HttpResponseMessage> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)]HttpRequestMessage req, TraceWriter log)\r\n<\/pre>\nC# script function<\/h5>\n\r\n public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)\r\n <\/pre>\nIt can be seen that the C# function uses attributes where the C# script function uses the settings which can be adjusted in the portal or can be maintained in a separate function.json file.<\/p>\n
Project output structure<\/h4>\n
A C# function developed and compiled in Visual Studio and deployed to Azure has a slightly different output structure than a C# script function created in the Azure portal.<\/p>\n
![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/1-C-function-output.png\")
<\/a>
\nFigure 1 – C# function output created in VS and deployed to Azure<\/p>\nThis is a copy of the directory below ‘\\release(or debug)\\net461’ on the local file system. As you can see there is a bin folder which contains the output assembly of the project as well as all the referenced assemblies. The function.json contains the bindings generated by the Azure Function tools from the C# code attributes defined.<\/p>\n
![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/2-C-script-output.png\")
<\/a>
\nFigure 2 – C# script output created in Azure Portal<\/p>\nBindings are defined in function.json, where the actual C# script code is listed in run.csx, un-compiled and readable in the browser.<\/p>\n
How to reference a file in the project within the function<\/h4>\n
How hard can it be, I hear you thinking\u2026 Yeah, my thoughts also..<\/p>\n
What is the current working directory in the function code?<\/h5>\n
There are several options for getting a path in .NET
\nAssembly.GetExecutingAssembly().CodeBase – Gets the location of the assembly as specified originally; the place where the file is found.
\nAssembly.GetExecutingAssembly().Location – Gets the full path or UNC location of the loaded file that contains the manifest.
\nEnvironment.CurrentDirectory – Gets the current directory path of the project.
\nAppDomain.CurrentDomain.BaseDirectory – Gets the path of the entrypoint of the application or where the current AppDomain is created.<\/p>\n
The output for the C# function, locally and published to Azure, as well as the output for the C# script function are displayed in the following figures.<\/p>\n
![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/3-output-locally.png\")
<\/a>
\nFigure 3 – C# function code output when running locally<\/p>\n![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/4-output-Azure.png\")
<\/a>
\nFigure 4 – C# function output when published to Azure<\/p>\n![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/5-ouput-script-function.png\")
<\/a>
\nFigure 5 – C# script function output running in Azure portal<\/p>\nIn all three situations the different possibilities result in a different location returned and none of them are usable in all three situations.
\nFor example the Codebase can be used when using a C# function, but when developing a C# script function this path is totally unusable.<\/p>\n
To get information about the function or directory one has to dive into the Azure WebJobs SDK. After all Azure functions are based on WebJobs.<\/p>\n
It seems that the method signature can take an additional parameter of type ExecutionContext<\/strong>.
\nJust add it and it’s ok, like this in a C# function:<\/p>\n\r\npublic static async Task<HttpResponseMessage> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)]HttpRequestMessage req, TraceWriter log, ExecutionContext executionContext)\r\n<\/pre>\nOr a C# script function:<\/p>\n
\r\npublic static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log, ExecutionContext executionContext)\r\n<\/pre>\nCalling the property FunctionDirectory<\/em> of this context in Visual Studio results in the actual local function directory:
\n![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/6-paths-locally.png\")
<\/a>
\nFigure 6 – FunctionDirectory result running locally<\/p>\nSo get the parent of this path to get the project directory.<\/p>\n
When deployed to Azure it results in D:\\home\\site\\wwwroot\\Function1![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/7-paths-deployed-to-Azure.png\")
\n<\/a>Figure 7 – FunctionDirectory result deployed to Azure<\/p>\nAnd using an C# script function this results in ‘D:\\home\\site\\wwwroot\\HttpTriggerCSharp1’ which is the function directory over there.<\/p>\n
![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/8-paths-script-function.png\")
<\/a>
\nFigure 8 – FunctionDirectory result running C# script function<\/p>\nWhen adding files and folders to the project in Visual Studio and deploy it to Azure, they are present in the structure:<\/p>\n
![\"\"](\"https:\/\/www.itidea.nl\/wp-content\/uploads\/2017\/11\/9-files.png\")
<\/a>
\nFigure 9 – File structure<\/p>\nNow the working directory is a known fact, referencing these files in the project is easy.
\nlog.Info(executionContext.FunctionDirectory);
\nlog.Info($”{Directory.GetParent(executionContext.FunctionDirectory).FullName}\\\\files\\\\afile.json”);<\/p>\n
Summary<\/h4>\n
To get the project or function directory in an Azure function in Visual Studio or in the portal isn’t rocket science, but it took me some digging around in the SDK to get it.<\/p>\n","protected":false},"excerpt":{"rendered":"
To explain in detail how to reference a file in an Azure function some background information on the basics of Azure functions is necessary. To complete the story it will all be explained for C# script based function as well … Read More »<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,39],"tags":[50,37],"class_list":["post-2458","post","type-post","status-publish","format-standard","hentry","category-azure","category-office-365","tag-azure","tag-office365"],"_links":{"self":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/2458","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/comments?post=2458"}],"version-history":[{"count":15,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/2458\/revisions"}],"predecessor-version":[{"id":2482,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/2458\/revisions\/2482"}],"wp:attachment":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/media?parent=2458"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/categories?post=2458"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/tags?post=2458"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\r\n[FunctionName("Function1")]\r\npublic static async Task<HttpResponseMessage> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)]HttpRequestMessage req, TraceWriter log)\r\n<\/pre>\nC# script function<\/h5>\n\r\n public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)\r\n <\/pre>\nIt can be seen that the C# function uses attributes where the C# script function uses the settings which can be adjusted in the portal or can be maintained in a separate function.json file.<\/p>\n
Project output structure<\/h4>\n
A C# function developed and compiled in Visual Studio and deployed to Azure has a slightly different output structure than a C# script function created in the Azure portal.<\/p>\n
<\/a>
\nFigure 1 – C# function output created in VS and deployed to Azure<\/p>\nThis is a copy of the directory below ‘\\release(or debug)\\net461’ on the local file system. As you can see there is a bin folder which contains the output assembly of the project as well as all the referenced assemblies. The function.json contains the bindings generated by the Azure Function tools from the C# code attributes defined.<\/p>\n
<\/a>
\nFigure 2 – C# script output created in Azure Portal<\/p>\nBindings are defined in function.json, where the actual C# script code is listed in run.csx, un-compiled and readable in the browser.<\/p>\n
How to reference a file in the project within the function<\/h4>\n
How hard can it be, I hear you thinking\u2026 Yeah, my thoughts also..<\/p>\n
What is the current working directory in the function code?<\/h5>\n
There are several options for getting a path in .NET
\nAssembly.GetExecutingAssembly().CodeBase – Gets the location of the assembly as specified originally; the place where the file is found.
\nAssembly.GetExecutingAssembly().Location – Gets the full path or UNC location of the loaded file that contains the manifest.
\nEnvironment.CurrentDirectory – Gets the current directory path of the project.
\nAppDomain.CurrentDomain.BaseDirectory – Gets the path of the entrypoint of the application or where the current AppDomain is created.<\/p>\n
The output for the C# function, locally and published to Azure, as well as the output for the C# script function are displayed in the following figures.<\/p>\n
<\/a>
\nFigure 3 – C# function code output when running locally<\/p>\n<\/a>
\nFigure 4 – C# function output when published to Azure<\/p>\n<\/a>
\nFigure 5 – C# script function output running in Azure portal<\/p>\nIn all three situations the different possibilities result in a different location returned and none of them are usable in all three situations.
\nFor example the Codebase can be used when using a C# function, but when developing a C# script function this path is totally unusable.<\/p>\n
To get information about the function or directory one has to dive into the Azure WebJobs SDK. After all Azure functions are based on WebJobs.<\/p>\n
It seems that the method signature can take an additional parameter of type ExecutionContext<\/strong>.
\nJust add it and it’s ok, like this in a C# function:<\/p>\n\r\npublic static async Task<HttpResponseMessage> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)]HttpRequestMessage req, TraceWriter log, ExecutionContext executionContext)\r\n<\/pre>\nOr a C# script function:<\/p>\n
\r\npublic static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log, ExecutionContext executionContext)\r\n<\/pre>\nCalling the property FunctionDirectory<\/em> of this context in Visual Studio results in the actual local function directory:
\n<\/a>
\nFigure 6 – FunctionDirectory result running locally<\/p>\nSo get the parent of this path to get the project directory.<\/p>\n
When deployed to Azure it results in D:\\home\\site\\wwwroot\\Function1
\n<\/a>Figure 7 – FunctionDirectory result deployed to Azure<\/p>\nAnd using an C# script function this results in ‘D:\\home\\site\\wwwroot\\HttpTriggerCSharp1’ which is the function directory over there.<\/p>\n
<\/a>
\nFigure 8 – FunctionDirectory result running C# script function<\/p>\nWhen adding files and folders to the project in Visual Studio and deploy it to Azure, they are present in the structure:<\/p>\n
<\/a>
\nFigure 9 – File structure<\/p>\nNow the working directory is a known fact, referencing these files in the project is easy.
\nlog.Info(executionContext.FunctionDirectory);
\nlog.Info($”{Directory.GetParent(executionContext.FunctionDirectory).FullName}\\\\files\\\\afile.json”);<\/p>\n
Summary<\/h4>\n
To get the project or function directory in an Azure function in Visual Studio or in the portal isn’t rocket science, but it took me some digging around in the SDK to get it.<\/p>\n","protected":false},"excerpt":{"rendered":"
To explain in detail how to reference a file in an Azure function some background information on the basics of Azure functions is necessary. To complete the story it will all be explained for C# script based function as well … Read More »<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,39],"tags":[50,37],"class_list":["post-2458","post","type-post","status-publish","format-standard","hentry","category-azure","category-office-365","tag-azure","tag-office365"],"_links":{"self":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/2458","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/comments?post=2458"}],"version-history":[{"count":15,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/2458\/revisions"}],"predecessor-version":[{"id":2482,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/posts\/2458\/revisions\/2482"}],"wp:attachment":[{"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/media?parent=2458"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/categories?post=2458"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itidea.nl\/index.php\/wp-json\/wp\/v2\/tags?post=2458"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}