Azure-functions-host: Azure function project doesn't copy system.private.servicemodel.dll to the output directory

[pragnagopa]

_From @Lxiamail on October 2, 2018 0:35_

When Azure function references and uses one of WCF core packages (like system.servicemodel.http), system.private.servicemodel.dll, which system.servicemodel.http depends on, is not copied to output directory together with system.servicemodel.http. The azure function fails for can't find system.private.servicemodel.dll. Looks like other WCF core dependencies (like system.servicemodel.primitives.dll) are copied correctly, but system.private.servicemodel.dll. My guess is that Azure function may not handle the reference assembly, façade and implementation assembly pattern correctly.
Some background of WCF Core packages, system.servicemodel.*.dll (like system.servicemodel.http) are reference assemblies (in ref directory of the package) facade assemblies (in lib directory of the package), The façade assemblies don't have implementation, all they do is typeforward to the implementation assembly system.private.servicemodel.dll. App never directly references to system.private.servicemodel.dll. .NET Corefx follows the same façade and implementation pattern. The difference between WCF Core packages and .NET CoreFX packages is .NET CoreFX are in .NET Core SDK as shared framework, but WCF Core doesn't. This is why mscorlib.dll is not copied to app output directory, but still can be loaded.

OS: windows 10 version 1803 (OS build 17134.286)

VS: VS pro 2017 version 15.7.5

Repro steps:

Create a new Azure function http trigger Project,
Add system.servicemodel.http Nuget package to the reference using NugetPackage manager
Add
Use this repo to file issues in documentation or the Functions Visual Studio tooling.
Adding the follow code in Function1.Run() function to make the function to use something implemented in WCF Core packages.
System.ServiceModel.BasicHttpBinding binding = new System.ServiceModel.BasicHttpBinding();
binding.Name = "binding1";

Build and debug the azure function in VS, after the function is trigger by Http request, you will get the following error:
[10/1/2018 11:39:36 PM] Executing 'Function1' (Reason='This function was programmatically called via the host APIs.', Id=67985bea-8a52-431a-8d65-4ded513269ce)
[10/1/2018 11:39:36 PM] Exception during runtime resolution of assembly 'System.Private.ServiceModel, Version=4.5.0.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a': 'System.InvalidCastException: [A]System.AppDomain cannot be cast to [B]System.AppDomain. Type A originates from 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' in the context 'Default' at location 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.9\System.Private.CoreLib.dll'. Type B originates from 'System.Runtime.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' in the context 'Default' at location 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.9\System.Runtime.Extensions.dll'.
[10/1/2018 11:39:36 PM] at Microsoft.Azure.WebJobs.Script.Description.FunctionAssemblyLoader.ResolveAssembly(Object sender, ResolveEventArgs args) in C:\azure-webjobs-sdk-script\src\WebJobs.Script\Description\DotNet\FunctionAssemblyLoader.cs:line 66'
[10/1/2018 11:39:36 PM] Unable to find assembly 'System.Private.ServiceModel, Version=4.5.0.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Are you missing a private assembly file?
[10/1/2018 11:39:37 PM] Executed 'Function1' (Failed, Id=67985bea-8a52-431a-8d65-4ded513269ce)
[10/1/2018 11:39:37 PM] System.Private.CoreLib: Exception while executing function: Function1. FunctionApp4: Could not load file or assembly 'System.Private.ServiceModel, Version=4.5.0.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

_Copied from original issue: Azure/Azure-Functions#974_

[pragnagopa]

_From @Lxiamail on October 2, 2018 0:40_

https://github.com/dotnet/wcf/issues/2824

[pragnagopa]

@Lxiamail - Did you already try the workaround mentioned in the issue you linked above?

[pragnagopa]

_From @Lxiamail on October 3, 2018 19:55_

@pragnagopa Yes. Zhenlan's work around in #dotnet/wcf#2824 worked for me. However, there are other customers reported the same issue and asked for long term fix. I'm not sure if the work around worked for all customers. My team owns WCF Core packages. Please feel free to contact us if you need more context of the WCF Core packages.

[pragnagopa]

cc: @fabiocav

[j055]

This workaround https://github.com/dotnet/wcf/issues/2824 does not work for me in a Function v2 app. The workaround allows me to debug locally but the DLL is not published or is removed if the file is uploaded manually when running in Azure.

