I want to create a Text file in my code behind file in my web application. However, I am not allowed to save this file to server. So I tried to use MemoryStream class to save my file into memory. So far I have,
MemoryStream memoryStream = new MemoryStream();
TextWriter textWriter = new StreamWriter(memoryStream);
textWriter.WriteLine("Something");
memoryStream.Close();
It seems like working but my requirement is to open this file on client browser when he/she clicks button. Since this file does not have a physical path like ..../text.txt. I have no idea how to open it on browser.
How can I do this in ASP.Net using C#. I searched a lot but could not find a solution working for me.
Thanks in advance.
This is a lot easier than you think. Keep in mind that the HTTP protocol doesn't actually transfer "files" in the strictest sense of the word. It transfers requests and responses, each containing headers and content. In this case, you're concerned with the headers and content of the response.
The easiest way to do this in a WebForms application is with a generic handler. Specifically, take a look at the implementation of the handler's response in that link:
context.Response.ContentType = "image/png";
context.Response.WriteFile("~/Flower1.png");
This is writing the content of an image file to the response after setting the response's header appropriately. What you want is closer to what's commented out in the implementation:
context.Response.ContentType = "text/plain";
context.Response.Write("Hello World");
This would send to the browser plain text, nothing more. The browser won't think it's a web page or anything like that, won't apply any styles to it, etc. As far as the web browser is concerned, it just downloaded a text file with the words "Hello World" in it. You can Response.Write() all the text you want to build that file.
You can further customize your response headers to give the browser even more information. For example, if you add the following header to your HttpResponse:
Content-Disposition: attachment; filename=myfile.txt
Then the browser will translate that to mean that this "file" should be downloaded and saved, not just displayed. (Of course, the user's browser settings may tell it to display it anyway, but this is the proper way for the server to "suggest" to the browser that it should save the file.)
From the point of view of the browser, it doesn't matter where the "file" came from. Whether it was from the server's file system or dynamically generated or magically conjured, it makes no difference. The browser is concerned only with the response headers and content. If the headers say it's text, and they say that it's a file, then the content will be treated as a text file.
Why do you need to write a MemoryStream? Just write it to the HTTP response if you want to send it to the browser.
Response.WriteLine("Something");
If you want to make the browser download this response as a file, see here.
I honestly believe this isn't a good pattern in Web development.
It's just about reading your file and send its data as text to the client-side (Web browser), edit it in a textbox, send back modified text and save it as file in the path or storage of your choice.
HTTP is an stateless protocol, so you won't be leaving a file opened in the server-side while its contents are edited in client-side, as both tiers are absolutely disconnected after server response ends.
Ok, I think I figured out what you want. You say you have a button, with witch you want to go to the content of a text-file, that you want to create in-memory, but you don't know what url to send the browser to when the user clicks the button?
If this is the case here's what you can do:
1) On the page that has the button, set the href (or link-location or whatever) of the button to be a new asp.net page (jet to be created). Something like "textfile.aspx" or whatever. Also, remove all the code regarding the memory-stream.
2) Create the new asp.net file (textfile.aspx, or whatever you decided to call it). The content of that file should be like this:
Response.WriteLine("Something"); // Or whatever you previously wrote to the MemoryStream
The point is, you should separate into two different files (or separate action based on query-string).
Related
I am working on a file uploading functionality using ASP.NET, C# and telerik. I am using telerik:RadAsyncUpload control. I already convert the file to byte array and save in the SQLServer Database.
On update page, I need to open file directly(from the binary data saved in db), when I will click a link. I need to Open that file in separate browser tab/window. I do not want to save file Physically on any local drive while retrieving it.
Please help me out.
What I have tried?
For time been, I am saving that binary data in a blank file located at some local drive and then attaching it to that link. but I do not want to save file Physically on any local drive while retrieving it. I want .....when user will click link binary data will directly flush on separate browser tab and he can view the file.
Create a handler (arbitrary one or an aspx page, whatever you find easier) that will read the database (e.g., based on a querystring argument) and return the appropriate response (via the Response object, e.g., Response.BinaryWrite()).
Note that you should set the appropriate headers and that depending on the type of file you return the browser may prompt the user to open/save it instead of opening it inline. You have some control over that via the content-disposition HTTP header, but it is ultimately up to the browser.
Also, you may want to use a RadWindow to open that handler to keep browser popups to a minimum to reduce the risk of them getting blocked by the browser.
I have to send many, difference text files to print one click on button in my WebApplication but the first I have to download this files from server.
How should I have to do?
You cannot send more than one file in the same response. It's programmatically feasible, but the browser will not be able to understand the response.
If you need to send several content in just one event (a click response, for example) it is better to compress the documents and send one .zip file. The other option is to response to different buttons, one per file.
The reason is that the HTTP only expects one kind of response, not two or more.
I have looked around a lot and i cant seem to find a way that works for me. I am creating a website, and I have two buttons, a Download button (which works fine) and a Print button that should print the PDF (or even just open the PDF in adobe with the print dialog open).
The biggest difference between my question and many others is that I'm not trying to create a new document. My PDF is generated using a template PDF that I have created already.
I just need a way to print the document. I cannot save it on the server because I want the client to be able to print it. I have tried a MemoryStream, but its not working(granted I probably didnt write it correctly, the code is below). The header is grabbed from a different page.
using (var ms = new MemoryStream())
{
Response.ContentType = "application/octet-stream";
Response.AppendHeader("Content-Disposition", header); /
Response.Buffer = true;
Response.Clear();
var bytes = ms.ToArray();
PdfReader r = new PdfReader(template);
using (PdfStamper ps = new PdfStamper(r, Response.OutputStream))
{
AcroFields af = ps.AcroFields;
...
ps.FormFlattening = true;
}
Response.OutputStream.Write(bytes, 0, bytes.Length);
Response.OutputStream.Flush();
Again, I want to be able to have the client print this PDF that is generated once they click the Print button.
Before going down this path too far I just want to make sure that some things are properly explained. I don't know your level of expertise so please don't be offended if I say something that is obvious.
First, you say that you have two buttons, "Download" and "Print". We know what you intend for these to do however its important to know and understand that both of these options are "download". Your "Download" button is really "download and (maybe) prompt to save" and your "Print" button is really "download and then if the person has a PDF renderer configured in their browser (which most modern browsers have) then render the PDF otherwise prompt to save". This might be very obvious already to you but I just wanted to make sure it was clear. I personally don't have a PDF renderer bound to my default browser so all PDFs download for me every time.
Second, the server gets to send one and only one "thing" back to the client in response to a request. That "thing" can have meta data (headers) associated with it but there are very few standard meta keys out there that are relevant. One key (content-disposition) is whether this response should be treated, relative to the initiating request, as "inline" or an "attachment". Some browsers treat the latter as a "download and (maybe) prompt to save" but some still will launch an associated application. There's another key (mime type of application/octet-stream) that some people use to further trick browsers that essentially says "seriously dude, this thing I'm sending is so weird that it would be impossible for you to figure it out so just save it to disk".
This is all very important because there's no "please print this" thing that you can send from the server that's in any standard spec (or any spec that I've ever seen for that matter). Also, the server cannot even say "open this in a new tab or browser window". Both print and window/tab control are client-side features so you need to attack from that angle.
So now on to some options. These options all assume that your clients have modern browsers with PDF renderers built-in and enabled.
One option that you could use would be to wrap your PDF in an iframe that has some JavaScript that calls window.print() upon loading. Google used to (and maybe still does) for their calendar. You'll need to test this with your various client rendering devices to make sure it works as you expect.
Another option is to try using PDFObject to embed the PDF and then use the same JavaScript mentioned above.
One last option is to slightly change your PDF generation code and add JavaScript to your PDF the tries to print the PDF on load. JavaScript support in PDF renderers isn't universal so you'll need to check whether this works with your clients. Also, this setting is "baked" into the PDF that you make, so if someone saves it to disk, every time they open it it will try to print which is very annoying.
Using info found here and elsewhere I have successfully implemented an app that will pull a PDF from our document storage server, stream it across our firewall and display it in a frame on the client's web browser. The PDF is loaded into a page using the following code and that page is the source for the iframe.
int ImageID;
if (int.TryParse(Request.QueryString["ImageID"], out ImageID))
{
FileTransferService.FileTransferClient client = new FileTransferService.FileTransferClient();
Byte[] documentStream = client.GetFile(Classes.AppSettings.pwServer, Classes.AppSettings.pwDatabase, Classes.AppSettings.pwUsername, Classes.AppSettings.pwPassword, Classes.AppSettings.pwCabinet, ImageID, "", "");
Response.ContentType = "application/pdf";
Response.BinaryWrite(documentStream);
}
This is working fine most of the time, but due to settings on the client for the Acrobat Reader plugin the PDF will sometimes open in Acrobat Reader rather than displaying in the web page, leaving our page with an empty hole where the PDF should be. I've searched for a third party PDF viewer we could use in the app without success. Either they don't accept a stream as a source or the image quality is unacceptable. If we could force it to always pop up in Acrobat Reader that would be acceptable, but we'd prefer it to be displayed in the web page. For security reasons we don't want to write the file to disk and display it from there.
Is there a method to force the viewing behavior one way or another or a third party viewer we could use that will solve this problem?
As an alternative to the optimal solution, you could add the 'Content-Disposition' header to make the browser always treat it as a download.
Usage:
Content-Disposition: attachment; filename="example.pdf"
This may also be worth looking into, although I've never used it:
System.Net.Mime.ContentDisposition
Represents a MIME protocol Content-Disposition header.
I am saving a .doc file to a SQL Server database as varbinary(max) using the C# code below.
I am able to save the file, but when I retrieve the file back and want to display the contents on the web page, my code is downloading the file and I am in great confusion about how to handle it.
The exact functionality I am looking for is the way naukri.com uploads the resume and gives a preview of it. My code is :
byte[] fileContent = new byte[fuResume.PostedFile.ContentLength];
fuResume.PostedFile.InputStream.Read(fileContent, 0, fuResume.PostedFile.ContentLength);
//lblAppliedMessage.Text = ByteArrayToString(fileContent);
//lblAppliedMessage.Text = BitConverter.ToString(fileContent).Replace("-", string.Empty);
byte[] btYourDoc;
btYourDoc = fileContent;
Response.ContentType = "application/ms-word";
Response.AddHeader("Content-Disposition", "inline;filename=yourfilename.doc");
Response.OutputStream.Write(btYourDoc, 0, fileContent.Length);
Response.BinaryWrite(btYourDoc);
Response.End();
The reason your file is getting downloaded instead of displayed is because you're setting the content type to application/ms-word. This tells a browser to download the file (they can't natively handle files of that type so they delegate to an external app).
You'll need to have code that knows how to interpret the MS Word format and convert that to something viewable in a browser (HTML, some kind of plugin that will do that for you, etc). Saving the raw Word document and then sending it back to the client in the same state is basically just having them download a Word file.
squillman is right. There are tons of third party components that do Word -> HTML conversion.
One other option, which may be more appropriate for an intranet site, is to install Word on the server.
An example of this is here:
http://www.c-sharpcorner.com/UploadFile/munnamax/WordToHtml03252007065157AM/WordToHtml.aspx
Effectively, the doc is opened, saved out as HTML, then subsequent requests can retrieve the HTML version of the file for preview.
Office automation server side has many pitfalls, however - see http://support.microsoft.com/kb/257757 for more information.
Here's a good one where the end result it's up to the user whether to download or view the file here's the link but #Squillman is right by putting the Response headers you're telling it to download.