0

While running my project using Visual Studio, the working directory (AppDomain.CurrentDomain.BaseDirectory) is {ProjectDirectoryPath}\bin\Debug\netcoreapp2.0; but while running the project from its publish folder (after publishing it), the working directory is {PublishDirectoryPath}. All project configuration and data files are located under {ProjectDirectoryPath} and {PublishDirectoryPath} in the same tree structure. What it means is that whenever I'm running the project using Visual Studio, I should prefix the path of each of the files with ../../../.

My current solution is using the following function whenever accessing a file in the project directory:

public static string Root()
{
    string root = AppDomain.CurrentDomain.BaseDirectory;
    if (root.EndsWith("Debug\\netcoreapp2.0\\"))
        root = root + Slash("../../..");
    return root;
}

However, it feels to me that there must be some better way to solve this, since using files located under the project directory is nothing unusual (though it's more common to store configuration and data files under %AppData% or /home). So it doesn't seem right that so many developers would really implement a solution like this to something so common.

What am I missing?

Lews Therin
  • 3,707
  • 2
  • 27
  • 53
Moon
  • 338
  • 2
  • 9

2 Answers2

0

Typically, any constants that your application is dependent on that could change are added to a web.config/app.config file; so that you don't need to recompile the code to change these values. An exception would be a service or library that would require consumers to provide the data via parameters.

When you store paths in a config file, you can use web.config/app.config transforms to change the values based on the build configurations. This allows you to supply different values to your config file settings based on the environment you deploy to.

Lews Therin
  • 3,707
  • 2
  • 27
  • 53
0

I posted this question after hours of research. Even after posting it I continued searching for a solution. I saw a lot of threads about this issue, and a lot of solutions that didn't work in my case. Now I stumbled across this, and I used the second approach. Using this solution it works.

It seems so bizarre to me that the access to something so basic would be so non-intuitive. Unfortunately, .NET Core is yet not mature enough.

Moon
  • 338
  • 2
  • 9