csproj used:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <AzureFunctionsVersion>v2</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.23" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="System.ServiceModel.Duplex" Version="4.5.3" />
    <PackageReference Include="System.ServiceModel.Http" Version="4.5.3" />
    <PackageReference Include="System.ServiceModel.NetTcp" Version="4.5.3" />
    <PackageReference Include="System.ServiceModel.Security" Version="4.5.3" />
  </ItemGroup>
  <ItemGroup>
    <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <None Update="System.Private.ServiceModel.dll">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
  </ItemGroup>
  <Target Name="CopySPSM" BeforeTargets="Build">
    <Copy SourceFiles="$(USERPROFILE)\.nuget\packages\system.private.servicemodel\4.5.3\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" DestinationFolder="$(OutputPath)\bin" />
  </Target>
</Project>

I am interested to know if someone can get this working in a Function v2 app and how this is done. Otherwise this fix needs to be expedited.

[rhythmnewt]

I had to create a CopyToPublishDirectory ItemGroup and specify direct path to the assembly, just like in the Build target. This way it's picked up correctly when publishing, and I have the publish working from both local and from DevOps pipeline.

Edit: CopyToOutputDirectory ItemGroup doesn't do anything in this case and I don't even have that in my .csproj

  <!--
  this is temporary workaround for issue https://github.com/dotnet/wcf/issues/2824 
  also requires nuget package
  -->
  <Target Name="CopySPSM" BeforeTargets="Build">
    <Copy SourceFiles="$(USERPROFILE)\.nuget\packages\system.private.servicemodel\4.5.3\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" DestinationFolder="$(OutputPath)\bin" />
  </Target>
  <ItemGroup>
    <None Include="$(USERPROFILE)\.nuget\packages\system.private.servicemodel\4.5.3\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" CopyToPublishDirectory="Always" />
  </ItemGroup>
  <!--end workaround-->

[j055]

Thanks @rhythmnewt, that works for me now.

[pragnagopa]

@fabiocav - Is there anything we can do to address this issue?

[Kazpers]

Thank you @rhythmnewt This "solved" it for me too, so we can at least keep dev process going until a proper fix arrives 👍

[fabiocav]

We rely on the build and move all dependencies and runtime specific dependencies to the output. I'll spend some time investigating this to see if this is truly a runtime/build issue on our side, but in the meantime, the documented workaround seems to be the recommended solution.

[Lxiamail]

@fabiocav this "We rely on the build and move all dependencies and runtime specific dependencies to the output." may be the problem. As I stated early, WCF Core packages build time dependencies are all reference assemblies, and runtime dependencies are facades assemblies. The facades assemblies don't have any implementation, they type forward to system.private.servicemodel.dll, which contains actually implementation. However, system.private.servicemodel.dll is not directly referenced by the application (in this case Azure function). If Azure function build only move the direct dependencies to the output, system.private.servicemodel.dll may be missed.

[fabiocav]

That would indeed be problematic. The functions are expected to deploy any dependency not expected to be brought in by .NET Core Azure Functions Host, and that is one of them.
I'm tracking some enhancements that would help with this, in functions, but this would be a general issue for customers who expect to have what they're building dynamically loaded by a host environment that does not have a direct reference to System.Private.ServiceModel.dll.

[Lxiamail]

@fabiocav how does Azure function calculate the app dependencies? Does it look at only direct dependencies or it calculate the transact dependencies as well?

[fabiocav]

It loads transient dependencies in isolation as well. There are some enhancements I'm working on that may actually help with this issue. I'm running some tests now to validate.

[bartdk-be]

Small bump.
Facing same issue when trying to call SOAP client (using Connected Services)

[iwaldman]

@bartdk-be Same here. Note that I am using Azure Durable Functions.

[brendan-mcmahon]

I am also running into this using Durable Functions, and having no luck with the posted workarounds.

[tylerhartwig]

I'm running into this issue as well, and the given workarounds also don't solve my problem.

However, I've found the version of Azure Tools that Visual Studio downloads is able to run our function, while the version I manually downloaded from Github/npm is not able to.

I'm also facing the same issue in Azure, even with the workaround implemented.

[tylerhartwig]

@iwaldman @brendan-mcmahon
Are you two having issues with not copying the System.Private.ServiceModel.dll?

I was having an issue with failing to resolve a method in the NetTcp assembly, and arrived at this work around as well. I found that if you revert to the Azure Function Extension version to 2.0.12246 then it fixed the issue for me. The underlying problem was that past that version the powershell worker was added, and Azure was resolving to assemblies in that directory, rather than the one from our function.

