Could not load file or assembly 'Microsoft.Extensions.DependencyModel, Version=3.0.0.0 in Azure Functions App v3 - azure

I have a v3 queue-triggered function that has been working fine on my Windows 10 machine. This is how the .csproj file looks like:
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>
I am not sure why I started getting the exception mentioned in the subject line, but the bottom line is that this function used to work well. This Stackoverflow post was not helpful to address the issue. Could it be due to upgrading the operating system to Windows 11? I did not run this function app immediately after migrating to Windows 11, so I cannot speak on that.
The full exception's stack trace is per below:
Could not load file or assembly 'Microsoft.Extensions.DependencyModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
at
Microsoft.Azure.Functions.Extensions.DependencyInjection.FunctionsStartup.Configure(WebJobsBuilderContext
context, IWebJobsBuilder builder) at
Microsoft.Azure.WebJobs.WebJobsBuilderExtensions.ConfigureStartup(IWebJobsStartup
startup, WebJobsBuilderContext context, IWebJobsBuilder builder) in
C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Hosting\WebJobsBuilderExtensions.cs:line
162
Any idea on what the possible solution would be as it has become a roadblock?

To preserve specific version in order to avoid upgrading to a newer version which you could add this entry to csproj
<ItemGroup>
<FunctionsPreservedDependencies Include="Microsoft.Extensions.DependencyModel.dll" />
</ItemGroup>

You can try adding <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput> to the Function's project file.
like this:
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
</PropertyGroup>

Related

Why am I getting duplicate errors in my obj/Release/net6.0 folder after building and deploying Azure function in VS Code

