Reputation: 1221
I have a .NET Core console app with target netcoreapp2.1. It calls into an existing WCF service using the Windows Compatibility Pack.
When I run it through Visual Studio, or if I use dotnet run
to run it from the command line, it works fine.
However, I want to publish it to a .exe file so that I can run it by double-clicking it.
So, I ran the Publish which appears to succeed, but when I try to run the published .exe file it fails with the following exception:
System.IO.FileNotFoundException: Could not load file or assembly
'System.Private.ServiceModel, Version=4.1.2.1, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
This error happens on the machine that I ran the publish on, and also if I try copying the published folder to another machine. I believe that System.Private.ServiceModel
is some sort of deep dependency of the Microsoft.Windows.Compatibility
package, but why is this not working? Surely it should have been copied to the output folder automatically?
Is there additional configuration or setup required to get the publish to pull in dependencies automatically?
If it matters, the reference in the csproj file looks like this:
<ItemGroup>
<PackageReference Include="Microsoft.Windows.Compatibility" Version="2.0.1" />
</ItemGroup>
Upvotes: 8
Views: 4708
Reputation: 17908
I found out that this was caused by PrivateAssets="All"
in one of my packages:
<PackageReference Include="ULabs.VBulletinEntity" Version="0.7.17" />
Background: ULabs.VBulletinEntity
itself refers to some shared library, that should be automatically shipped without installing a second package. So I tried this workaround, which recommends PrivateAssets="All"
to integrate the shared library.
This works, but when deploying to Linux, the package was not present after dotnet restore
. This leads to the FileNotFound exception after starting the application. Since I don't get any error, I tried installing it manually using
RUN dotnet add package ULabs.VBulletinEntity --version -s my-baget-repo
which gave me at least an error:
error: Package 'ULabs.VBulletinEntity' is incompatible with 'all' frameworks in project '/app/MyApp/MyApp.csproj'.
The error message doesn't have me any usefull information. Mostly they used another version (e.g. .NET Core 2.0 lib in a 3.0 project). In the other case, it seems some kind of wired bug.
After removing the PrivateAssets="All"
, the package was present in the publish output and I could start the application again. It seems strange for me, but maybe this same someone time. I wasted a few hours with this problem. Used .NET Core 2.1 and .NET Standard 2.0 for the lib.
Upvotes: 0
Reputation: 24459
Looking at the related GitHub issues*, people seem to have varying mileage with suggested workarounds.
What worked for me was copying the DLL from the runtime folder, to the bin folder, after build, by adding this to my Azure Function app csproj:
<!-- https://github.com/dotnet/wcf/issues/2824 -->
<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>
Other workarounds include installing the System.Private.ServiceModel
package directly, or increasing version of System.ServiceModel to 4.5.3, neither of which worked for me.
*
https://github.com/dotnet/wcf/issues/2824
https://github.com/Azure/azure-functions-host/issues/4304
https://github.com/Azure/azure-functions-host/issues/3568#issuecomment-433146109
https://github.com/dotnet/wcf/issues/2349
Upvotes: 2
Reputation: 541
Add in vsstudio nuget package
Install-Package System.Private.ServiceModel
Now when you publish dll will be included.
Upvotes: 0
Reputation: 4138
I had the same problem and I've manually added from nuget the missing file by installing the System.Private.ServiceModel
package.
This is a hack though, because from the description of the package you can see that it's meant for .Net internal usage, but I didn't find any other options.
Upvotes: 2