Not sure that helps, but thought it may be helpful for some.

[fabiocav]

Been meaning to follow up on this as well to share some recent enhancements made to the runtime. There will be additional tooling work to make this the default behavior, but in the meantime, can you add the following post-build event command to your Azure Functions project:

copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json

This will drop the function deps file in the bin output, and the runtime will use that information to load those assets.

[iwaldman]

Thank you all. Will try the two options.

[brendan-mcmahon]

I wasn't having any luck manually adding the dll and then forcing the copy, but a coworker of mine discovered that I was using the wrong version.
I was using the C:\Users\{username}\.nuget\packages\system.private.servicemodel>4.5.3>runtimes>win>lib>netcore50>System.Private.ServiceModel.dll
when I should have been using the C:\Users\{username}\.nuget\packages\system.private.servicemodel>4.5.3>runtimes>unix>lib>netstandard2.0>System.Private.ServiceModel.dll
(basically, use the Unix one, not the Windows one)

I don't know if that helps anyone, but it seems like that was what the problem ended up being for me.

[fabiocav]

@brendan-mcmahon have you tried what I mentioned above? That will remove the need for you to point to a specific DLL, and work on multiple platforms as well.

[brendan-mcmahon]

@fabiocav - I added the command you suggested, but now I'm getting the same error but on build instead of at runtime:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Private.ServiceModel, Version=4.5.0.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

I will admit that it's very possible that I've missed something though.

[fabiocav]

@brendan-mcmahon would be happy to take a look. Can you share your project (or, more ideally, just a basic repro) on a GitHub repo so we can look at your setup and what you're running into?

[ghills]

Been meaning to follow up on this as well to share some recent enhancements made to the runtime. There will be additional tooling work to make this the default behavior, but in the meantime, can you add the following post-build event command to your Azure Functions project:

copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json

This will drop the function deps file in the bin output, and the runtime will use that information to load those assets.

@fabiocav I'm also running into an error for System.Private.ServiceModel. I can't really share the project as it uses a number of internal libraries but if I get a chance I will see if I can make a small project to reproduce the error.

In the meantime I don't know if it will be helpful but here is the function.deps.json file it copied to the bin directory:

https://gist.github.com/ghills/e10d06b281f11acb69f3e0d37e936ac9

and the error:

[2/11/2019 4:04:29 PM] System.Private.CoreLib: Exception while executing function: SubmitViaFaxActivity. AgencyRM.ConcordFax.SDK: Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.2.4, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. System.Private.CoreLib: Could not load the specified file.
[2/11/2019 4:04:29 PM] 8257681cb67342489e93e065ed6205da:1: Function 'SubmitViaFaxActivity (Activity)' failed with an error. Reason: System.IO.FileNotFoundException: Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.2.4, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
[2/11/2019 4:04:29 PM] File name: 'System.Private.ServiceModel, Version=4.1.2.4, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.IO.FileNotFoundException: Could not load the specified file.
[2/11/2019 4:04:29 PM] File name: 'System.Private.ServiceModel'
[2/11/2019 4:04:29 PM]    at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingEvent(AssemblyName assemblyName)
[2/11/2019 4:04:29 PM]    at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingResolvingEvent(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)

[brendan-mcmahon]

@fabiocav - I'm in the same boat as @ghills in terms of sharing code. It also looks like we're seeing the same error. I will also try to create a repro project if I get time.

[ghills]

@fabiocav

It ended up being pretty simple to reproduce. See the sample repo here:
https://github.com/ghills/TestConcordFunctionApp

In this case the project ServiceLibrary mimics the DLL we use that actually has the SOAP service reference.

Here is the output I get when it runs:

