PublishTrimmed with Oracle.ManagedDataAccess.Core causes FileNotFoundException at runtime

[SIkebe]

Steps to repro.

1. mkdir Trimmed && cd Trimmed
2. dotnet new console
3. dotnet add package Oracle.ManagedDataAccess.Core --version 2.19.60
4. Replace Program.cs with the following code.

     using System;
     using Oracle.ManagedDataAccess.Client;
   
     namespace Trimmed
     {
         class Program
         {
             static void Main(string[] args)
             {
                 string connectionString = "connection string for Oracle DB";
   
                 using (OracleConnection con = new OracleConnection(connectionString))
                 {
                     using (OracleCommand cmd = con.CreateCommand())
                     {
                         try
                         {
                             con.Open();
                             cmd.BindByName = true;
                             cmd.CommandText = "select id from test_table where id = :id";
                             OracleParameter id = new OracleParameter("id", "test");
                             cmd.Parameters.Add(id);
   
                             OracleDataReader reader = cmd.ExecuteReader();
                             while (reader.Read())
                             {
                                 Console.WriteLine("id: " + reader.GetString(0));
                             }
   
                             Console.WriteLine();
                             Console.WriteLine("Press 'Enter' to continue");
   
                             reader.Dispose();
                         }
                         catch (Exception ex)
                         {
                             Console.WriteLine(ex);
                         }
                         Console.ReadLine();
                     }
                 }
             }
         }
     }

5. dotnet publish -c Release --runtime win-x64 /p:PublishTrimmed=true
6. .\bin\Release\netcoreapp3.1\win-x64\publish\Trimmed.exe

Error

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.TypeInitializationException: The type initializer for 'OracleInternal.ServiceObjects.OracleConnectionImpl' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'Oracle.ManagedDataAccess.Types.TimeStamp' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'System.Runtime.Serialization.Formatters.Binary.Converter' threw an exception.
 ---> System.IO.FileNotFoundException: Could not load file or assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. 指定されたファイルが見つかりません。
File name: 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, RuntimeAssembly assemblyContext, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, AssemblyLoadContext assemblyLoadContext)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext)
   at System.Reflection.Assembly.Load(String assemblyString)
   at System.Runtime.Serialization.Formatters.Binary.Converter..cctor()


   --- End of inner exception stack trace ---
   at OracleInternal.Common.OracleTimeZone.GetInstance()
   at Oracle.ManagedDataAccess.Types.TimeStamp..cctor()
   --- End of inner exception stack trace ---
   at Oracle.ManagedDataAccess.Types.TimeStamp.InitializelatestTZversion()
   at OracleInternal.ServiceObjects.OracleConnectionImpl..cctor()
   --- End of inner exception stack trace ---
   at OracleInternal.ServiceObjects.OracleConnectionImpl..ctor()
   --- End of inner exception stack trace ---
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean wrapExceptions, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& hasNoDefaultCtor)
   at System.RuntimeType.CreateInstanceDefaultCtorSlow(Boolean publicOnly, Boolean wrapExceptions, Boolean fillCache)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, Boolean wrapExceptions)
   at System.Activator.CreateInstance[T]()
   at OracleInternal.ConnectionPool.PoolManager`3.CreateNewPR(Int32 reqCount, Boolean bForPoolPopulation, ConnectionString csWithDiffOrNewPwd, OracleConnection connRefForCriteria, String instanceName, List`1 switchFailedInstNames)
   at OracleInternal.ConnectionPool.PoolManager`3.Get(ConnectionString csWithDiffOrNewPwd, Boolean bGetForApp, OracleConnection connRefForCriteria, String affinityInstanceName, Boolean bForceMatch)
   at OracleInternal.ConnectionPool.OraclePoolManager.Get(ConnectionString csWithNewPassword, Boolean bGetForApp, OracleConnection connRefForCriteria, String affinityInstanceName, Boolean bForceMatch)      
   at OracleInternal.ConnectionPool.OracleConnectionDispenser`3.Get(ConnectionString cs, PM conPM, ConnectionString pmCS, SecureString securedPassword, SecureString securedProxyPassword, OracleConnection connRefForCriteria)
   at Oracle.ManagedDataAccess.Client.OracleConnection.Open()
   at Trimmed.Program.Main(String[] args)

[SIkebe]

.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Oracle.ManagedDataAccess.Core" Version="2.19.60" />
  </ItemGroup>

</Project>

[alexkeh]

What resolution are you seeking for this problem?

This error can be expected behavior with assembly trimming. Microsoft documents the following:
"It's important to consider that applications or frameworks (including ASP.NET Core and WPF) that use reflection or related dynamic features, will often break when trimmed. This breakage occurs because the linker doesn't know about this dynamic behavior and can't determine which framework types are required for reflection. The IL Linker tool can be configured to be aware of this scenario."

[SIkebe]

Yeah, it's an expected behavior. But you have a workaround. Microsoft also saids,

To trim such apps, you need to tell the linker about any types needed by reflection in your code
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/

So I added below ItemGroup to .csproj file, then the simple select SQL statement just worked.

<ItemGroup>
  <TrimmerRootAssembly Include="mscorlib" />
</ItemGroup>

I'd like to know official guidance in the Trimming scenario like this. Is this configuration enough? Or under more complex scenario, do you have to exclude more types?
Publishing single-file executables and Assembly linking give a lot of benefits for us, so it would be great if there are some documentation from Oracle.

[alexkeh]

I don't have any immediate guidance. We'll take a look at it and ask Microsoft if they have any guidance for third-party products.

[SIkebe]

@alexkeh Thanks! If I can find something else, I'd share here.

[jods4]

@alexkeh Please re-open this, Microsoft has all the guidance you need. Took me 2min of Googling to find it out.

It is easy to see here that it's the reliance on BinaryFormatter (in OracleTimeZone) that is failing to load mscorlib, Version=4.0.0.0.
This incompatibility is known, see dotnet/linker#1569 for a report to MS.

The guidance of MS is clear. BinaryFormatter is obsolete in .net 5, should be avoided and will be removed in a future version. It is probably never gonna be compatible with trimming.
https://docs.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide
https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/binaryformatter-obsoletion.md

The message to everyone (esp. ISV) is: get rid of it. That's something Oracle can (and should) act upon.

Doesn't mean there won't be another trimming-related problem, but this one will be out of the way and we can explore further.

As a end-user there's no work-around that I know of, so you're blocking us if you don't act on this bug report.

[jods4]

BTW if you do reflection in ODP.NET and want to make it link-trimmable and keep the reflected members, there's this blog post by a MS employee that points at attributes you could use to make it work:
https://devblogs.microsoft.com/dotnet/customizing-trimming-in-net-core-5/

If you get rid of BinaryFormatter, assembly-trimmable should work, it's a mode that's not expected to create issues.

[jods4]

@alexkeh @SIkebe Great news, I made it work.
You can trim the project if you add this to your csproj:

<TrimmerRootAssembly Include="mscorlib" Version="4.0.0.0"/> 

The key here is to add Version (which I haven't seen documented, but hey it works).

The linker emits a ton of warnings because of duplicated core system stuff.
I'm guessing that's because we have both mscorlib 5 and 4 in our build and that's probably not great.

The end result works nonetheless. In our basic tests we even had no problem with link trimming mode.

Still hoping Oracle will publish a cleaner version.

[alexkeh]

@jods4 That's great you found a solution!

One thing to keep in mind is that the discussion on ODP.NET assembly trimming in this issue between @SIkebe and I happened about a year ago was focused on .NET Core 3.x functionality prior to much of the new guidance and functionality MS added for .NET 5.

From my initial perusal of .NET 5 assembly trimming guidance, it appears focused on the end developer. There's not much info about what third-party apps should do. Developers can potentially use third-party apps in a myriad of ways that may or may not use other .NET assemblies and/or other third-party software.

Are you aware of any guidance that SqlClient or the PostgreSQL provider has in this area? MS employees develop both these providers for .NET Core. The ODP.NET team could use both/either as a model to start with. I'll reach out to the my MS .NET team myself after the holiday.

With respect to BinaryFormatter, an ODP.NET bug has been filed and we are investigating. The fix is not completely straightforward and may have performance implications.

[jods4]

@alexkeh I am not aware of any recommandation from SQL team.

As far as my understanding of trimming goes, I'd say the same guidelines that apply to end-developer would apply to ISV.

1. There's a list of things that don't work in single-file publish, mostly revolving around accessing your assembly base path or file.
   There's no "work-around" other than replacing the code with an alternative that doesn't use these APIs.
   Since ODP.NET works for me, I conclude you don't do that (and I don't see why you would).

2. The "safe" assembly-trimming mode is based on referenced assemblies.
   As long as you don't load an assembly dynamically there's no issue.
   If you wanted to do that, I think you'd have to document a <TrimmerRootAssembly> that end-developers must add to their build.
   BinaryFormatter aside, works for me, so I don't think you do that (and again I don't see why you would).

3. The link-trimming mode is based on static code analysis, to find types and members that are actually used.
   End-developers will encounter issues if ODP.NET performs some non-statically typed code, e.g. by reflection, runtime emitted code, or using dynamic.
   This can be done but you'd need to use attributes as described in the blog post above to make the linker aware of the dynamically accessed members.
   Again, works for me, so the commonly used codepaths don't seem to be concerned by that.

It looks to me like you're very close to trimming-friendly.
That pesky BinaryFormatter is the main roadblock, at least for my basic usage so far.

[jods4]

Good news everyone.
After seeing Oracle tweet about 2.19.101 saying "BinaryFormatter issues are resolved", I gave it a try.

It looks like you can now publish link-trimmed self-contained .net core applications without referencing mscorlib 4.0.0.0 and it works. 🎉