First I will explain my problem. I am updating software to fit the needs for Windows 10 users. Currently we are using C:\ProgramData to store Product databases and product pricing databases. Each quarter we release new version of the software that has updated product pricing databases and maybe a new and/or edited product database that the user installs. Should this data continue to be stored in ProgramData or should we switch it to store in C:\Users\user1\AppData?
I have been looking through questions between the difference between Program Data and AppData. StackOverflow Question
The data for the user downloading the software isn't customized so AppData doesn't seem like the correct place but would like this to be verified.
Thank you in advanced.
Related
I have created my database in my windows phone app. Now i want to see whether it is created and stored data as i programmed it. But i am failed to view this database. Where my local database file get saved ? I like to mentioned that i have stored the database in the isolated storage. I heard about a method by using firefox extension i may be able to see the database but not sure what extension that is.
I've never heard about any Firefox extensions for browsing Isolated Storage on Windows Phone.
You can use Windows Phone Power Tools to copy your data file from the emulator or device to your desktop. If you're using Linq to Sql, you can open it in SQL Server Management Studio. Other data formats (i.e., Sqlite) can be opened in respective administration tools.
After Downloading Windows Phone power tools as mentioned by Michael, you can easily extract the database.
You may find difficulty in finding the exact file as the apps are listed by GUID and not their names in wp power tools.So you may have to go through each app to see which one contains the desired file.
Once you have located the file you will need a viewer (like this) to open the file.
This method worked for me just right.
Many questions on SO say "Windows developer guidelines" or "windows design guidelines" say that you shouldn't write temporary or program data to the Program Files area, but as far as I can tell none of them actually link to a piece of documentation that says as much. Searching the MSDN has yielded me no results. Windows will make the area read-only, so it can be enforced by the OS, but that doesn't mean developers didn't try to write there anyway (e.g., when porting older, XP and earlier based programs forward.)
I realize that it seems odd to ask about it this late into Windows development (since, as a commenter below pointed out, has been enforced by the OS for more than a decade), but a document that says so is sometimes necessary to satisfy people.
With that in mind, Does Microsoft have a document published stating we shouldn't write application data to the Program Files area, and if so, where is it?
From Technical requirements for the Windows 7 Client Software Logo Program:
Install to the correct folders by default
Users should have a consistent and secure experience with the default
installation location of files, while maintaining the option to
install an application to the location they choose. It is also
necessary to store application data in the correct location to allow
several people to use the same computer without corrupting or
overwriting each other's data and settings.
Windows provides specific locations in the file system to store
programs and software components, shared application data, and
application data specific to a user:
Applications should be installed to the Program Files folder by default. User data or application data must never be stored in this
location because of the security permissions configured for this
folder (emphasis added)
All application data that must be shared among users on the computer should be stored within ProgramData
All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in
Users\<username>\AppData
Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as
fonts or drivers
In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no
correct user location to store data at time of installation. Attempts
by an application to modify default association behaviors at a machine
level after installation will be unsuccessful. Instead, defaults must
be claimed on a per-user level, which prevents multiple users from
overwriting each other's defaults.
And I'm quite sure that there's similar stuff for every Windows version of the NT family going back to Windows NT 4 or even earlier.
See also this question.
Edit: the original link in this post to the Windows 7 Logo program exists no more. Here you find the current link to the Certification requirements for Windows Desktop Apps. See Section 10, Apps must install to the correct folders by default
In later versions of windows (Vista, 7 and of course server versions) access permission are restricted for "special folders" including "Program Files". Even if your program is elevated to have sufficient privileges to write to this folder it is still a bad idea.
I don't know of any guidelines that state this but there is a list of special folders and what they are meant for. The fact that there is a special folder for nearly all types of data I can image means there is no need to use the program files folder.
We just discovered a new problem with our registration scheme on Windows 7 64 bit edition. Currently we save a hidden registration file inside our application's resources but it has become clear that this is not the best place for this. Today we discovered that on Windows 7 64 bit edition when an application tries to create a file inside program files(x 86)/.. it actually ends up in the user's appData inside the virtualStore. This becomes a serious problem when a different user tries to use the software from a different account (because the virtualStore is specific to the user's account and the user gets asked to register the software again).
I am wondering where do people usually put these kinds of registration files?
So there is this software. When installed it somehow (probably reads file or registry entry) recognizes my windows operating system.
It's supposed to do some tasks only once per unique computer. If I uninstall the program and re install it, the software remembers that it has been installed and therefore do not do the task.
If I use system restore, software also does not do the tasks. If I load image of the system before the install, software also doesn't do the tasks.
If I re install a fresh copy of windows, then only the software does the task. IP even does not matter. Everything is the same, except it is a brand new copy of Windows operating system.
So I guess that the software reads some kind of unique operating system identifier, then connects to server to create a user profile.
So the question is? What could be those files which software uses to check system identifier? So far I have found out that there are entries under registry. WindowsNT/CurrentVersion and Windows/Cryptography but software do not rely on them.
Where else should I search? Any software which could help me find out?
Maybe it's reading the ProductId value from the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion.
Microsoft says:
The product key also forms the basis
for the product ID that is created
when Windows XP is installed. Each
licensed instance of Windows XP has a
unique Product ID.
Take care, for some OEM smopuiM versions, there is only one licensed instance of Windows XP. So you can find the same product ID for two PC.
You can use FileMon and RegMon by SysInternals to check what files and keys in registry are being accessed
I've been asked to update a VB6 application that's been running on WinXP for the last 6 years. The client wants to use Windows 7. Up until now, the app stored its settings in an INI file located in the application directory. One key difference between XP and 7 is that you can't write to C:\Program Files\AppFolder anymore.
I am trying to figure out where on the file system should I store settings? Given that the application is still required to run on WinXP, I am kind of confused.
On WinXP, I have the following:
C:\Documents and Settings\profilename\Application Data
C:\Documents and Settings\profilename\Local Settings\Application Data
On Windows 7, I have the following:
C:\Users\profilename\AppData\Local
C:\Users\profilename\AppData\LocalLow
C:\Users\profilename\AppData\Roaming
Each one of these folders have subfolders that seem to store settings/files for various products
So 2 questions:
Given all these folders, where do I store my settings?
I am assuming that there is a nifty Windows API call that would give me the proper location of this folder. And I am hoping it works on both XP and 7. Is my assumption correct? If so, a link would be much appreciated.
There are a number of special folders you can use, on XP/Vista/Windows 7:
The CSIDL_APPDATA folder is the one you will likely be most interested in. Data stored here is available to roaming users at whatever machine they log in to. This is the best place to store simple configuration data. All users have write access to this (and the last) folder. Note that none of the above folders are for user-generated data! That would properly belong under the My Documents hierarchy.
EDIT: As Cody Gray suggests in the comments, also consider CSIDL_LOCAL_APPDATA for application data that will always be local to the current machine, but is set aside on a per user basis. The data in this folder is not available on a roaming basis, so it should be data that the user will likely not miss if they log in to a different machine.
I shamelessly copied the explanation above from a good article by Karl Peterson, explaining this for VB6 programmers. Karl also has a ready-to-use class that will help you find the directories, but IMHO he's overcomplicated things this time. Bob Riemersma has a better way in one line, using the Shell object, as below. EDIT Bob's comment below explains why it's best to use late binding for this rather than early binding.
Const ssfCOMMONAPPDATA = &H23
Const ssfLOCALAPPDATA = &H1c
Const ssfAPPDATA = &H1a
Dim strAppData As String
strAppData = _
CreateObject("Shell.Application").NameSpace(ssfAPPDATA).Self.Path
In my opinion it's fine to continue to use INI files in these directories.
See the question "Does Microsoft have a best practices document regarding the storage of app data?" for some helpful info.
Maybe you just save your settings in Windows Registry?
That's very easy. Using SaveSeting and GetSetting is much easier than creating INI file.
And there is no trouble in compatibility, from WinNT to Windows 8.