Azure Functions Core Tools (2.4.299 Commit hash: 0f105e9bc6e2faed71e8521d7541a909a6dcc389)
Function Runtime Version: 2.0.12285.0
[2/11/2019 4:54:00 PM] Starting Rpc Initialization Service.
[2/11/2019 4:54:00 PM] Initializing RpcServer
[2/11/2019 4:54:00 PM] Building host: startup suppressed:False, configuration suppressed: False
[2/11/2019 4:54:00 PM] Reading host configuration file 'C:\Users\gavin.hills\source\repos\TestConcordFunctionApp\TestConcordFunctionApp\bin\Debug\netstandard2.0\host.json'
[2/11/2019 4:54:00 PM] Host configuration file read:
[2/11/2019 4:54:00 PM] {
[2/11/2019 4:54:01 PM]   "version": "2.0"
[2/11/2019 4:54:01 PM] }
[2/11/2019 4:54:02 PM] Initializing Host.
[2/11/2019 4:54:02 PM] Host initialization: ConsecutiveErrors=0, StartupCount=1
[2/11/2019 4:54:02 PM] LoggerFilterOptions
[2/11/2019 4:54:02 PM] {
[2/11/2019 4:54:02 PM]   "MinLevel": "None",
[2/11/2019 4:54:02 PM]   "Rules": [
[2/11/2019 4:54:02 PM]     {
[2/11/2019 4:54:02 PM]       "ProviderName": null,
[2/11/2019 4:54:02 PM]       "CategoryName": null,
[2/11/2019 4:54:02 PM]       "LogLevel": null,
[2/11/2019 4:54:02 PM]       "Filter": "<AddFilter>b__0"
[2/11/2019 4:54:02 PM]     },
[2/11/2019 4:54:02 PM]     {
[2/11/2019 4:54:02 PM]       "ProviderName": "Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.SystemLoggerProvider",
[2/11/2019 4:54:02 PM]       "CategoryName": null,
[2/11/2019 4:54:02 PM]       "LogLevel": "None",
[2/11/2019 4:54:02 PM]       "Filter": null
[2/11/2019 4:54:02 PM]     },
[2/11/2019 4:54:02 PM]     {
[2/11/2019 4:54:02 PM]       "ProviderName": "Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.SystemLoggerProvider",
[2/11/2019 4:54:02 PM]       "CategoryName": null,
[2/11/2019 4:54:02 PM]       "LogLevel": null,
[2/11/2019 4:54:02 PM]       "Filter": "<AddFilter>b__0"
[2/11/2019 4:54:02 PM]     }
[2/11/2019 4:54:02 PM]   ]
[2/11/2019 4:54:02 PM] }
[2/11/2019 4:54:02 PM] FunctionResultAggregatorOptions
[2/11/2019 4:54:02 PM] {
[2/11/2019 4:54:02 PM]   "BatchSize": 1000,
[2/11/2019 4:54:02 PM]   "FlushTimeout": "00:00:30",
[2/11/2019 4:54:02 PM]   "IsEnabled": true
[2/11/2019 4:54:02 PM] }
[2/11/2019 4:54:02 PM] SingletonOptions
[2/11/2019 4:54:02 PM] {
[2/11/2019 4:54:02 PM]   "LockPeriod": "00:00:15",
[2/11/2019 4:54:02 PM]   "ListenerLockPeriod": "00:00:15",
[2/11/2019 4:54:02 PM]   "LockAcquisitionTimeout": "10675199.02:48:05.4775807",
[2/11/2019 4:54:02 PM]   "LockAcquisitionPollingInterval": "00:00:05",
[2/11/2019 4:54:02 PM]   "ListenerLockRecoveryPollingInterval": "00:01:00"
[2/11/2019 4:54:02 PM] }
[2/11/2019 4:54:02 PM] Starting JobHost
[2/11/2019 4:54:02 PM] Starting Host (HostId=armvanpc06-2074930811, InstanceId=40559c9c-58c1-41ab-b46a-ba5683bcc1d8, Version=2.0.12285.0, ProcessId=26552, AppDomainId=1, InDebugMode=False, InDiagnosticMode=False, FunctionsExtensionVersion=)
[2/11/2019 4:54:02 PM] Loading functions metadata
[2/11/2019 4:54:02 PM] 1 functions loaded
[2/11/2019 4:54:02 PM] WorkerRuntime: dotnet. Will shutdown other standby channels
[2/11/2019 4:54:03 PM] Generating 1 job function(s)
[2/11/2019 4:54:03 PM] Found the following functions:
[2/11/2019 4:54:03 PM] TestConcordFunctionApp.Function1.Run
[2/11/2019 4:54:03 PM]
[2/11/2019 4:54:03 PM] Host initialized (1018ms)
[2/11/2019 4:54:04 PM] The next 5 occurrences of the 'TestConcordFunctionApp.Function1.Run' schedule will be:
[2/11/2019 4:54:04 PM] 2/11/2019 8:55:00 AM
[2/11/2019 4:54:04 PM] 2/11/2019 9:00:00 AM
[2/11/2019 4:54:04 PM] 2/11/2019 9:05:00 AM
[2/11/2019 4:54:04 PM] 2/11/2019 9:10:00 AM
[2/11/2019 4:54:04 PM] 2/11/2019 9:15:00 AM
[2/11/2019 4:54:04 PM]
[2/11/2019 4:54:04 PM] Host started (1960ms)
[2/11/2019 4:54:04 PM] Job host started
Hosting environment: Production
Content root path: C:\Users\gavin.hills\source\repos\TestConcordFunctionApp\TestConcordFunctionApp\bin\Debug\netstandard2.0
Now listening on: http://0.0.0.0:7071
Application started. Press Ctrl+C to shut down.
[2/11/2019 4:54:09 PM] Host lock lease acquired by instance ID '0000000000000000000000009A46158C'.
[2/11/2019 4:55:00 PM] Executing 'Function1' (Reason='Timer fired at 2019-02-11T08:55:00.0859558-08:00', Id=31269f1c-8183-41ed-b95e-5a72e52e97e8)
[2/11/2019 4:55:01 PM] Executed 'Function1' (Failed, Id=31269f1c-8183-41ed-b95e-5a72e52e97e8)
[2/11/2019 4:55:01 PM] System.Private.CoreLib: Exception while executing function: Function1. TestConcordFunctionApp: Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.2.4, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. System.Private.CoreLib: Could not load the specified file.

