Printable View
I am interested in beilding a web-application in which the application is sitting on the server. When the user runs the application, the application asks for a user-generated input file. How can I access this file from the application sitting on the server?
1. Do I upload the file? OR
2. Can I directly read the file while it is on the client-side?
Also, what is the best way to provide the output file to the user?
Never mind. Solved the problem.
Mind sharing the information?
-Cool Bizs
Not at all. Drop "File Field" from HTML toolbox into the design area with "File1" as its id. Then, after user enters the file name (through direct entry into "FileField") say "inpfile.dat", use the following two lines of code to upload it to your server:
file1.PostedFile.SaveAs(FullPathNameonServer)
The FullPathNameonServer must include the file name with which it will be stored in the server and the full path on server machine.
Once uploaded, use server-side code to access the file.
What about,
"Also, what is the best way to provide the output file to the user?"
Did you make them just click a link to download?
Craig:
That is exactly what I have done before to provide an output file to user. But I would like to be able to write directly to a user-defined file on user's PC. I haven't thought about the answer yet. If you know of a method to do this programmatically, like in a Windows application, pl let me know.
I've yet to see a way to do this easily other than using Java Applet or ActiveX control. The problem is, exposing such methods will cause a big security loophole on client's PC.
The best way I've seen so far is to write out the output into the stream in a certain format. For example, change the stream header to indicate that you're streaming Excel format and the browser will automatically pops up a box for the user to choose whether to open or to save the content.
I'm more towards displaying the output on the screen and allowing user to download the output file via a link.
My two cents,
-Cool Bizs
Coolbiz:
I agree with you 100% on the output issue; it makes immense sense to write the output on server and let the user download. That takes me to the next question. I am having problem using Excel on ASP.Net; I can access Excel spreadsheet as a database without a problem, but when I try to access it as a new Excel application, I get the error: Access Denied. Any ideas on why this is happening? It seems like a authentication issue, but I am at a loss as to how to fix it. Thanks.
Yea ... remember that ASP.NET runs under ASPNET which pretty much does not have access to do anything. You have few options:
[list=1][*]Write a .NET remoting server that handles the EXCEL processing. Your .NET remoting server can be housed in a Windows Service which allows you to run it as another user that has access to execute Excel. This is more secure.[*]Set your site anonymous user to a user that can execute EXCEL. Then, set the IMPERSONATE flag in your web.config file so that your ASP.NET runs under the anonymous user identity instead of ASPNET. As you can imagine, this is less secure.[/list=1]
Good Luck,
-Cool Bizs
Coolbiz:
Here is what I have done so far and the results thereof:
On server side, I write the following code to access the Excel file:
dim filename as string = "..path and file name.."
Dim Xl as new excel.application
dim xlb as excel.workbook=xl.workbooks.open(filename)
dim xls as excel.worksheet=xtype(xlb.worksheets("Sheet1"),excel.worksheet)
When I run it on my PC without adding 'impersonate = true" in web.config, it does not even open an excel object.
After adding 'impersonate=true' it runs fine.
When I deploy it on remote server, it provides the following error:
COM object with CLSID {00024500-0000-0000-C000-000000000046} is either not valid or not registered.
Any ideas on how to overcome this problem?
Thanks.
Are you sure they have EXCEL installed on the server? Is is very unlikely for a production web server to have Office installed :)
-Cool Bizs
Yep. That was it. I guess I'll have to work around accessing Excel on the server. Thanks.