Open ielcoro opened 3 years ago
Also, for me, the upper level "runtime" directory is 0 bytes after building it in Azure Devops using DotNetCoreCLI@2 build command . It's filled with empty folders for each architecture. The sub 'runtime' directory has the appropriate files in it. This is the error I get when I try to run it live on Azure Function:
Could not find file 'C:\home\site\wwwroot\runtimes\win-arm64\native'.
For some reason, building in VS2019 results in a different build output then dotnet build.
Anybody have an answer to this in 2022? Possible solution to prevent the bin-in-bin scenario? Very irritating to deal with when you have a web app project as well as a function app project in the same solution trying to get files from a project only to have the function app create a bin folder inside the bin folder for all the dll's but not place the files which you've explicitly marked as Copy if Newer
or Copy Always
in the bin-in-bin folder.
dealing with this same issue right now. Something I found -
When using DevOps Pipelines, it is outputting the above structure; a bin with duplicates inside of the main folder, as pictured below:
When deploying straight from Visual Studio to the Azure Function, it is being built with a parent folder containing a bin and the bin has no duplicate bin inside, as shown below:
On top of all of this, I am getting a System.ArgumentNullException when trying to access the hosted aforementioned double bin, while deploying from Visual Studio is yielding a function that runs as intended. Does anyone have any idea what's happening here?
This issue affects many scenarios with configuration files. Only when using Azure Functions, config files tagged with CopyToPublishDirectory
are copied to bin/output
but the assembly execution path is bin/output/bin
.
In other words:
assembly execution path
== config files path
assembly execution path
!= config files path
I hope this can be resolved as soon as possible. I'm sure it would make things much easier for developers and library creators, who currently have to create and maintain workarounds just for Azure Functions.
== .NET version: 6.0.400 Core Tools Version: 4.0.4895 Function Runtime Version: 4.13.0.19486
Az Function csproj snippet:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>V4</AzureFunctionsVersion>
</PropertyGroup>
.NET app csproj snippet:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
</PropertyGroup>
We are in the process of migrating from functions v2 to v3, and we got caught by surprise when analyzing the output of our functins projects. It looks like some post build target in the functions v3 sdk runs copies all the binaries from the standard output folder to a bin subfolder, duplicating output.
We don't understand why this is done, and cannot find any documentation on which folder is the right one to run our automated build/deploy tasks on.