hello,

i have what i would guess to be a relatively "newbie" question: how do
i create & write to a new text file?

i have found plenty of articles (MSDN & other) on how to do this in
conjuction w/ the *file system*, but i do not wish to touch the
client's hard drive. rather, id like to build up a .txt file in memory,
then Response.WriteFile() it back to the user (ASP.NET plaform).

there are so many streams it's somewhat confusing. a high-level point
or link to an article would be most helpful.


thanks!
matt

> id like to build up a .txt file in memory
>
> there are so many streams it's somewhat confusing. a high-level point
> or link to an article would be most helpful.
>
MemoryStream?

are you asking a question?

ok, so i can use this syntax to write:

MemoryStream ms = new MemoryStream();
StreamWriter sw = new StreamWriter(ms);

foreach (DataRow row in _dtResults.Rows)
{
sw.WriteLine("foo");
}

...got that part. but then what do to change that memorystream into a
file? the Response.WriteFile() method takes in either a file, or a
"IntPtr fileHandler", which i am not familar with.

is there a way to convert a stream into a new file? the File
constructor doesnt seem to take a stream as a parameter.

thanks!

ah.. ok, i dont think the memorystream is really needed. atleast in my
case... since i am return this to the web user, i can do so:

//build file's contents
StrinbBuilder sb = new StringBuilder(50);

foreach (DataRow row in _dtResults.Rows)
{
sb.Append("foo");

sb.Append("\n");
}

//send file to user
Response.Clear();
Response.ContentType = "application/octet-stream";
Response.AppendHeader("content-disposition", "attachment;
filename=foo.text");
Response.Flush();
Response.Write(fileContents);
Response.End();


(tho i am still curious about how one takes a memorystream and turns it
into a file object)

matt

It's a bit difficult, the beta WinFX SDK completely messed my C# express &
WebExpress documentation... :-(
basically you should use
HttpResponse.Write (String)
and build the string with an in memory stream.

How to do that? here is some pseudo code (caution: name of the actors could
have been modified)

// 1st create the memory stream to write to
MemoryStream ms = new MemoryStream();
StreamWriter sw = new StreamWriter(ms, Encoding.UTF8);

// 2nd fill it up
sw.WriteLine("blah blah blah");
sw.WriteLine("foo bar foo bar foo bar foo bar");

// 3rd get its content!
ms.Position = 0;
StreamReader sr = new StreamReader(ms, Encoding.UTF8);
string content = sr.ReadToEnd();

// 4th write it to the user
HttpResponse.Write(content);



<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> ah.. ok, i dont think the memorystream is really needed. atleast in my
> case... since i am return this to the web user, i can do so:
>
> //build file's contents
> StrinbBuilder sb = new StringBuilder(50);
>
> foreach (DataRow row in _dtResults.Rows)
> {
> sb.Append("foo");
>
> sb.Append("\n");
> }
>
> //send file to user
> Response.Clear();
> Response.ContentType = "application/octet-stream";
> Response.AppendHeader("content-disposition", "attachment;
> filename=foo.text");
> Response.Flush();
> Response.Write(fileContents);
> Response.End();
>
>
> (tho i am still curious about how one takes a memorystream and turns it
> into a file object)
>
> matt
>

yeah, psuedo code is great, thanks.

now looking at that.. doesnt it seem much heavier than the above
(stringbuilder, response.write)...?



thanks,
matt

ho, oops....

1st. I missed the part with the StringBuilder. You keep changing variable
names, that confuses me!
just to make it clear:
yep, you could write
StringBuilder sb;
Response.Write(sb.ToString())

it's even better in this case in your case!.

2dn: I was addressing your question about MemoryStream.
Showing you how to work with them.
Of course my pseudo-code is much heavier than your StringBuilder version but
it's also much more extensible / flexible.
On top of that, as you seems to be not very knowledgeable in the Stream
area, it shows some usage of Stream chaining, which is a powerfull lego
concept.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> yeah, psuedo code is great, thanks.
>
> now looking at that.. doesnt it seem much heavier than the above
> (stringbuilder, response.write)...?
>
>
>
> thanks,
> matt
>

doh! i put my example together from two different tests, thus the
mis-named variables. sorry.

ah.. yes. thanks for the pointers on the stream. thats good to know
about the memorywriter & streamreader.

but, what about working w/ a File obj -- does a File *have* to be
linked to the file system (ie, harddrive)? i wonder if one can build-up
a text file via the MemoryStream as in your example, and then convert
it somehow into a File, say if that's what some other function requires
for further manipulation. (this is not my present scenario, but is
interesting nonetheless).


thanks again for the tips.

matt

> doh! i put my example together from two different tests, thus the
> mis-named variables. sorry.
Oki doki!

> but, what about working w/ a File obj -- does a File *have* to be
> linked to the file system (ie, harddrive)? i wonder if one can build-up
> a text file via the MemoryStream as in your example, and then convert
> it somehow into a File, say if that's what some other function requires
> for further manipulation. (this is not my present scenario, but is
> interesting nonetheless).

You get me lost here.
It's very confusing the way you say "only File"....

Here is a list of what you could call a file and their possible source.
I think I get most of them, but I might have missed what you were thinking
about, who knows?


..NET: System.IO.Stream: could be anything, including a MemoryStream as shown

..NET: System.IO.FileStream: typically only a file system file

..NET / C: string: filename: has to be a file system file in most case. (well
could be a pipe or a printer port, etc... but it's seldom the case)

C: HANDLE: many thing (socket, pipe, memoy mapped file, file system file,
com port, printer port, etc...) but typically, when created by the user, a
file system file.
However, with some effort, could be a memory mapped file with no file system
representation.

..NET: IntPtr (point to a Handle): as above.

So, look at the various signature of your methods/functions and you get your
answer.
if you don't know what you're speaking about, you can't tell!