I'm currently working on some evaluation work for a project that I'm planning.
I recently looked at solutions for a data storage mechanism for my application and while researching stumbled upon SQLite. I currently use SQLite with the System.Data.SQLite wrapper.
I really like the way it works but I have one problem with it that I couldn't get fixed and I also found no help concerning my problem on the internet.
I would like my SQLite Database to be embedded into one of my applications DLLs (ie. Title.Storage.dll) to be used within this DLL. Is this possible?
How can I access the database then?
It would be great if I could use something like:
SQLiteConnection con = new SQLiteConnection();
con.ConnectionString="DataSource=Title.Storage.storage.db3";
con.Open();
Thanks in advance and best regards,
3Fox
An assembly isn't for file storage, it's for code storage. While you can store files in an assembly, they are read only.
If you're on NTFS, you can use an alternate data stream. On my project we hide the SQLite database inside another file using an alternate stream called :DB.
I don't think storing data in DLL is a good idea, but there is a dirty way to do it.
To load data from DLL:
Now you can make any queries in memory.
To save data to DLL:
It's stupid, but it should work. Hope you will never code that way.
SQLite is packaged and distributed as a single C file with a few (3 I think) header files. This means that you can compile the entire 50000 line program with one compile command and get a .o file. From there, you can link it into your application DLL with the other files you link into that DLL.
Once you build sqlite3.o into your application DLL, the symbols in its SQLite's API become available to your programs in the same way that your other C/C++ DLLs become available to your C#/VB programs.
Check out www.sqlite.org/amalgamation.html for more info.
This is not possible as such. What you could do is embed the db in your dll project and dump it to certain location on the file system (may be AppData?) and read and write from there. Having db sit directly inside the executable (or dlls) may not be a good idea in the sense it bloats the size of the application besides being technically infeasible.
Having a single executable to distribute is a matter of taste which I like. In your case but the problems are more. It's not just about embedding the db file alone, what about the dlls associated with it? Steps are 2:
1) Add the necessary dlls (
System.Data.SQLite
?) associated with your db to your project asEmbedded Resource
(not necessarily aResource file
) and let the system automatically resolve the assembly conflicts. Catch it here how to do it.2) Now either add your db file to your
Resources
of your project (and extract it)or even better do not embed the db as such in your project but write the logic to create database in your application. What if tomorrow you need to change the version of SQLite, say from 3 to 4? With the first approach you need to create a database for yourself and re-embed it in the project. But if you are writing the logic to create the db in your application then updating SQLite version is just a matter of changing the ADO.NET dll (the code remains the same). May be like this:
And in the connection string add
FailIfMissing=False;