and the local settings I used:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "AzureWebJobsDashboard": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet"
  }
}

[fabiocav]

Thank you for the follow up! Will investigate this and provide an update as soon as possible.

[sharpcoder28]

I'm using durable functions and rhythmnewt's answer fixed it for me

[mconnew]

@fabiocav, I looked into this a while ago and I believe the problem is that it looks like when calculating the transitive set of dependent packages, net46 is being used as the target framework. Then when building the output folder to send to Azure functions, the correct target framework is then used to select which runtime bits to use. On net46, our public packages don't have a dependency on System.Private.ServiceModel as the implementation is the in-box .Net Framework implementation. So if you calculate the set of dependencies using a netfx id such as net46, you won't get System.Private.ServiceModel included.

[fabiocav]

@mconnew thanks follow up! I haven't had a chance to follow up on what was last reported yet, but the work that was done should be handling that. I'll prioritize this and have an update soon.

[fabiocav]

Spent a bit of time looking at this today. The new logic handles this as expected if the deps file is correctly generated, but because of your target, runtime dependencies were not present there (this the default .NET behavior). If you update your target to netcoreapp2.1, that should address the problem.

As an example, I've sent a PR to @ghills' repo to show the diff: https://github.com/ghills/TestConcordFunctionApp/pull/1/files

[ghills]

Spent a bit of time looking at this today. The new logic handles this as expected if the deps file is correctly generated, but because of your target, runtime dependencies were not present there (this the default .NET behavior). If you update your target to netcoreapp2.1, that should address the problem.

As an example, I've sent a PR to @ghills' repo to show the diff: https://github.com/ghills/TestConcordFunctionApp/pull/1/files

@fabiocav interesting - this does fix it for me.

So I had based the target framework on the documentation at https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-class-library#microsoftnetsdkfunctions which lists netstandard2.0. If the deps file is not correctly generated for netstandard2.0 would you consider netcoreapp2.1 the correct target framework guidance?

[fabiocav]

The default project template has been updated to target .NET Core app. I'll submit a documentation update to do the same there.

[fabiocav]

I'm closing this as resolved with the information provided above. If others experience similar issues, please open a new issue with details and we'll investigate.

[nero120]

@fabiocav the issues does not appear to be fixed as my functions project already targets netcoreapp2.1 and System.Private.ServiceModel.dll is not copied to the correct bin location. After build, I can see it in a subfolder within the projects bin folder (specifically, in bin\Debug\netcoreapp2.1\bin\runtimes\win\lib\netstandard2.0 but as it's not present in bin\Debug\netcoreapp2.1\bin I get a runtime error that the assembly cannot be found. Note: @rhythmnewt's work around above temporarily resolves this issue for me.

In my case, my csproj looks like:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup Label="Globals">
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
  </PropertyGroup>
  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <AzureFunctionsVersion>v2</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.WebJobs" Version="3.0.4" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Core" Version="3.0.4" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="3.0.3" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.25" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

dotnet --info results:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.503
 Commit:    4c506e0f35

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.503\

Host (useful for support):
  Version: 2.1.7
  Commit:  cca5d72d48

.NET Core SDKs installed:
  1.0.0-preview2-003131 [C:\Program Files\dotnet\sdk]
  1.0.4 [C:\Program Files\dotnet\sdk]
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.300 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]
  2.1.503 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[ghills]

