Azure function project doesn't copy system.private.servicemodel.dll to the output directory #3568
Comments
|
From @Lxiamail on October 2, 2018 0:40 |
|
@Lxiamail - Did you already try the workaround mentioned in the issue you linked above? |
|
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. |
|
cc: @fabiocav |
|
This workaround dotnet/wcf#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: 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. |
|
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 |
|
Thanks @rhythmnewt, that works for me now. |
|
@fabiocav - Is there anything we can do to address this issue? |
|
Thank you @rhythmnewt This "solved" it for me too, so we can at least keep dev process going until a proper fix arrives 👍 |
|
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. |
|
@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. |
|
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. |
|
@fabiocav how does Azure function calculate the app dependencies? Does it look at only direct dependencies or it calculate the transact dependencies as well? |
|
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. |
|
Small bump. |
|
@bartdk-be Same here. Note that I am using Azure Durable Functions. |
|
I am also running into this using Durable Functions, and having no luck with the posted workarounds. |
|
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. |
|
@iwaldman @brendan-mcmahon 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 Not sure that helps, but thought it may be helpful for some. |
|
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:
This will drop the function deps file in the bin output, and the runtime will use that information to load those assets. |
|
Thank you all. Will try the two options. |
Update to fix issue described in Azure/azure-functions-host#3568
|
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 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 |
|
The default project template has been updated to target .NET Core app. I'll submit a documentation update to do the same there. |
|
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. |
|
@fabiocav the issues does not appear to be fixed as my functions project already targets In my case, my csproj looks like: dotnet --info results: |
|
@nero120 I think you still need to add this target per @fabiocav response: |
|
Ah I missed that, thanks @ghills! |
|
I'm still seeing this issue. Is it fixed? |
|
@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) |
|
@IGx89 thank you for that, coincidentally I was just looking into why this problem was occurring in Azure and your solution resolved the issue! 🥇 |
|
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). |
|
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? |
|
@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 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 |
|
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:
|
|
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: |
|
Thank you @rhythmnewt! Your workaround fixed it for me as well (using Azure Functions with SOAP client). |
|
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> |
|
Yes works for me in local and Azure DevOps |
|
Updating to 4.6.0 solved this issue for me and I could remove the hack. |
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: This helps when running functions in a linux Docker container. |
|
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.
I used the azure functions project to make my integration and it uses .NET Core 3.0 and azurefunctions v2. |
|
That's because Azure Functions v2 is incompatible with the .NET Core 3.0 SDK, I recently found out. See Azure/azure-functions-vs-build-sdk#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> |
ghost
locked as resolved and limited conversation to collaborators
and others
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
The text was updated successfully, but these errors were encountered: