Breaking change - GetEnvironmentVariable / GetEnvironmentVariables treatment of empty string variables

[flakey-bit]

Description

I've noticed that the treatment of empty string environment variables appears to have changed between .NET7 and .NET8 on Linux

• Assuming the environment variable My__Variable__name was set to an empty string in the shell and exported
• Under .NET7 Environment.GetEnvironmentVariable("My__Variable__name") was returning null
• Under .NET8 Environment.GetEnvironmentVariable("My__Variable__name") is returning an empty string

I couldn't see this listed under the breaking changes section.

Reproduction Steps

export My__Variable__name=""

Environment.GetEnvironmentVariable("My__Variable__name");

Expected behavior

Perhaps the behaviour change is deliberate, but it should probably be called out

Actual behavior

?

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[flakey-bit]

Possibly relates to #50554

[flakey-bit]

I guess this "could" be due to the debian base image changing between mcr.microsoft.com/dotnet/sdk:8.0 and mcr.microsoft.com/dotnet/sdk:7.0

However I'd have thought an empty string environment variable is an empty string environment variable

Before invoking the .NET process we're logging

printf %s "$My__Variable__name" | od -vtc -to1

and it outputs

0000000

[jkotas]

Under .NET7 Environment.GetEnvironmentVariable("My__Variable__name") was returning null

It does not repro for me. Here is transcript of what I have done to reproduce it:

C:\>docker run -it mcr.microsoft.com/dotnet/sdk:7.0
root@08f300bf3cee:/# dotnet new console -o test
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring /test/test.csproj:
  Determining projects to restore...
  Restored /test/test.csproj (in 87 ms).
Restore succeeded.


root@08f300bf3cee:/# cd test/
root@08f300bf3cee:/test# echo "Console.WriteLine(Environment.GetEnvironmentVariable(\"My__Variable__name\") is null);" > Program.cs
root@08f300bf3cee:/test# dotnet build
MSBuild version 17.7.6+77d58ec69 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  test -> /test/bin/Debug/net7.0/test.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:03.16
root@08f300bf3cee:/test# /test/bin/Debug/net7.0/test
True
root@08f300bf3cee:/test# export My__Variable__name=""
root@08f300bf3cee:/test# /test/bin/Debug/net7.0/test
False
root@08f300bf3cee:/test# exit
exit

[jkotas]

Could you please share exact repro steps?

[dotnet-policy-service]

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

[flakey-bit]

@jkotas thanks very much for your time already spent looking into this.

While I can reproduce the issue on my CI server (JetBrains TeamCity), I'm unable to reproduce it locally/with a docker image and I've given up in my attempts to do so.

Apologies for not doing the leg-work initially 💚& thus taking your time.

Have ended up amending the shell script to avoid creating empty variables.

[jkotas]

CI server (JetBrains TeamCity),

What is the distro that this CI server runs on?

It is possible that there may be a bug that repros on some Linux distros only.

[flakey-bit]

What is the distro that this CI server runs on?
It is possible that there may be a bug that repros on some Linux distros only.

The build step is running within the dotnet SDK docker image (mcr.microsoft.com/dotnet/sdk:7.0 or mcr.microsoft.com/dotnet/sdk:8.0 respectively)

The build agents are probably running on a variety of Linux distros. If you think the underlying Linux distro could be relevant, I can look into it.