1

I'm trying to run my .net core web api service from the .net CLI. My solution is build with vs2022 to the path:

C:\myProject\Bin

When I try to use the

dotnet myService.dll

command, I see that it is executed from the path:

C:\Program Files\dotnet

But when this is the working directory, my service can't find referenced projects that are built to my "C:\myProject\Bin" folder.

When I run my service using VS2022, It runs from the correct folder and finds all the references that it needs.

What am i doing wrong?
can I make the

dotnet myService.dll

command run from the proper directory?

Stack Stalker
  • 27
  • 5
  • I never use working directories for that kind of thing, and absolutely not in services. You can use the path of the myService.dll – Bent Tranberg Feb 01 '22 at 14:45
  • 1
    Appears to be [a long-standing bug](https://github.com/dotnet/project-system/issues/3619). Try `Start-Process dotnet -Argumentlist "C:\myProject\Bin\myService.dll" -WorkingDirectory "C:\myProject\Bin" -Wait` from PowerShell – Mathias R. Jessen Feb 01 '22 at 14:48
  • @BentTranberg many .net apps have an appsettings file next to them. How would you go about loading it? – Good Night Nerd Pride Feb 01 '22 at 14:48
  • https://stackoverflow.com/questions/864484/getting-the-path-of-the-current-assembly – Bent Tranberg Feb 01 '22 at 14:49
  • @BentTranberg I'm running the dotnet command from the service's path and still it uses c:\program files\dotnet – Stack Stalker Feb 01 '22 at 14:49
  • @BentTranberg a bit clunky, but definitely a useful solution for appesettings. But how about referenced assemblies next to the entry point dll? Please don't say adding a handler to the [`AppDomain.AssemblyResolve` event](https://learn.microsoft.com/en-us/dotnet/api/system.appdomain.assemblyresolve?view=net-6.0) and doing the same there. – Good Night Nerd Pride Feb 01 '22 at 14:54
  • Right, but why are you interested in the current working directory? You never know what the system might give your service as working directory, and you never know what the users will give your applications as working directory. I have a feeling you don't understand what the working directories are. They do not point to your applications. You wrote that you want paths relative to the placement of that DLL. So look at the link I posted. (Answering the one two steps above.) – Bent Tranberg Feb 01 '22 at 14:54
  • There are lots of ways to get paths. Path to the entry assembly, currently executing assembly, a specific assembly. For an application, there are several ways to find the path to the executable. – Bent Tranberg Feb 01 '22 at 14:57
  • About the current working directory (and the working directories for each disk). These belong to the user. Not the application. This is where the user wants file open dialogs to open, and save dialogs to save. Some applications should allow the user to change the current working directory, e.g. by navigating with file open/save or directory dialogs. The current working directory for an application is frequently left to be some default, which is usually where the executable is. Unfortunately this gives many developers the wrong idea - that this is the path to the executable. It is not. – Bent Tranberg Feb 01 '22 at 15:04
  • About that link to an issue posted far above - it just leads to your discovery that the current directory is not always where your application's executables are. That issue is not the problem in your case. Applications or services that look for deployment files placed alongside executables via the current directory are likely to fail at some point. – Bent Tranberg Feb 01 '22 at 15:17
  • @BentTranberg this actually is my problem. I don't need to reference the working directory in my code. I have multiple dlls which load in reflection. I Placed them in the directory of my service, so it can find and load them. – Stack Stalker Feb 01 '22 at 18:39
  • Doesn't that mean that somewhere in your code you use the file names of these dlls, and possibly even a path? Are these paths absolute or relative? (If they are absolute, you must already be calculating them.) If they are relative, that means they are relative to the current working directory, which will sometimes fail. If you want them to be relative to the myService.dll instead, then you have to calculate that path. Perhaps you can let us know the path - the exact string - currently used when loading a dll that is not found. Also any code that calculates the path - maybe just a string. – Bent Tranberg Feb 01 '22 at 19:15
  • Digging a bit into the issue, I do acknowledge that it is a problem with the current directory being in the wrong place for a .net core web API service, because web services tend to rely on the working directory. So fixing that issue will likely also fix this issue with loading dlls. But loading dlls should not use the current working directory. Anyway, I suggest you simply set the current working directory at startup, so that you override what any application starter is doing wrong. As a first test you can just hardcode an absolute path to verify that it works. Then refine with some logic. – Bent Tranberg Feb 01 '22 at 19:34

0 Answers0