Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Environment variables for .NET Framework 4.7.2 set on a run basis rather than on a project root folder basis #69

Closed
Chunwol opened this issue Mar 4, 2022 · 7 comments · Fixed by #72

Comments

@Chunwol
Copy link

Chunwol commented Mar 4, 2022

I'm not using NET Core, I'm developing using NET Framework 4.7.2.

The project is using a function called Directory.GetCurrentDirectory() to find the root folder.

NET Framework, the function finds the location where the project was launched, not the root folder of the project.

Because of this, the path changes depending on the execution environment, and when you build with IIS Express in Visual Studio 2022, the root folder is applied as "C:\Program Files\IIS Express" rather than the project folder.

Because of this, putting ".env" in the project root folder doesn't work.

This issue was in the past "dotnet/aspnetcore#4206" and was fixed in Net Core but not in Net Framework.

According to what I checked on https://stackoverflow.com/a/53655514, in NET Framework, you should use System.AppContext.BaseDirectory instead of System.IO.Directory.GetCurrentDirectory() to work properly. At this time, I confirmed that it normally finds the project root folder.

@Chunwol
Copy link
Author

Chunwol commented Mar 4, 2022

Fortunately, it can be used in Net Framework by temporarily using it as follows.

using (Stream stream = File.OpenRead($"{System.AppContext.BaseDirectory}.env"))
{
            DotNetEnv.Env.Load(stream);
 }

@MrDave1999
Copy link
Contributor

But this error only occurs when using ASP.NET with .NET Framework? Because I just tested the Directory.GetCurrentDirectory() method in a console application with .NET Framework 4.7.2 and it does return the correct path.

I just tested that the System.AppContext.BaseDirectory property also works in .NET Core.

I am not so sure but I think the solution would be to remove GetCurrentDirectory method and replace it with AppContext.BaseDirectory property:

if (dir == null || dir == string.Empty) dir = Directory.GetCurrentDirectory();

@rogusdev
Copy link
Collaborator

rogusdev commented Mar 8, 2022

I'll take a PR for it if that is all it takes

@Chunwol
Copy link
Author

Chunwol commented Mar 10, 2022

It seems to happen when using ASP.net together.
"https://docs.microsoft.com/en-us/dotnet/api/system.appcontext.basedirectory"
When I checked, the function supports most versions and it normally loads the default directory file path, so it would be better to change it to the corresponding function.

@Chunwol
Copy link
Author

Chunwol commented Mar 10, 2022

When using xamarin-android, there is an issue that the function returns NULL. I can't write in detail because I don't have time right now, but if you check the attached issue, there is a solution.

[xamarin-android](dotnet/android#3489)

@joostmeijles
Copy link

Having the same problem with a ASP.Net Core and Console application within the same solution that uses 1 common .env file.

Using DotNetEnv.Env.TraversePath().Load(); as workaround for now in the ASP.NET project.

@rogusdev
Copy link
Collaborator

I did make this change as it sounds appropriate (I can imagine an app changing the current directory before loading this and ending up in the wrong place anyway). That said, if at any time anyone feels that they want the old behavior, or are having trouble, this is already quite easy to work around, since the first arg to Load is a file path -- relative or absolute. So just do this: DotNetEnv.Env.Load($"{Directory.GetCurrentDirectory()}.env") (or whatever your .env file should be called) and that should give you the old behavior back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants