Maybe someone can help me with the following problem:
I created a winform application in visual studio which i want to publish. The application contains a map Sqlscripts with .sql files in it.
FileInfo file = new FileInfo("../Sqlscript/View.sql");
string SQLscript = file.OpenText().ReadToEnd();
i thought about creating a directory for those files in C:\ when running the application, but ten i realized that it's not safe doing it this way. No one should have acces to sql querys. Can anyone help me for an alternate?
Thanks!
Embed your .sql file as resource (i.e, file content will be embedded in compiled code), and read it at runtime with Properties.Resources.yourresourcename
string sql = Properties.Resources.yourresourcename;
To add a file as resource, open Resources.resx in solution explorer -> Add Resource -> Add existing file (or add new text file)
Obscurity != security. If someone wants to, they can always get the contents of the file. Be it reverse engineering, or simply reading out the memoty of the program. How important is it that thay can't edit / view the SQL? Otherwise I would generate the SQL on a server somewhere. Make sure the server only accepts parameters and generates / runs the SQL there.
Related
I'm writing a C# WinForms application, and one of the components of the application is a SQLite database.
If the user is running the program for the first time, the program is supposed to create the necessary folders and files (namely, the database file) in the user's home directory. That works fine.
However, the database also needs to be set up (i.e., tables need to be added). I have a SQL script that will create the necessary tables; however, it is currently stored in the solution directory and I'm not sure if this is the best practice for when the program actually gets packaged into an .exe file.
The script will be the same every time the database needs to be set up, so I'm thinking there are probably a few options:
Have the program read from the SQL script and apply it to the database (preferred unless there is a better way)
Load the contents of the script file into memory (hard-code it into a string) and have the application run it that way (not preferred because of future versions, there needs to be a way to update the existing structure so as to not obliterate the existing database, so this way could get complicated)
Include the SQL script as part of the program package or a standalone file (very dangerous because users aren't supposed to know about that)
So what is the best way to run SQL statements from a "companion" script file? How does all of this get packaged when the program is ready for production, and how can I ensure that this file will be accessible by the program every time it is needed?
You can set the file to be copied in output directory. Select the file in solution explorer and then in property window, set Copy to Output Directory to Copy Always. This way the file will be copied in output directory and you can load it this way:
var path = System.IO.Path.Combine(Application.StartupPath, #"Script.txt");
var content = System.IO.File.ReadAllText(path);
If the file in root of the solution, use filename as above. If the file is in a folder in your solution, for example for a file in Folder1, use #"Folder1\Script.txt" in above code.
As another option you can add the file to Resources.resx. Then it will be included in resources and you can simply access it this way:
var content = Properties.Resources.Script;
Include an encrypted version of the sql file. Have your program load, decrypt it then execute it. At least that's how I'd do it.
I never see database files in the installation folders of random programs, yet they obviously have one. My question is how do they do it?
EDIT: My database can be either on SQL Server, MySql, or Access I'm not bothered, however I would like the client to not have to download SQL Server or any other programs in order to be able to use mine.
You never see database files in the installation folders because installation folders are meant for programs, not for data. The data go into the appdata folders, such as "C:\Documents and Settings\User1\Application Data\Company1\Application1" or "C:\Users\User1\AppData\Company1\Application1" depending on your OS.
I never see database files in the installation folders of random programs yet they obliviously have one
If they are oblivious to database files then they don't need them. That is why you don't see them.
You can place the database file in Hidden Mode so that user can't see it until and unless he has Show Hidden Files option true
Or instead of placing database file along with exe you can place in dedicated application directory like C:\users\username\appdata\yourapp\
My suggestion would be to store your own database as a flat XML file (for example, a plain .NET DataSet saved to file via DataSet.WriteXml ) then apply your own fixed encryption to that file. the key to encrypt/decrypt will be inside your program code and need never be altered. By storing your own data as XML you wont need a client. At the start of your program, Read and decrypt your datafile into memory, then save and encrypt out when needed.
I'm Creating Win Form application ,I'm adding a Empty Sqlite Database file having Tables in it as embedded data source. on run time i extract Database file into application path and INSERT THE VALUES into the TABLE of that Database file.
On Closing the application again i have to update or replace Database File into Executable.
Is it possible ,if so how to do that.
I'm not sure if I understand the question correctly. If you are trying to re-write to the same exe you are running this is NOT possible. Windows locks code files that are in use so that they can't change. Additionally, it is not advisable either, code and data should be separate.
If you are trying to update another resources executable (that is not currently running), I don't know how to do that programatically (See this thread here for more info How do I replace embedded resources in a .NET assembly programmatically?) but if your program has access to the Visual Studio Compiler tools (which it probably doesn't) you can disassemble and reassemble the executable. See here: http://fortheloveofcode.wordpress.com/2007/09/24/change-resources-inside-assembly/.
Why not just store it in application folder? Or maybe user's AppData if you don't want to show it?
We have to build an event registration website for our client in ASP.NET using C#.
One of the requirements is that the client wants to add new foreign languages to his website himself using en excel file. I know how to make a website multilingual in Visual Studio, but I have no idea how to generate a resource file based on an excel file in code.
I also noticed VS generates a second file called Resource.en.designer.cs but I can't find any documentation how to generate that file either.
btw, the enduser is anything but IT-related. He knows his way around excel though (obviously).
Any help is appreciated!
Yoeri
EDIT:
!Robert Levy Provided a good method!
HOW TO:
STEP 1:
Read the excel file (using an OleDBAdapter was the best method for me, as you can use column headers etc)
Write the language to a txt file in this format:
KEY=TRANSLATION
no spaces or anything else
STEP 2:
Locate ResGen.exe on your computer (it comes with Visual Studio, so look somewhere like c:\program files\visual studio\sdk... however I found it # C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\ResGen.exe)
STEP 3:
Invoke the exe with Process.Start("resgen.exe")
hint: use ProcesStartInfo for easy argument and preferences settings
(STEP 4:)
Move the file to your desired location (I find the App_GlobalResources works perfectly)
STEP 5:
Set the user currentUIculture to your desired culture!
ResGen.exe will compile resource files for you. You could either get him to deliver text files in the format used by that tool or write your own code that extracts from excel to generate the text files. Then just invoke this EXE and deploy your newly generated resource DLL. I am assuming you already know how to read things from resource files and use the appropriate one based on user preference.
http://msdn.microsoft.com/en-us/library/ccec7sz1.aspx
This is probably one place where you would like to use resources from database rather than simple resx files. It would be easier just to populate database table(s) with Excel data than transforming it to standard resx file (it could be a problem in the future if MS decided to modify file format).
So I would suggest you to write your own ResourceReader which would load strings from database (it could load it directly from Excel as well, but for many reasons I wouldn't recommend this method).
You should ask your end-user if they really have to get another language 'on the fly' and how many languages they expect they are going to add.
Otherwise, e-mailing the Excel file to you and manually creating the resource file might be by far the cheapest solution....
I have a C# winform application that accesses data from an MS Access database. This means my applications requires at least 2 files, the .exe file and the .accdb file. Is it possible to include the database in the .exe file, so my solution consists of a single file (the same way you would include an image in the project resources)? If it is possible, are they any major reasons why it shouldn't be done and how would you access the data from code? The project is a only a little one for personal use so if performance is hit it doesn't matter too much.
thanks in advance
It can be done. Simply add it to your project as you would add any other file (right click project -> Add -> Existing Item), then cancel all the dialogs that will popup offering you to handle it for you, then right click your database from your project explorer, go to properties and select Build Action: Embedded Resource.
Then use the method below to dump your database into a temporary file, which you can create by calling Path.GetTempFileName.
internal void CreateBlankDatabase(string destFile)
{
using (Stream source = new MemoryStream(Properties.Resources.MyEmbeddedDatabase))
using (Stream target = File.Open(destFile, FileMode.Truncate))
{
source.CopyTo(target);
}
}
(Note that MyEmbeddedDatabase would be your embedded database name). Then use your temporary file name in your connection string. Make sure you delete your temporary file after you're done. Also, as other said, you won't be able to modify and save any data.
No it shouldn't be done. How would you send someone and update to the .exe file without them losing their data? Keep it separate.
You need to have a way to manage how your applications installs and the file location in your connection string(s). There could be a \Data subfolder in your app folder with the .accdb file(s) in it.
You probably can't achieve what you want with an access database as an embedded resource, but you effectively get the same result by wrapping all your files in another executable app.
When you run the wrapper application, it extracts the "main" C# app, database file, and an updater app (more on this below) to the temporary files folder and runs the main app.
When the main app is closed, it runs the updater app, passing in the paths to the database file and original wrapper application. The updater app updates the wrapper application file with the changed database file. It then finally deletes the database main app and database file from the temp folder. Unfortunately, the updater app can't delete itself, but you could work around that by adding a command to the runonce section of the registry to delete the updater app on the next reboot.
Instead of figuring out how to extract and insert embedded resources, consider having the wrapper application as a compressed, self-extracting executable (like a self-extracting zip or rar file). Here's a codeproject article that describes how to turn a .Net app into a compressed, self extracting exe.
Access requires to be able to read and write to the file. The OS will lock the exe when it is run so that it can't be changed while in use. This along will cause it to not work, not to mention that Access simple wouldn't be able to read the exe as it is expecting a different file format.