This is the same issue with #3568. That issue is closed but we still need to manually modify the csproj file to make it copy the dll. This doesn't seem fixed at all.
@mahl the file will be in the runtimes. Did you add the post-build step as mentioned in the referenced issue?
I know I can fix it by adding the post-build. The problem is it _should_ work as is, without manually editing the project file.
Yes, the work to automate the process and eliminate the need to setup the post-build step is tracked in the SDK.
I'll leave this issue open and update once those changes are done.
It's two month's later now, although the reports go back 9 months or so:
https://github.com/Azure/azure-functions-host/issues/3052
https://github.com/Azure/azure-functions-host/issues/3568
https://github.com/Azure/Azure-Functions/issues/1138
https://github.com/Azure/Azure-Functions/issues/974
https://github.com/dotnet/wcf/issues/2824
https://github.com/dotnet/wcf/issues/2885
https://github.com/Azure/azure-webjobs-sdk/issues/2050
...and probably a few more.
Plenty of issues, but no permanent solution.
Is it unreasonable of me to expect a Function project to produce a working build even when using common nuget packages?
@AVee I understand the following project modification is a workaround, but this is essentially the behavior the SDK will have in place out of the box. While this does require a manual step, it should resolve the issue you're seeing. Is this not working for you?
<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>
Yes, that workaround works. But it shouldn't be required, that's the point.
Right now you when you create a function package and happen to add the wrong dependency you end up with something that works locally and breaks when you deploy it to Azure. That's has to be classified as a serious bug imho. Even more so because the error isn't clear and it may require quite a bit of time to find out what's happening.
If it's not fixable in the sdk I guess it can still be fixed in the Visual Studio template if nothing else.
@AVee no disagreement on the fact that this shouldn't be required. This is fixable in the SDK, and that is work that is currently planned, but unfortunately, and also due to the fact that there is a valid workaround, the priority of other work items has kept the team from getting this work done.
We understand this has an impact, apologize for the inconvenience, and appreciate the patience. We'll hopefully have this addressed by the end of the next sprint.
Just for the record, the project's name MUST match the assembly name specified in the project's properties. Otherwise it wont build.
I had a file structure like
B
C.D (assembly name A.B.C.D)
And had to change to
B
A.B.C.D
Hope it helps someone.
We'll hopefully have this addressed by the end of the next sprint.
Ok, at least it's good to know it's not falling of the radar.
Are there any updates on this issue? The Workaround doesn't seem to be working for me. I do see that the copy step is working and my projectname.deps.json file is copied to the bin folder as function.deps.json but then it is still failing with the System.Private.ServiceModel file not found error on generating the functions.
I dug into the runtimes folder and I do see the dll in there, however despite targeting .Net Core 2.1 it is ending up in the following path: \runtimes\win\libnetstandard2.0
Which I see in the deps file(s) that is the path referenced, but it just seemed strange to me.
@qdi-jeffd It works, but the filename must be function.deps.json
I just did it again today for one more project.
Let me know I can help you further.
I was able to get it working via the workaround in the following comment:
https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-433146109
Thanks for the offer of help though.
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>
Just in case anyone else runs into similar issues as me. I ended up having to use all 3 workaround mentioned here
Also as it relates to the copy to create the function.deps.json file since my paths had a space in it I was getting an error with the copy command (exited with code 1). Putting " around the paths resolved that:
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<!-- Ref: 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">
<!--Ref: https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-461182536-->
<Exec Command="copy "$(PublishDir)$(ProjectName).deps.json" "$(PublishDir)bin\function.deps.json"" />
</Target>
Thanks to everyone helping in this thread!
Jeff
Updating to 4.6.0 solved this issue for me and I could remove the hack.
Updating what to 4.6.0?
The WCF NuGet packages
The face the issue still in 2020-05, have to update packages, thx @SaebAmini . The VS 2019 Add/Configure WCF Web Service wizard should be updated to use new package versions 4.7.0 instead of the obsolete and problem causing 4.4.*:
<PackageReference Include="System.ServiceModel.Duplex" Version="4.4.*" />
<PackageReference Include="System.ServiceModel.Http" Version="4.4.*" />
<PackageReference Include="System.ServiceModel.NetTcp" Version="4.4.*" />
<PackageReference Include="System.ServiceModel.Security" Version="4.4.*" />
Most helpful comment
The WCF NuGet packages