You'll note here that you get the behavior you expect with each call. Runtime Call C:\Users\scott\Desktop\testdir\bin\Debug\net5.0\win-圆4\publish Physical location C:\Users\scott\Desktop\testdir\bin\Debug\net5.0\win-圆4\publish\ĪppContext.BaseDir C:\Users\scott\Desktop\testdir\bin\Debug\net5.0\win-圆4\publish\ NET 5 as a single EXE and unfolding directly into memory (no temp files): Launched from C:\Users\scott\Desktop NET 3.1 temp file behavior, you can use a compatibility property called IncludeAllContentInSingleFile. NOTE: There is some work happening on an analyzer that would flag weird usage when you're using Single File publish, so you won't have to remember any of this. Any use of Assembly.Location is going to be suspect.
NET Core 5 (> preview 7)? Well, because the assemblies are embedded and loaded from memory in 5, so like any other in-memory assembly, they don't have a location. You'll want to catch that at startup as it's not a super cheap call you want to make all the time.
Starting with your current process, then digging into the MainModules's filename, then getting that file's Directory. NET 3.1 if you want to get your "original birth location" you have to do a little runtime dance. Runtime Call C:\Users\scott\Desktop\testdir\bin\Debug\netcoreapp3.1\win-圆4\publish Physical location C:\Users\scott\AppData\Local\Temp\.net\testdir\30gxvy1b.yq3\ĪppContext.BaseDir C:\Users\scott\AppData\Local\Temp\.net\testdir\30gxvy1b.yq3\ \testdir\bin\Debug\netcoreapp3.1\win-圆4\publish\testdir.exe NET Core 3.1: using System Ĭonsole.WriteLine($"Launched from ") Īnd here's the output of this app when started from elsewhere. But how do you find this config file if you got started from a random temp folder?.That way you have two files next to each other and it's simple. If you have a config file like, you'd like the user to keep that file NEXT TO THE EXE.NET 3.1, the system "unzips" the app and its dependencies into a temp folder.
NET 3.1 LTS (long term support) has a cool feature where you can ship a single EXE with no dependencies. The app then attempts to load the config file from this temp directory, which obviously fails. Every method for finding the startup assembly's location I have found, either by googling or exploring with reflection while it runs, only gives me the location in the temp directory, not the one where the app was actually launched from. NET actually extracts the embedded DLL to some temporary location in my filesystem, then runs it from there. BUT, it seems that when I have the entire app built into a single EXE like this. (I think I got the idea from your blog btw, thanks! :) It is a simple app that does a single task, so I figure it should be one EXE, not 50 megabytes in 80 files.Īnd there the problem lies: If the config file is right next to the exe, I need to know where the exe is located. avoid going into other directories), so I want to store the config file right next to the executable.Īnd since I want it to be small and easily distributed, I set up. Unfortunately, it needs a single line of configuration (an API key), which store in a text file. NET Core 3 that is supposed to sit in your apps folder you have in your path, do something when you run it, then exit. The tl dr question: how do I find which directory the app was started in? So instead, I've email my new friend a link to this blog! Plus, every question that moves knowledge forward is a gift, and I don't want to ignore a gift. And while I could find the answer and email them back, I also have a limited number of keystrokes. I got a great question emailed to me today.
0 kommentar(er)