My Azure function works, I can debug it, and deploy it no problem. But when I deploy it and it gets built into the release folder I see errors in the obj -> Release/net6.0 folder.
FYI - I deploy by using the Azure extension and in the Azure workspace panel I click on deploy, then choose my resource group and it runs on it's own and deploys no problem.
I'm wondering if it has something to do with the name I gave my project
"Functions" ?
I'll post what I see below.
Here is my .csproj file for the Azure function project
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.0.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.1" />
<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.1.0" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\Core\Core.csproj" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\Infrastructure\Infrastructure.csproj" />
</ItemGroup>
</Project>
I was having a similar/related problem a week ago (if you ask me to recall it, I'd need to go through heaps of my screenshots). I was able to deploy my Azure function via GitHub but it wouldn't work and I made satisfactory progress by changing (in the Azure Portal) the value of Configuration | Function Runtime Settings | Runtime Version to the value: ~4. However, just today, the portal is warning me to go back to the value: ~3. So, it is just something you might want to try and be prepared to undo.
On a loosely related topic, yesterday I started having problems with deployment again (via GitHub CI/CD). Today, in the Activity Log under a "Sync Web Apps Function Triggers" entry I saw the error: "Encountered an error (BadGateway) from host runtime". A few minutes later it was cleared (and it said it had run for 13 minutes). Now, I'd been in the portal about 15 minutes, so that might have fixed today's issue -- I figured the job was still in the queue and today it was able to pick it up and work it through. By visiting the function in the portal, it must have helped initialize it somehow. Still working on this one. I'll try resetting the Runtime Version value back to the suggested value ~3.
Good luck with your issue. Cheers, Henk.
I have tried replicating your setup (e.g. "Functions" name) on a Mac with Visual Studio details bellow, without any issues however. If you've used any preview version of VS or even Azure Function Extensions, then I suggest you re-create a new project and import your artifacts.
My setup is the following:
Release ID: 1703001972
Git revision: 8eb3c1bb0f14a8e54ee7c227c7047c46cff6ee8c. Build date: 2022-07-12 19:09:28+00
Build branch: release-17.3
Running on .NET 6.0.5 (64-bit)
Operating System: Mac OS X 12.4.0
Darwin 21.5.0 Darwin Kernel Version 21.5.0

${currentdir} target is not generating file anymore

I have recently upgraded my asp.net core project to .net core 2.2 and at same time updated NLog.Web.AspNetCore.
After I did this (maybe coincidence?) I noticed that log files are not being generated.
In my config this is my target:
<target xsi:type="File" name="allfile" fileName="${currentdir}/Logs/nlog-all-${shortdate}.log"
layout="${longdate}|${event-properties:item=EventId_Id}|${uppercase:${level}}|${logger}|${message} ${exception:format=tostring}" />
After some debugging I realised that if I specified the path explicitly then it would generate log file:
<target xsi:type="File" name="allfile" fileName="E:\Project\Logs\nlog-all-${shortdate}.log"
layout="${longdate}|${event-properties:item=EventId_Id}|${uppercase:${level}}|${logger}|${message} ${exception:format=tostring}" />
I have throwExceptions="true" set in config but when a file is not generated no exception is thrown, it just silently doesn't create the file.
To further debug this I created a console project and added nuget NLog.Web.AspNetCore and copied my config. Now in the console project it works fine and is creating log files in the debug output directory.
Is there any way to debug why the log file isn't being generated with this target in my main project?
Instead of using ${currentdir} then consider using ${aspnet-appbasepath} (Or ${basedir} if not in-process-hosting)
NLog InternalLogger usually gives very good hints when something is not working as expected.
Please avoid using throwExceptions="true" as it is for unit-testing, and not for production environments.

Cannot run PowerShell scripts in Azure Functions v2

I'm trying to write a Function App using .NET Core in Azure Functions v2. When using the Microsoft.Powershell.SDK package from Nuget (required for .NET Core PowerShell runtime) I cannot get Visual Studio to copy the System.Management.Automation library to the bin with my Function App.
This results in the following error:
System.Private.CoreLib: Exception while executing function: Function1. TestPowershellInFunction: Could not load file or assembly 'System.Management.Automation, Version=6.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. System.Private.CoreLib: Could not load the specified file.
I've reproduced this in an existing Azure Function and a new Solution by simply creating a Timer function and adding the following snippet:
PowerShell shell = PowerShell.Create();
IEnumerable<PSObject> result = shell.AddScript("Write-Output 'Hello, World!'").Invoke();
foreach(PSObject line in result)
{
log.LogInformation(line.ToString());
}
This works on a new Console App with the PowerShell Nuget installed, but when added to the Function App I get the error. I do notice that System.Management.Automation doesn't get put in the bin directory with a regular Console App but I'm not sure how to interpret this. I know it's a System library but I can't use it unless the Nuget is installed, so I don't know if this is a special case. In both scenarios I'm using v6.1.1 of the PowerShell Nuget.
Is this a known bug with Functions v2? Or am I missing something?
It's a known issue that Function can't load runtime assemblies([FunctionProject]\bin\Debug\netcoreapp2.1\bin\runtimes) correctly.
The workaround is to move assemblies to output dir bin manually. Right click on your function project and Edit <FunctionProject>.csproj. Add following items to achieve our goal.
<PropertyGroup>
<SDKVersion>6.1.1</SDKVersion>
<SDKPlatform>win-x86</SDKPlatform>
</PropertyGroup>
<ItemGroup>
<None Include="
$(USERPROFILE)\.nuget\packages\system.directoryservices\4.5.0\runtimes\win\lib\netcoreapp2.0\System.DirectoryServices.dll;
$(USERPROFILE)\.nuget\packages\system.management\4.5.0\runtimes\win\lib\netcoreapp2.0\System.Management.dll;
$(USERPROFILE)\.nuget\packages\system.management.automation\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\System.Management.Automation.dll;
$(USERPROFILE)\.nuget\packages\microsoft.management.infrastructure\1.0.0\runtimes\win10-x86\lib\netstandard1.6\Microsoft.Management.Infrastructure.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.commands.management\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.Commands.Management.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.commands.utility\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.Commands.Utility.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.commands.diagnostics\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.Commands.Diagnostics.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.sdk\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.SDK.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.security\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.Security.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.coreclr.eventing\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.CoreCLR.Eventing.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.consolehost\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.ConsoleHost.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.markdownrender\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.MarkdownRender.dll;
$(USERPROFILE)\.nuget\packages\microsoft.wsman.runtime\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.WSMan.Runtime.dll;
$(USERPROFILE)\.nuget\packages\microsoft.wsman.management\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.WSMan.Management.dll;
">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
<Target Name="CopyRuntimeToBin" AfterTargets="Build">
<Copy SourceFiles="
$(USERPROFILE)\.nuget\packages\system.directoryservices\4.5.0\runtimes\win\lib\netcoreapp2.0\System.DirectoryServices.dll;
$(USERPROFILE)\.nuget\packages\system.management\4.5.0\runtimes\win\lib\netcoreapp2.0\System.Management.dll;
$(USERPROFILE)\.nuget\packages\system.management.automation\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\System.Management.Automation.dll;
$(USERPROFILE)\.nuget\packages\microsoft.management.infrastructure\1.0.0\runtimes\win10-x86\lib\netstandard1.6\Microsoft.Management.Infrastructure.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.commands.management\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.Commands.Management.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.commands.utility\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.Commands.Utility.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.commands.diagnostics\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.Commands.Diagnostics.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.sdk\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.SDK.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.security\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.Security.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.coreclr.eventing\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.CoreCLR.Eventing.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.consolehost\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.ConsoleHost.dll;
$(USERPROFILE)\.nuget\packages\microsoft.powershell.markdownrender\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.PowerShell.MarkdownRender.dll;
$(USERPROFILE)\.nuget\packages\microsoft.wsman.runtime\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.WSMan.Runtime.dll;
$(USERPROFILE)\.nuget\packages\microsoft.wsman.management\$(SDKVersion)\runtimes\$(SDKPlatform)\lib\netstandard2.0\Microsoft.WSMan.Management.dll;
" DestinationFolder="$(OutputPath)\bin" />
</Target>
Note that microsoft.management.infrastructure is set to win10-x86 on my side(Win10), you may need to change according to your pc platform. Assemblies are x86 as VS uses x86 Function CLi by default, we don't need to worry about it unless we need to work with x64.

WebJobsStartup in Azure Functions v2 not working when targeting netcoreapp2.1

I have an Azure Function v2 app, that I originally targeted netcoreapp2.1.
I then have a Startup.cs class, annotated with [assembly: WebJobsStartup(typeof(Startup))] to set up dependency injection, but it did not register Startup in the extensions.json file.
This is happening during build. Publish has another issue at the moment.
When I change the TargetFramework in the project file to netstandard2.0 it successfully adds Startup to extensions.json:
{
"extensions":[
{ "name": "AzureStorage", "typeName":"Microsoft.Azure.WebJobs.Extensions.Storage.AzureStorageWebJobsStartup, Microsoft.Azure.WebJobs.Extensions.Storage, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"},
{ "name": "Startup", "typeName":"MyApp.Functions.Startup, MyApp.Functions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"}
]
}
While I do not have exact reasons to target netcoreapp2.1, I am curious to figure out why it doesn't work, as v2 was changed to target .Net Core by default.
I have upgraded the Microsoft.NET.SDK.Functions to version 1.0.26 from manage nuget packages and it worked.
This looks fixed now just upgrade Microsoft.NET.SDK.Functions to version 1.0.25 +
In my case, I had simply missed to explicitly set host.json to be copied. Adding these rows to the csproj file did the works:
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>

Continuous integration AND NuGet restore in VSO and Azure

We are using VSO and Azure Cloud Services (web roles).
Previously, we have used the following build.proj file for our VSO build definitions:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<OutDir>$(MSBuildThisFileDirectory)bin</OutDir>
<Configuration>Release</Configuration>
<ProjectProperties>OutDir=$(OutDir);Configuration=$(Configuration);</ProjectProperties>
</PropertyGroup>
<ItemGroup>
<Solution Include="$(MSBuildThisFileDirectory)*.sln" />
</ItemGroup>
<Target Name="RestorePackages">
<Exec Command=""$(MSBuildThisFileDirectory).nuget\NuGet.exe" restore "%(Solution.Identity)"" />
</Target>
<Target Name="Clean">
<MSBuild Targets="Clean" Projects="#(Solution)" Properties="$(ProjectProperties)" />
</Target>
<Target Name="Build" DependsOnTargets="RestorePackages">
<MSBuild Targets="Build" Projects="#(Solution)" Properties="$(ProjectProperties)" />
</Target>
<Target Name="Rebuild" DependsOnTargets="RestorePackages">
<MSBuild Targets="Rebuild" Projects="#(Solution)" Properties="$(ProjectProperties)" />
</Target>
</Project>
The reason for this is to execute NuGet restore before MSBuild began running. This is a suggested approach by NuGet.
Now that we are trying to set up continuous integration with our Azure cloud services, as instructed in this MSDN article.
This means that we must now use the TfvcContinuousDeploymentTemplate.12.xml build process template.
But when setting the template to build the build.proj file, the following build error occurs:
Exception Message: Deploying to Azure Cloud Service requires a Visual Studio Solution (.sln) that contains either a ccproj or a lsxproj. (type DeploymentException)
Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
When using the .sln, all works fine. But we obviously also need NuGet restore to occur before the build.
What is a good solution to have both continuous integration AND NuGet restore working?
I have just learnt that this is redundant. There is no reason to manually execute NuGet restore as this is already built into VSO/TFS.
Read more here.

Resources