wcf: .NET Core 2.0 self-contained app: Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
Hi,
I’m migrating a console application to .NET Core 2.0 and when I run the app on my server I’m receiving this message:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.Private.ServiceModel, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
This app is self-contained and has a netstandard2 library dependency that uses the System.ServiceModel.Http package to call an external api (using WCF).
When I publish the app using the win-x64 runtime identifier the file System.Private.ServiceModel.dll is not placed in the output folder.
If I use the win81-x64/win10-x64 runtime identifiers the file is placed in the output folder.
Is this the correct behavior?
Thanks!
Fabiano
How to simulate
-
Create the project:
dotnet new console
-
Update the csproj to:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.ServiceModel.Http" Version="4.4.0" />
</ItemGroup>
</Project>
- Update the Program.cs to:
using System;
using System.ServiceModel;
namespace Sample
{
class Program
{
static void Main(string[] args)
{
var binding = new BasicHttpBinding(BasicHttpSecurityMode.Transport)
{
MaxReceivedMessageSize = 5242880
};
Console.WriteLine("Hello World!");
}
}
}
-
Publish the project:
dotnet publish --configuration Release --runtime win-x64
-
Execute the exe file on the publish folder
dotnet --info output
.NET Command Line Tools (2.0.2)
Product Information:
Version: 2.0.2
Commit SHA-1 hash: a04b4bf512
Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.2\
Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 21 (6 by maintainers)
Commits related to this issue
- #123 Support module nested references loading in Platform modular system: - Reworked LoadContextAssemblyResolver assembly loading: every module assembly with all level dependencies is loaded into Asse... — committed to VirtoCommerce/vc-platform-core by yecli 5 years ago
- #123 Support module nested references loading in Platform modular system: - Reworked LoadContextAssemblyResolver assembly loading: every module assembly with all level dependencies is loaded into Asse... — committed to VirtoCommerce/vc-platform-core by yecli 5 years ago
- #123 Support module nested references loading in Platform modular system. (#124) * - Added tests for module assembly loading; - Used PluginLoader for this; * #123 Support module nested references... — committed to VirtoCommerce/vc-platform-core by yecli 5 years ago
- Ajuste na versão dos pacotes System.ServiceModel para evitar o problema descrito em https://github.com/dotnet/wcf/issues/2349 — committed to GRMagic/Sefaz by GRMagic 8 months ago
4.5.0 packages all have “win” RIDs now as well as “win7” RIDs for netstandard2.0 and netstandard1.3 respectively.
Workaround add this to your build process
For anyone struggling with this: In the process of upgrading .NET Framework Webjobs to .NET Core 3.1 I faced this issue. I was on 4.4.0 versions of System.ServiceModel packages. Upgrading til 4.7.0 fixed this problem.
please use RID. I know win7-64 works. Portable RID will not work
dotnet publish -c Release -r win7-x64 --self-contained true
@ehsansajjad465 the System.Private.ServiceModel assembly version 4.1.2.4 was shipped in WCF packages version 4.4.4 which was a .NET Core 2.0 servicing release.
This issue was fixed with the WCF packages version 4.5.0 which was part of the .NET Core 2.1 release.
So you need to update your WCF packages to the 4.5.0 version or newer. I would recommend at least the latest version released from our 2.1 branch if not our just released 3.0 packages.
Hi @nero120 while this is an RID issue it isn’t with our WCF packages. We do the correct thing based on the .NET Core supported RID’s runtime.json file.
The issue is with the Azure Function app, there is an active issue with lots of details regarding this problem.
https://github.com/Azure/azure-functions-host/issues/3568