Why are temp/local/roaming folders not in Windows.ApplicationModel.Package namespace? RRS feed

  • General discussion

  • I wonder why the apps folders are not all in one namespace, namely the Windows.ApplicationModel.Package namespace.


    would make perfect sense to me. Instead I have to remember, that files in the package are in the package namespace, folders accessible for the package are in Windows.Storage.ApplicationData


    Anybody knows the reasoning behind it?

    Monday, June 16, 2014 12:32 PM

All replies

  • installedLocation is where the package is installed, and not where the data is saved, beside that is InstalledLocaiton readonly when your app is downloaded from the store. This isn't used to save your own data. Windows.Storage namespace gives you access to storage where you can save data, create files. so it has an whole other purpose

    Microsoft Certified Solutions Developer - Windows Store Apps Using C#

    Monday, June 16, 2014 1:05 PM
  • I know all that. My question was about why the folders reside in the namespaces they are in. For me, it all belongs to the ApplicationModel.Package namespace.
    Monday, June 16, 2014 1:45 PM
  • I don't know the exact history (this would've been taking place in early 2011) but I imagine it could've gone either way and someone eventually had to make a decision. Generally speaking, Windows.ApplicationModel has package information along with a bunch of APIs that deal with app-to-app communication, contracts, activation, suspend/resume, and background tasks. Windows.Storage, on the other hand, has everything to do with the file system.

    Because appdata folders are probably more closely aligned with the file system than with the "app model" stuff, I can see why Windows.Storage was the landing place. After all, that's where you find all the other file I/O APIs, and I can imagine that if the ApplicationData APIs were in Windows.ApplicationModel, we'd be having the same question about why they weren't in Windows.Storage. :)

    I would guess that there was probably an argument for putting the package information classes into Windows.Management.Deployment, which is probably it's most natural home. However, the rest of the APIs there are desktop-only and not accessible to Store apps, so it made some sense to put the Package class elsewhere. I expect this decision was probably made well after the decision to put ApplicationData into Windows.Storage.

    It's also worth noting that the appdata folders are not technically part of the package, so it's really the installedLocation property that's the aberration. The rest of the Package and PackageId properties come from the Store and describes the package characteristics more than runtime state. Thus installedLocation just so happens to be the link between all the package info and the file system.

    In the end, I think the structure that we have actually makes the most sense, because when you start talking about appdata you automatically end up in Windows.Storage.

    Knowing the guys in API naming team that bandied all this kind of stuff about (guys like Harry Pierson, Jason Olson, and Brent Rector), I expect that they discussed all these pros and cons before making a decision.


    Author, Programming Windows Store Apps with HTML, CSS, and JavaScript, Second Edition, a free ebook from Microsoft Press.

    Monday, June 16, 2014 4:02 PM
  • Thanks Kraig for the thorough explanation!
    Monday, June 16, 2014 5:59 PM
  • +1 on all points Kraig (I was involved in much of this sausage making early on, and I have the scars to prove it :-)

    The architect must be a prophet...a prophet in the true sense of the term...if he can't see at least ten years ahead don't call him an architect - Frank Lloyd Wright Howard Kapustein [MSFT] -- Looking for the Spike... [http://blogs.msdn.com/b/howardk/]

    Thursday, June 19, 2014 12:06 AM