Add
<RuntimeIdentifier>win10-x86</RuntimeIdentifier>
and
<PackageReference Include="Microsoft.Extensions.ApiDescription.Server" Version="$(MicrosoftExtensionsApiDescriptionServerVersion)" />
and then build. "An error occurred while loading required library hostpolicy.dll from " appear.
If comment out or remove RuntimeIdentifier then build would succeed.
error : Failed to load the dll from [ProjectName\bin\Debug\netcoreapp3.0\win10-x86\hostpolicy.dll], HRESULT: 0x800700C1
error : An error occurred while loading required library hostpolicy.dll from [ProjectName\bin\Debug\netcoreapp3.0\win10-x86\]
I try with Preview 8 and 3.0.0-preview9.19417.2
Seems to work for me like this (no runtime id in the project):
dotnet publish -c Release -r win-x64 --self-contained
However fails with the hostpolicy error when using -r linux-x64
It maybe the case for me as well. I may run build on Mac, but with -r win10-x86
@ryanbrandenburg is this a dupe of the referenced issue you're looking at?
Actually no, the referenced issue is MacOS specific.
The problem here isn't that you specified a RuntimeIdentifier, it's that you've specified an x86 RID while running an x64 version of dotnet. When the process is launched to generate the document it needs to load in your project, and when you provide an x86 RID it can't do that because it's expecting x64. This is essentially the same thing as https://github.com/aspnet/EntityFrameworkCore/issues/16054 (Since we use the same process as EF). I don't know at this time what to solution would be for x86 (would have to consult with the EF folks), but one mitigation would to either not specify a RID or make sure the RID you specify is x64. Will that work in your case?
Removing property from project file make sense yo me. It was not explicitly understandable, that all tooling running with same properties as specified by project file, and not host system. But I can live with that. Maybe that should be mentioned somewhere in the docs. It was confusing initially.
@mkArtakMSFT I propose moving this to the Backlog. This only matters in a bit of an edge case (mixing x86 and x64), there are some workarounds, and the identical bug on the EF side is also in the backlog.
Let's do that and monitor this there.
Seems like adding this property fixes the build
<PropertyGroup>
<OpenApiGenerateDocumentsOnBuild>false</OpenApiGenerateDocumentsOnBuild>
</PropertyGroup>
By the way, this bug is not only related to runtime identifies but also for multi-targeting too. For example, with this configuration:
<TargetFrameworks>netstandard2.0;netcoreapp3.0</TargetFrameworks>
@inech you may be mixing something unrelated into this issue about bitness. The <OpenApiGenerateDocumentsOnBuild>false</OpenApiGenerateDocumentsOnBuild> setting just disables OpenAPI document generation on build. That's fine if you don't need the document(s) but may be hiding something.
Is your scenario identical to @kant2002's mixed x86 / x64 case? And do you see the same error messages on build? If not, please open a new issue describing your problem.
Also of note for anyone running into this, when I was testing this locally I was able to "fix it" by changing RuntimeIdentifier to RuntimeIdentifiers, even when I didn't provide more than one RID.
Thanks for interesting hint. Does that means that command dotnet tool use
RuntimeIdentifier (or specifically ProjectName.deps.json) of the project
when run and do not use when project have RuntimeIdentifiers . Can this
rule be applied to all global/local tools, or this is something swagger
generation specific?
On Thu, Oct 24, 2019 at 00:59 Ryan Brandenburg notifications@github.com
wrote:
Also of note for anyone running into this, when I was testing this locally
I was able to "fix it" by changing RuntimeIdentifier to RuntimeIdentifiers,
even when I didn't provide more than one RID.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore/issues/13245?email_source=notifications&email_token=ABAPKN3U4F5AV7VXWHDFDP3QQDCK7A5CNFSM4IMV2DHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECDAGNI#issuecomment-545653557,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABAPKN7NVRYFGHGXYW7SQ3TQQDCK7ANCNFSM4IMV2DHA
.
Most helpful comment
By the way, this bug is not only related to runtime identifies but also for multi-targeting too. For example, with this configuration: