System.Data.Odbc OdbcFactory.Instance is null

[WonderGnagno]

Description

Hi, running a simple code in Linux environment I noticed that the var OdbcFactory.Instance is null. It happens if I publish the software setting as the target runtime to Portable. See image below.

If i set linux-x64 it works.

This problem happen only if I run on Linux enviroment.

Here my execution

Linux OS

Reproduction Steps

Solution1.zip

Expected behavior

OdbcFactory.Instance != null

Actual behavior

OdbcFactory.Instance == null

Regression?

No response

Known Workarounds

No response

Configuration

Which version of .NET is the code running on? .net core 6 What OS and version, and what distro if applicable? Oracle Linux Server release 8.6 What is the architecture (x64, x86, ARM, ARM64)? x64 Do you know whether it is specific to that configuration? publish target runtime portable

Other information

No response

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @roji, @ajcvickers See info in area-owners.md if you want to be subscribed.

Issue Details

---

### Description Hi, running a simple code in Linux environment I noticed that the var OdbcFactory.Instance is null. It happens if I publish the software setting as the target runtime to Portable. See image below.  If i set linux-x64 it works. This problem happen only if I run on Linux enviroment. Here my execution  Linux OS  ### Reproduction Steps [Solution1.zip](https://github.com/dotnet/runtime/files/10876147/Solution1.zip) ### Expected behavior OdbcFactory.Instance != null ### Actual behavior OdbcFactory.Instance == null ### Regression? _No response_ ### Known Workarounds _No response_ ### Configuration Which version of .NET is the code running on? .net core 6 What OS and version, and what distro if applicable? Oracle Linux Server release 8.6 What is the architecture (x64, x86, ARM, ARM64)? x64 Do you know whether it is specific to that configuration? publish target runtime portable ### Other information _No response_

Author:	WonderGnagno
Assignees:	-
Labels:	`untriaged`, `area-System.Data.Odbc`
Milestone:	-

[stephentoub]

This package has OS-specific implementations, e.g. package/runtimes/linux/lib/net6.0/System.Data.Odbc.dll is the Linux implementation. However, the general lib/net6.0/System.Data.Odbc.dll is a stub implementation. It sounds like this particular deployment configuration is picking up that stub implementation, because you're requesting portable assemblies but this package's "portable" assemblies are fake.

@ViktorHofer, what's the expected behavior here?

[SamMonoRT]

@WonderGnagno @ViktorHofer - can this be closed?

[ViktorHofer]

I must have missed this ping back in March last year. I will take a look later today or latest tomorrow.

[WonderGnagno]

Hi All, I resolved creating different distributions and not portable. I don't know if the issue is still present. We should have a look to .NET 8.

BR Enrico

[SamMonoRT]

Assigning to @ViktorHofer for tracking

[ViktorHofer]

From what I know (cc @ericstj to double check) the behavior is the following when it comes to rid specific assets:

Scenario 1: A project sets the RuntimeIdentifier/s property or it gets passed in from the CLI (manually or automatically)

1. When NuGet restores packages, it selects the nearest RID specific asset for the given RuntimeIdentifier
2. MSBuild then later uses that information (from project.assets.json) and copies those files to the app's output directory.
3. At run time, the host loads that assembly because it is referenced and located next to the app executable.

Scenario 2: A project doesn't specify the RuntimeIdentifier/s property and it also isn't passed in from the CLI

1. When NuGet restores packages, it finds all the assemblies (the lib/<tfm>/ and the runtimes/... assemblies) and lists them (in the project.assets.json file).
2. MSBuild then later copies all these assemblies to the app output directory. The assemblies from the runtimes folder are put into a runtimes/<RID>/ folder.
3. At run time, the host loads the nearest RID specific assembly from the runtimes subfolder. If it doesn't find one, it loads the RID agnostic assembly which is located next to the executable. That one in this case then is a PNSE throwing assembly (a dummy assembly).

In this scenario, the app might not specify a RID at build time or the host might not be able to resolve the RID at run time.

[ericstj]

Based on the screenshot shared this is a framework dependent app - so it should be scenario 2 above. @ViktorHofer your explanation is correct.

In this scenario, the app might not specify a RID at build time or the host might not be able to resolve the RID at run time.

Another case could be the RID for the host doesn't import the linux RID, so the app doesn't select the linux assets. This can often happen when running on a new distro or new version of a distro with some unmapped RID. In this case the repro says the OS is Oracle Linux Server release 8.6 - it's possible the RID used is not mapped. https://github.com/dotnet/runtime/blob/68438edabab1c2eb578d830112dd10752548a3b2/src/libraries/Microsoft.NETCore.Platforms/src/runtimeGroups.props#L140-L145

Checking the host logs around selecting the Odbc.dll on the repro system is the right next steps to diagnose this problem. Those should list which RID the host was using and which copy of each library it decided to use. https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#corehost_trace Yet another case could be the app was launched without a deps file, or the load was from a context that didn't use the deps file.

@WonderGnagno if you'd like us to help further, please share host traces on the OS that has the undesired behavior.

[dotnet-policy-service[bot]]

This issue has been marked needs-author-action and may be missing some important information.

[dotnet-policy-service[bot]]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[dotnet-policy-service[bot]]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.