@nero120 I think you still need to add this target per @fabiocav response:

  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <!-- https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-461182536 -->
    <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
  </Target>

[nero120]

Ah I missed that, thanks @ghills!

[mahl]

I'm still seeing this issue. Is it fixed?

[IGx89]

@ghills (and @fabiocav), thanks a lot for that workaround, definitely cleaner than the previous workaround we were using that required manually including the DLL. However, that new workaround only partially works as-is: it works great for builds, but has no effect on publishes (very common scenario I assume). Here's an updated workaround that also works for publishes (tested on both MSBuild 15.9 and 16.0):

  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <!-- https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-461182536 -->
    <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
  </Target>
  <Target Name="PostPublish" AfterTargets="AfterPublish">
    <!-- https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-461182536 -->
    <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
  </Target>

(if someone has a cleaner method please share)

[nero120]

@IGx89 thank you for that, coincidentally I was just looking into why this problem was occurring in Azure and your solution resolved the issue! 🥇

[Kazpers]

I really don't think this can be called solved if you still need to add manual Postbuild workarounds (note haven't had time to test this myself as I'm in a new job now so the project where this was relevant is no longer available to me).

[brendan-mcmahon]

I was just testing locally after updating to durable 1.8. It seems like it's working after removing the workarounds I'd implemented, but I didn't see this mentioned in the release notes. Was this addressed? Either intentionally or inadvertently? Or is it a weird fluke that this is working now?

[AtOMiCNebula]

@fabiocav, this arguably shouldn't have been closed. Or at least, I wouldn't consider this closed until such a time when "workarounds" aren't needed anymore. Would you agree?

I had to alter my custom MSBuild <Target>s slightly from what was provided above. The function.deps.json wasn't getting included in my ZIP package; not sure if the prior solution works if you don't use ZIP package deployments, I didn't bother checking. Here's what I went with:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
  <!-- https://github.com/Azure/azure-functions-host/issues/3568 -->
  <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
</Target>
<Target Name="PostPublish" BeforeTargets="CreateZipFile">
  <!-- https://github.com/Azure/azure-functions-host/issues/3568 -->
  <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
</Target>

Only meaningful change from above was revising PostPublish to use BeforeTargets="CreateZipFile".

[Cartan]

Still won't work for me, even with the workarounds. I simply cannot compile a function project that contains a service reference. I always get:

C:\Users\nils.nuget\packages\microsoft.net.sdk.functions\1.0.27\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets(41,5): error : System.IO.FileNotFoundException: Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.2.4, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Das System kann die angegebene Datei nicht finden.
1>C:\Users\nils.nuget\packages\microsoft.net.sdk.functions\1.0.27\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets(41,5): error : File name: 'System.Private.ServiceModel, Version=4.1.2.4, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

...
Error generating functions metadata

[SaebAmini]

The only workaround that did the job for me was copying the DLL from the runtime folder, to the bin folder, after build and publish events, by adding this to my Azure Function app csproj, I noticed the DLL is copied there, but the function host doesn't know how to find it:

<Target Name="FixForDotnetWcfIssueBuild" BeforeTargets="PostBuildEvent">
  <Copy SourceFiles="$(OutputPath)bin\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" DestinationFolder="$(OutputPath)bin" />
</Target>
<Target Name="FixForDotnetWcfIssuePublish" AfterTargets="AfterPublish">
  <Copy SourceFiles="$(PublishDir)bin\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" DestinationFolder="$(PublishDir)bin" />
</Target>

[ramito1]

Thank you @rhythmnewt! Your workaround fixed it for me as well (using Azure Functions with SOAP client).

[Tiberriver256]

For mine to work with MSBuild I had to modify the publish copy step as follows:

<Target Name="FixForDotnetWcfIssuePublish" BeforeTargets="_GenerateFunctionsAndCopyContentFiles">
  <!-- https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-514445944 -->
  <Copy SourceFiles="$(PublishDir)bin\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" DestinationFolder="$(PublishDir)bin" />
</Target>

[nomansadiq11]

