locked
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.



    • Edited by Qwinn2015 Wednesday, January 07, 2015 8:27 AM
    Wednesday, January 07, 2015 7:35 AM

Answers

  • Okay, continued to research, and found this:

    Windows.ApplicationModel.Package.Current.InstalledLocation

    That returns my installed solution location + \bin\debug\AppX.  That would do.  But I can't write to it, I get an UnauthorizedAccess exception.

    So have I just basically discovered that the convention for all previous compilers known to me since the dawn of time (or, well, 1980, when I started programming), including all previous versions in Windows Visual Studio, which allowed solutions/projects to write to their own runtime directories, has been quietly removed as an option?  I *have* to either use Libraries (a mechanism I'm not particularly fond of) or the irritatingly long ApplicationData.Current.LocalFolder?

    If so, then please tell me how I regain the following lost functionality.  When doing development, I may frequently want to move my solution around from one location to another, or one device to another.  Previously I could just move the entire solution by copying and pasting the solution folder itself... as long as my data files were also in the folder, it seemed to carry everything necessary, it was all nice and self-contained, and any data files I had generated during my previous uses of the application would still be available upon using the application from its new location.  But now, any data generated from previous executions is completely separated from the solution itself, and would have to be moved manually (from a horribly long \User\Name\AppData path) to bring it along?  Is that correct?  Or am I missing something?


    Yeah, and back in the good old days malwares and viruses had free reign over everything.

    The new sandbox provides a much more secure system for both developers and users. 

    Here are the locations that you can write your test.txt file to.

    http://lunarfrog.com/blog/2012/05/21/winrt-folders-access/


    • Edited by RandyPete Wednesday, January 07, 2015 4:22 PM
    • Proposed as answer by Dave SmitsMVP Wednesday, January 07, 2015 6:35 PM
    • Marked as answer by Qwinn2015 Wednesday, January 07, 2015 7:42 PM
    Wednesday, January 07, 2015 4:15 PM

All replies

  • Okay, continued to research, and found this:

    Windows.ApplicationModel.Package.Current.InstalledLocation

    That returns my installed solution location + \bin\debug\AppX.  That would do.  But I can't write to it, I get an UnauthorizedAccess exception.

    So have I just basically discovered that the convention for all previous compilers known to me since the dawn of time (or, well, 1980, when I started programming), including all previous versions in Windows Visual Studio, which allowed solutions/projects to write to their own runtime directories, has been quietly removed as an option?  I *have* to either use Libraries (a mechanism I'm not particularly fond of) or the irritatingly long ApplicationData.Current.LocalFolder?

    If so, then please tell me how I regain the following lost functionality.  When doing development, I may frequently want to move my solution around from one location to another, or one device to another.  Previously I could just move the entire solution by copying and pasting the solution folder itself... as long as my data files were also in the folder, it seemed to carry everything necessary, it was all nice and self-contained, and any data files I had generated during my previous uses of the application would still be available upon using the application from its new location.  But now, any data generated from previous executions is completely separated from the solution itself, and would have to be moved manually (from a horribly long \User\Name\AppData path) to bring it along?  Is that correct?  Or am I missing something?


    • Edited by Qwinn2015 Wednesday, January 07, 2015 2:17 PM
    Wednesday, January 07, 2015 2:02 PM
  • Okay, continued to research, and found this:

    Windows.ApplicationModel.Package.Current.InstalledLocation

    That returns my installed solution location + \bin\debug\AppX.  That would do.  But I can't write to it, I get an UnauthorizedAccess exception.

    So have I just basically discovered that the convention for all previous compilers known to me since the dawn of time (or, well, 1980, when I started programming), including all previous versions in Windows Visual Studio, which allowed solutions/projects to write to their own runtime directories, has been quietly removed as an option?  I *have* to either use Libraries (a mechanism I'm not particularly fond of) or the irritatingly long ApplicationData.Current.LocalFolder?

    If so, then please tell me how I regain the following lost functionality.  When doing development, I may frequently want to move my solution around from one location to another, or one device to another.  Previously I could just move the entire solution by copying and pasting the solution folder itself... as long as my data files were also in the folder, it seemed to carry everything necessary, it was all nice and self-contained, and any data files I had generated during my previous uses of the application would still be available upon using the application from its new location.  But now, any data generated from previous executions is completely separated from the solution itself, and would have to be moved manually (from a horribly long \User\Name\AppData path) to bring it along?  Is that correct?  Or am I missing something?


    Yeah, and back in the good old days malwares and viruses had free reign over everything.

    The new sandbox provides a much more secure system for both developers and users. 

    Here are the locations that you can write your test.txt file to.

    http://lunarfrog.com/blog/2012/05/21/winrt-folders-access/


    • Edited by RandyPete Wednesday, January 07, 2015 4:22 PM
    • Proposed as answer by Dave SmitsMVP Wednesday, January 07, 2015 6:35 PM
    • Marked as answer by Qwinn2015 Wednesday, January 07, 2015 7:42 PM
    Wednesday, January 07, 2015 4:15 PM
  • 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?

    Wednesday, January 07, 2015 7:55 PM
  • 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.

    Wednesday, January 07, 2015 9:47 PM
  • and there is a thirth approach which i would recommend. Cloud! it looks like the roaming settings but toaming settings has problems. but you can make a own cloud service that doesnt have those problems. probally need a login then in your application but with using the LiveSDK you can almost leverage on the fact the user is signed in windows

    Microsoft Certified Solutions Developer - Windows Store Apps Using C#

    Wednesday, January 07, 2015 10:42 PM
  • and there is a thirth approach which i would recommend. Cloud! it looks like the roaming settings but toaming settings has problems. but you can make a own cloud service that doesnt have those problems. probally need a login then in your application but with using the LiveSDK you can almost leverage on the fact the user is signed in windows

    Microsoft Certified Solutions Developer - Windows Store Apps Using C#

    Way too advance for me. The highest programming class I took in college was intro to java. This fake programmer (me) can only take so much curve ball you throw at me before my head explode.
    Thursday, January 08, 2015 3:06 AM