I have a C # application and I need to keep in her pictures, but I can not use resources (resx).
Is there then an alternative method?
update:
ANSWER:
My images is static, for this I will use Embedded Resource
How create embedded resource
As mentioned above, it really depends on whether or not they are static or dynamic. If static, you could use an Embedded Resource (instead of encoding them as constant byte arrays, as others have mentioned). If dynamic, you could store them in isolated storage.
Is this a dynamic set of pictures or static? If static, you can compile the resource file as a separate assembly and then consume it. If dynamic, you need some type of data store to store the files. If file system does not work, a database is an option.
One idea comes to mind, but I probably wouldn't use it if at all possible: put the images into your code as arrays of bytes.
You could create byte[] fields for the images and initialize them in code. You could dynamically generate the code using either CodeDOM or Reflection.Emit.
If images are not too large you can encode them into huge constant arrays in code.
This is not very elegant solution but what else if no file, no resource, no database?
Given the options you gave us, that doesn't leave us with much to work with. Depending on the image size, you can use this website to encoding your images to Base64 and then store them in a string. Then you can use System.Convert.FromBase64String to convert them from base64 back to a byte array.
Another option would be to store your images on a web server and create a webservice on the server that you can consume to retreive the images.
These are not good methods though. The first idea is consuming a lot more memory then it would need to and the second method is just kind of ridiculous if you think about it. It is much much much better to use a database. You can use a database such as MySQL that will work with both Windows and Mono. You can also use SQLite database so that the database is portable. There really isn't a good reason to store this in a database.
I would go on my line: you can save on disk by using any Mono ZIP library that provides secure encryption.
Zip: cause you potentially will save a space
Encryption: if you need save some private data (family images, documents...)
Can group them based on your own app logic, or save them individually, with also some metafile attached, if you need also provide some information on image.
Microsoft uses this kind of "technology" for example for DOCX files. Try to change an extension of DOCX file to ZIP and unzip it into the folder. You will see the content.
Regards.
Related
I have a list of store information.
Each store has a region, a zone, and a store number.
The way I've been doing this now is:
I have a Store class, and a List with elements type Store.
In each application, I have to add this long list of StoreList.Add(new Store() { ... }), which looks bad, is sloppy, and totally not convenient. So I was looking for a way to use this information across multiple solutions/projects.
I don't want to use a database because I don't really want additional overhead in what could be simple scripts. Is a DLL something I would use in this circumstance?
You said you don't want to use database, but probably its not a bad choice. You can store the information in a XML file and read that on application startup. Having such information in a class and then dll, would complicate things. If you have to modify a store number, you have to deploy that dll on computers running your application, although modification in XML would be required on computers as well but it would be easier IMO.
Also if you have that information in some central database and loads up that information on application start event, it would provide you a much better option of maintaining your application and having lesser changes in client side / deployment.
The problem is not whether you want a database or not, but if you need to store your data once your application closes.
Now, you can use a database (could be an embedded one) or a file (xml most probably).
If all your data is stored in code (not the best option really) then yes, you can move that code to a class library project and distribute it wherever you need it.
But still, at the very least this is what i'd do
Move your list items to an xml file
Create a class that reads this file, and loads it into the list
Add the xml file to your project and mark it as an embedded resource (so it'll be packed with the dll)
You can read the xml file from the assembly directly (check here on SO how to do it)
Hope that helps
I understand how serialization works and was wondering if there is a way to store an object on the disk and work with the object and save the changes.
I am trying to avoid directly doing this:
Opening the file
Deserializing the object
Changing the object
Serializing the changes by overwriting the old file
Is there a class that allows a file to be used as an object store, namely List<object> and working with it directly on the disk without having to complete the above processes?
Try DB4O. It seems to be a solution for your requirements.
I dont believe there is an out of the box solution for this. Just search on how to save arbitrary data in a file, and think up your own format.
You probably want to look at something like ESE which comes with Windows. There is a managed interface for it. Never used it though.
Either that or use a lightweight database e.g. SQLite, since effectively, if you want to add, remove and modify data on the disk, some kind of database is what you need.
Objectivity is another alternative. It supports computing across vast distributed networks or embedded in stand-alone devices that simply must not fail, enables persistent object management, virtually instantaneous traversal of complex, many-to-many relationships and graphs, and much more.
I have a C# app that uses a DLL I made and I have to store 3 variables inside the DLL that have to be constant so I can get them later even after the user closes the program (I need to get them every execution after I write the data to the DLL). I want to store them inside the DLL because I don't want to use the registry or use any external files so I was thinking of using a Resource file within the DLL to read/write my static data to.
Can anyone give me an example of how to use the resource data like this or suggest another way to do this without declaring hardcoded variables (which I cannot do), or using the registry/external data files to store the information.
I would suggest using Isolated storage to write your data. You can have a quick start here.
Use a regular memory mapped file. Writing to binary executables is bad practice and many (if not all) OS-es will prohibit that in all but the most promiscuous security policy settings.
PS. The popular term for this kind of storage is 'database' (or program database). This should help you get a few google hits.
Also, depending on your preferred method of implementation you can use memory-mapping to overlay your data-segment (so you can have your cake and eat it: keep you global static data where it is and easily commit them to disk). However, this is more in the C/C++ spirit.
In .NET you'd have to use a giant custom-layout struct (meaning, all reference types are out of the question - this is more unnatural in C# than it is in, say, C++)
So your best bet is probably to use an UnmanagedMemoryStream, serialize your data using builtin .NET System.Runtime.Serialization (of which the XML flavour is by far the more popular and easily copied from blogs and other sources).
Cheers
I have a site which is akin to SVN, but without the version control.. Users can upload and download to Projects, where each Project has a directory (with subdirs and files) on the server. What i'd like to do is attach further information to files, like who uploaded it, how many times its been downloaded, and so on. Is there a way to do this for FileInfo, or should I store this in a table where it associates itself with an absolute path or something? That way sounds dodgy and error prone :\
It is possible to append data to arbitrary files with NTFS (the default Windows filesystem, which I'm assuming you're using). You'd use alternate data streams. Microsoft uses this for extended metadata like author and summary information in Office documents.
Really, though, the database approach is reasonable, widely used, and much less error-prone, in my opinion. It's not really a good idea to be modifying the original file unless you're actually changing its content.
As Michael Petrotta points out, alternate data streams are a nifty idea. Here's a C# tutorial with code. Really though, a database is the way to go. SQL Compact and SQLite are fairly low-impact and straightforward to use.
I am wondering which way is the fastest to deliver images via ASP.net:
//get file path
string filepath = GetFilePath();
Response.TransmitFile(f);
or:
string filepath = GetFilePath();
context.Response.WriteFile(f);
or
Bitmap bmp = GetBitmap()
bmp.Save(Response.OutputStream);
or any other method you can think of
TransmitFile scales better since it does not load the file into Application memory.
You'll need to test with large image files to see a visible difference, but TransmitFile will outputperform WriteFile.
In either case, you should use an ashx handler rather than an aspx page to serve the image. aspx has extra overhead which is not needed.
One more thing-- set the ContentType when sending the file or the browser may render it as binary gibberish.
In the case of BMP:
context.Response.ContentType="image/bmp";
This doesn’t really answer your question but asp is not a file server, if you want to serve files use IIS and get Asp to link to those files, or if you must use ASP use it to redirect to the appropriate place.
I am not saying that it can't be done but if you are worried about performance, you may consider going down another route.
Of the methods you have I would think that the bitmap one would be slowest as that is creating a more complex object.
MS seems to have a decent solution if you must do it through asp.
It's easy enough to test, I recommend you set up three different URLs that will test the different mechanisms and then have a client (HttpWebRequest/HttpWebResponse or WebClient instance) download the content from all of them. Use a Stopwatch instance to time the download.
I imagine that it's not going to matter, that network latency is going to trump IO latency (unless you are thrashing the hard drive all the time) most of the time.
Well one thing is for sure - this will NOT be as fast as letting IIS server the file. If route the request through asp.net instead of letting IIS serve it then you are introducing a bunch of overhead you dont need.
The only reason I can imagine routing through asp.net is for security purposes; is that the case?
In my experience, use TransmitFile(), as long as that's the only thing you intend to send, and it sounds like it is.
Note this is incompatible with AJAX-enabled ASPX files.
I imagine you want to do this either out of security concerns, or to record some type of metrics (e.g. recording each hit to the database to find out what image is most popular, or who is viewing the image, etc.), or for URL rewriting purposes. If there is no particular reason to use ASP.NET to serve the image, then you should just let IIS take care of it as others have noted.
Also - this doesn't answer your question of which method is most efficient when reading an image file from disk, but I thought I should point this out:
If you already have a Stream or Bitmap containing the image, use that to write directly to Response.OutputStream. You definitely want to avoid writing it to disk and then reading from disk if you already have the Stream.