HL7.Fhir.R4 can't be loaded as a plug-in

[jhudsoncedaron]

This kind of problem doesn't have a short reproduction.

When code is to be loaded dynamically we don't get a correct reference to the package.

Web server csproj fragment:

   <ItemGroup>
       <ProjectReference Include="../Repository/Repository.csproj">
         <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
         <OutputItemType>Content</OutputItemType>
         <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
         <Targets>Build;DebugSymbolsProjectOutputGroup</Targets>
       </ProjectReference>
       <ProjectReference Include="../ApplicationServer/ApplicationServer.csproj">
         <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
         <OutputItemType>Content</OutputItemType>
         <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
         <Targets>Build;DebugSymbolsProjectOutputGroup</Targets>
       </ProjectReference>
   </ItemGroup>

What this does is in development (while reading appsetting.Development.json which overrides dependency injection), loads the application server into the web server, bypassing the normal stack where they would be in separate processes. ProjectReferences are copied to output, but PackageReferences aren't. They are expected to be resolved from the .nuget directory at runtime. That's just how dotnet build works.

The application server needs to have:

  <ItemGroup>
    <PackageReference Include="Hl7.Fhir.R4" Version="4.3.0" />
  </ItemGroup>

This builds, packages, etc; everything seems normal. But it doesn't run. On trying to access any Fhir code, the dynamic resolver gets "I want Hl7.Fhir.R4.Core, version 4.3.0" But the package name is "Hl7.Fhir.R4" so it doesn't resolve. The assembly resolving is declared as public event Func<AssemblyLoadContext, AssemblyName, Assembly?>? Resolving: the package name is long gone.

The code runs if linked directly into the web server, but that's exactly what we need to not do.

I have looked into solutions to this problem; and there just aren't solutions that handle the development environment very well. I can at package time dynamically construct an HL7.Fhir.R4.Core package to ship because that would only read from the shippeed nuget directory; but that does me no good at development.

Just fixing the package name doesn't fix the problem because Newtonsoft.Json has essentially the same issue only it's package version vs dll version rather than package name vs. dll name. This has lead to us removing almost all references to Newtonsoft.Json (there's one left in the web server itself but that one must inherently be statically loaded so it's not a problem).

[ewoutkramer]

What is it that you want us to do here? It does not seem to be a specific .NET FHIR SDK problem, as you highlight with NewtonSoft. The good news is that in the current release (since 5.x), the package name is actually Hl7.Fhir.R4, there is no .Core anymore. Maybe that helps?

[jhudsoncedaron]

These are in fact the only two packages I have encountered with this problem. :(

I'm in a bad spot because what I believe ought to be the solution (force override package with a locally compiled package) doesn't work because the .NET tooling doesn't support it. The answer I got from the .NET team was suffix the version name with +local; which doesn't work for the obvious reason of +local can't be written to AssemblyName.

Getting rid of the .Core does resolve half of it. If Newtonsoft could be replaced with System.Text.Json the problem would go away altogether, but that's a lot of work. There's a fundamental disagreement; Newtonsoft.Json wants its input in strings and System.Text.Json wants its input in byte arrays. I keep on wondering if there's some other solution I just haven't thought of that would be more reasonable.

In fact both packages are noncompliant in different ways with the JSON spec and I'm wondering how long before it blows up in your face because somebody sent JSON in UTF-16 when implementing FHIR. (HttpClient.GetAsStringAsync() would definitely return a garbled string...); but that's a completely different issue.

[mmsmits]

We really don't know your problem statement and thus how to solve this. I'm really sorry.
If you come by a solution, please supply a PR for a fix, we will definitely take it under consideration.

For you second issue:
FHIR is always UTF-8 by design. https://www.hl7.org/fhir/json.html (The character encoding is always UTF-8)