How do you access application solution folder without hardcoding?

Question

Working in C# in Visual Community 2013, coding for Desktop only.
In WinForms and WFP, you can open a stream to write to a file without any directory (Streamwriter ("test.txt")) and the file would get saved in the directory the executable is in, generally the \bin\debug folder under wherever you saved
your solution.
Working with Store Apps, how do you mimic that behavior without using hard coded paths or manually navigating to the directory via a FolderPicker or FilePicker?  I can find ways (e.g. KnownFolders) to create an IStorageFile reference to the Pictures
Library, or the Video Library... or if I really want to drive myself nuts, I can go with ApplicationData.Current.LocalFolder and it's Roaming variant, which point to an \User\Name\AppData\Local\Package\DJHAH-JHFDS-FDSFS-FDSFD\...\LocalState directory structure around
10 levels deep... not my preference either.  Oh and I understand you used to be able to use the Documents Library (not that I want to, but it'd be better than any of the other options I've found) but even that isn't easily accessible anymore,
despite still being found under KnownFolders, if I've understand what I've been reading correctly.
I can't seem to pass anything like "." or ".\text.txt" to CreateFileAsync(), for the record.  And I've hunted randomly around the .NET classes, but nothing is being helpful.
Short version:  what namespace.class.property stores a usable IStorageFolder reference to the folder where the currently running executable is located?
An example bit of code that would open up a write stream to a file wherever the solution executable is, and how to capture the path to a string so it could be later passed to OpenAsync() again, would be fantastic.
Thanks for any help.

Answer 1

Thank you kindly, that is indeed very helpful, and yes, it confirms what I'd read earlier that as an indie developer I can't use the Documents folder.  I do have a bit of a follow up question, though... probably no one will see it as I've marked this
question as answered, so I may start a new thread for it if I don't see a reply in a few days.
I get the Sandbox concept, it just seems overrestrictive here.  A simple example is, I make a game which generates save game files.  As anyone who's played Steam games can tell you, one can generally uninstall the game *without* blowing away
your saved games.  I'm not sure how one could employ this concept as an indie game developer however, without using something completely unintuitive like saving save game files to the Video, Pictures or Music libraries, or without forcing the user to
use FolderPickers or FilePickers every save.   If I use the Local data folder, per your source "The folder will be completely erased if the app is uninstalled." Is there any workaround for this situation? What's the conventional method
most people use? FolderPickers and FilePickers every save?  Save games in Video?
Yes, this can be done.  There are 2 options you have.
Options:
(1) First time your user runs your game, you can ask the user to choose a folder to store the saved games, data, and whatever else.  Then you would save this location that the user chooses in the futureaccesslist.
(2) Save the data in the roaming folder of the app.  The data in this folder gets synced to the cloud and stays there for future use.  So, even if the user uninstalls the game and then later reinstalls the game, the data from this folder would
still be there because it was saved in the cloud.
I highly recommend you use option 1.  I can think of several situations where option 2 would pose a problem. 
Regarding the windows sandbox, trust me I was annoyed by the limitations at first, too.  But once you get used to it, it's actually quite nice.  There are always ways to get around certain limitations.  You just need to spend time looking
for them.  For example, one of my apps is a word processor.  My users really wanted the ability to export their documents to pdf.  This was easy to do in wpf and there were plenty of libraries for it.  But in metro, certain limitations
made the old methods impossible.  It took me 3 months to finally get it working.  Once it worked, the sky is the limit. 
The limitations are there for everyone's benefits whether they know it or not.