Yes works for me in local and Azure DevOps

[SaebAmini]

Updating to 4.6.0 solved this issue for me and I could remove the hack.

[tobyreid]

@fabiocav, this arguably shouldn't have been closed. Or at least, I wouldn't consider this closed until such a time when "workarounds" aren't needed anymore. Would you agree?

I had to alter my custom MSBuild <Target>s slightly from what was provided above. The function.deps.json wasn't getting included in my ZIP package; not sure if the prior solution works if you don't use ZIP package deployments, I didn't bother checking. Here's what I went with:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
  <!-- https://github.com/Azure/azure-functions-host/issues/3568 -->
  <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
</Target>
<Target Name="PostPublish" BeforeTargets="CreateZipFile">
  <!-- https://github.com/Azure/azure-functions-host/issues/3568 -->
  <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
</Target>

Only meaningful change from above was revising PostPublish to use BeforeTargets="CreateZipFile".

I had a similar problem using Google.Ads.GoogleAds =2.5.0 with Azure.Net.Sdk.Functions =1.0.29

Resolved using this method for both Windows/Linux:

<Target Name="PostBuildWindows" AfterTargets="PostBuildEvent" Condition="'$(OS)' == 'Windows_NT'">
    <!--https://github.com/Azure/azure-functions-host/issues/3568-->
    <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
    <Message Text="PostBuild Copied $(OutDir)bin\function.deps.json" />  
  </Target>
  <Target Name="PostPublishWindows" BeforeTargets="AfterPublish" Condition="'$(OS)' == 'Windows_NT'">
    <!--https://github.com/Azure/azure-functions-host/issues/3568-->
    <Message Text="PostPublish Copied $(OutDir)bin\function.deps.json" />  
    <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
  </Target>
  <Target Name="PostBuildUnix" AfterTargets="PostBuildEvent" Condition="'$(OS)' != 'Windows_NT'">
    <!--https://github.com/Azure/azure-functions-host/issues/3568-->
    <Exec Command="cp -r $(OutDir)$(ProjectName).deps.json $(OutDir)bin/function.deps.json" />
    <Message Text="PostBuild Copied $(OutDir)bin/function.deps.json" />  
  </Target>
  <Target Name="PostPublishUnix" BeforeTargets="AfterPublish" Condition="'$(OS)' != 'Windows_NT'">
    <!--https://github.com/Azure/azure-functions-host/issues/3568-->
    <Exec Command="cp -r $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin/function.deps.json" />
    <Message Text="PostPublish Copied $(OutDir)bin/function.deps.json" />  
  </Target>

This helps when running functions in a linux Docker container.

[LasseAndersen]

I get the exception "TypeLoadException: Could not load type 'System.UriTemplate' from assembly 'System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".

I've tried some of the workarounds regarding copying the dll to the publish bin and none of them worked. Of course with my file structure.

<Target Name="FixForDotnetWcfIssueBuild" BeforeTargets="PostBuildEvent"> <Copy SourceFiles="$(OutputPath)bin\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" DestinationFolder="$(OutputPath)bin" /> </Target> <Target Name="FixForDotnetWcfIssuePublish" AfterTargets="AfterPublish"> <Copy SourceFiles="$(PublishDir)bin\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" DestinationFolder="$(PublishDir)bin" /> </Target>

I used the azure functions project to make my integration and it uses .NET Core 3.0 and azurefunctions v2.

[IGx89]

That's because Azure Functions v2 is incompatible with the .NET Core 3.0 SDK, I recently found out. See https://github.com/Azure/azure-functions-vs-build-sdk/issues/333 -- it puts the runtimes folder in the wrong spot!

Workaround (in addition to the normal workaround here, AtOMiCNebula's is working great for me) is to add a global.json with the following contents (matching the exact patch version of your latest installed .NET Core 2.x SDK) to the function project root -- that'll force the project to be built with the 2.x SDK:

{
  "sdk": {
    "version": "2.2.402"
  }
}

Here's also an alternative workaround (incorporating the primary workaround) if you'd like to still use the .NET Core 3.0 SDK, or need this fix for Functions v3 as well:

  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <!-- https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-461182536 -->
    <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
  </Target>
  <Target Name="PostPublish" BeforeTargets="Publish">
    <!-- https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-461182536 -->
    <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
    <!-- https://github.com/Azure/azure-functions-vs-build-sdk/issues/333 -->
    <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" />
  </Target>