I want to know, if it is possible to have shared internal and external (SD-card) access in a mobile c# UWP App. I know, that one can decide, whether to install new Apps internally or on SD-card via Settings -> System -> Storage.
The problem: I have a SQLite database, that I would like to run on internal NAND storage at all costs (for obvious performance reasons) and then I have a lot of images, that don't necessarily need to be on the internal NAND, but can be "outsourced" to the SD-card (so they don't clutter up valuable space especially on budget phones).
The MS documentation here suggests, that one can use the external SD-card like a drive. That solution however is not suitable to me, because it can only open file-types specified in the app-declarations and also these files would be visible to everyone and are not in a hidden app-container, like apps are.
Is there a solution or workaround for my issue?
Related
Database File and Application that reads the db. The application has a registration component added. If the user doesn't want to register they can simply download the open source application, copy the database to the new folder, run a batch file and the database opens in the application, completely eliminating the registration and whatever extra features were added.
I want to keep the database file inhouse, even if it means adding the db file into the resources of the main application. The file does require data to be written to that file.
I've gone as far as converting the batch file to an exe file and loading the database file or even renaming the database file to something obscure like abc.exe (Even though its a db file it can be renamed to anything)
Database file is renamed to an exe file for the time being, I would prefer to either have it encrypted somehow or somehow placed into the resources of my main application and accessed that way, I am just trying to limit the way the software can be pirated.
Encryption:
You can encrypt SQLite databases using extensions such as SQLite Encryption Extension. The usefulness of such encryption depends on what you are trying to do. If your application can read the keys to decrypt it, so can a hacker that can run your application. You can use Windows Data Protection API to manage the keys so that if someone copied the database from one windows machine to another, the database would be unreadable; but again, if the hacker can access the source machine, they can obtain the keys just like your application (but it would protect against a "dumb" user from just copying the files over).
Putting it in your "main application resources": If you mean embedding the database within the EXE, you are out of luck if you have a requirement to write the data. Generally speaking, an EXE cannot modify itself (though depending on OS/version/user permission/absense of antimalware agents, etc, you might theoretically accomplish a self-modifying EXE; but, if you want your app to work most of the time in the wild, this strategy won't succeed). Even if you did succeed in an EXE that read itself, loaded the embedded blob as a database, modified that database in memory, then rewrote the entire EXE with database exported as a new blob (of different size than the original, wreaking havoc on the assembly), it wouldn't help. The attacker can do what your app does and access the data. Do yourself a favor and follow the operating system's guidelines for writing user data. For Windows, this is generally reading and writing files to your Local App Data folder.
Renaming a SQLite database to have an EXE extension. What are you trying to accomplish? Obscurity? Renaming it to EXE might fool some users (certainly not the motivated user I've described above), but it also might accidentally fool anti-malware / anti-virus software running on your legitimate user's operating systems into thinking your application is writing malformed executables (which would be suspicious) and shut your application down, or at least prevent it from working correctly. This will cause your users to not use your application or a mountain of support for you. What does it gain? It stops a "dumb" user from trying to open it in a SQLite query tool?
All that said, if you want to limit your user's abilities to read the data stored on their own storage devices, you really can't stop a determined user. You can stop the less savvy users. The majority of users cannot run a reflector on a C# assembly and figure out what it is doing, but many can. If you want to stop the less savvy users, encryption of the data will stop most of them, and it will be the least likely approach you've discussed to prevent your application from working "in the wild".
I have a use-case where I need to make a block of storage (think any cloud based storage provider or a Database) available as a Windows drive.
I am happy to do the coding but haven't got a clue where to start.
you have to work with Windows Drivers SDK, there are some samples online about this, something "similar" but not 100% saem as what you need is teh RAM drive implementation whcih creates a new drive which uses RAM memory as storage,
have a look here for some source code you can compile in Visual Studio and to see how you have to setup/prepare your machine for Windows drivers development.
https://github.com/Microsoft/Windows-driver-samples/tree/master/storage/ramdisk
See this question:
creating virtual hard Drive
You would need to create a folder location, probably somewhere in the user's folder tree and map the drive as in the answer in the above link. Then use that folder to sync files with your cloud storage. I doubt you'd want to have the files in memory as you may end up with a drive containing gigabytes of data.
I wrote an app on my iPhone. It's a more portable and smaller version of my pc software. I activated the File Sharing feature on my app so now I can transfer files through iTunes. But I want my pc software to be able to read or write files to that shared folder on my iPhone without having to do it manually through iTunes.
I have big constraints:
I can't use a Jailbroken iPhone/iPod/iPad
The vast majority of my customers don't have Internet access (It's a farm management software so even cellular are not available in some area)... :(
I heard there is a way using Manzana and MobileDevice.dll (itunesmobiledevice.dll). I don't really know how to use these dll. I tried to use Manzana a little but I can't access my folder since it's not a jailbroken iPhone.. Can someone help me with a little bit of code example?
Or is there other ways to make my iPhone app communicate with my C# application using the USB cable without internet access or Wifi?
mobiledevice.codeplex.com. This project should let you send and retrieve files from the phone
I'd suggest seeing if you can use the iTunes scripting interface. Add the COM reference iTunes 1.1 Type Library to a project and you can control many parts of itunes automatically. I can't find the documentation for it, but you can play around with the library and see if there is something to access the file sharing section.
Here's a decent introduction to using it:
http://www.codeproject.com/Articles/7723/Controlling-iTunes-through-COM
I work in a call center and we need to use a lot of web based tools and work with a lot of information. They way we need to work is not efficient, so I made myself a couple of C# Windows Application to make my work a bit easier.
The problem is that those computers a locked en secured in a very high level. Almost all website's are blocked, we can't use USB drives to get data on the pc, the only way to get data to my account at work is to mail it compressed in a 7z file. We can't install software, drivers etc. I luckily have write access to the program data folder to save some data. But the only way I can store data is to put it all in .txt files. I've tried a lot of standalone databases but I'm also limited in space because we've got 30MB. So a standalone version of xampp (or similar software) is almost 40 MB so I can't use it.
Does anybody know I type of database to store my data is (mostly text and integers)? I prefer a single file which i can drop in the program data folder. I prefer it also to get the data in the same way like getting it from a database, dataset or something similar.
You may want to look into Infobright Community Edition which can give you incredible compression ratios on average from 40:1. Infobright is exactly like mysql and very compact.
Disclaimer: the author is affiliated with Infobright.
When should the Windows Registry be used for per-user state, and when should we use the filesystem, particularly the user's AppData folder? (eg, C:\Users\USERNAME\AppData). Where does Isolated Storage come in?
Is there a pretty firm rule, or is it just a fuzzy thing, like "use the registry until it becomes too much data to store in the registry". or "use whatever you feel like using."
Are there Windows logo requirements that affect the decision?
If I use the AppData directory, how do I choose between Local, Roaming and LocalLow ?
edit: I just noticed these similar questions:
When and why should you store data in the Registry?
Registry vs Ini file for storing user-configurable app settings.
I will summarize replies.
If you have a small number of key/value pairs and the values aren't big the registry is great - and you don't care about xcopy deployment - then use the registry (I know this isn't exact, but it's usually obvious when working with the registry becomes a pain).
If you want xcopy deployment the data must be in the same folder as the program obviously - but the program can be somewhere under the AppData folder, it doesn't have to be under "program files".
Use isolated storage only when you need it or have to use it - for example ClickOnce.
Otherwise use AppData\Roaming, use Local or LocalLow only if you have a good reason.
EDIT: Here is the difference between Roaming, Local and LocalLow:
Windows has a little known feature called "roaming profiles", the general idea is that in a corporate environment with this feature enabled any user can use any computer.
When a user logs in his private settings are downloaded from the server and when he logs out his settings are uploaded back to the server (the actual process is more complicated, obviously).
Files in the User's "Roaming" folder in Vista or "Application Data" in XP move around with the user - so any settings and data should be stored there.
Files under "Local" and "LocalLow" in vista and "Local Settings" in XP do not, so it's a good place for temp files, things that are tied to the specific computer or data that can be recalculated.
In Vista, as part of the new security features we all know and love, you can have programs running in "low integrity mode" (for example IE in protected mode), those programs are running with reduced privileges and can't access files in the user's profile - except for files under the "LocalLow" folder.
So, in conclusion, files stored in "LocalLow" are inherently insecure and files in "Local"/"Local Settings" are likely to be unavailable in some large companies - so unless you have good reason and know exactly what you are doing go with "Roaming"/"Application Data".
Don't clutter up my Registry thank you.
Use isolated storage, thats what it's for.
See Was The Windows Registry a Good Idea? On Jeffs Blog...
You might want to consider Isolated Storage.
I don't know whether there is a firm rule, but but one thing to consider is that the registry is transacted -- it is safer for concurrent read/write operations. So, if your user data might be written by multiple threads at run time (or if you have multiple exe's in your product package), consider using the registry.
History:
One reason (as I heard it) that MS went from .ini files to the registry was precisely to try to handle the concurrent access problem.
.Net (sort of) went back to .ini files in the form of xml .config files, however those config files are not supposed to be written to at runtime (or at least not if there is a chance of concurrent writers/readers).
More info: http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx