I am downloading an xml string from ASP.Net and want it to open in MS Office Infopath. I set the ContentType to "application/ms-infopath.xml" (not sure where I got that from).
On some machines it is fine, on others the xml opens in the browser, or in Visual Studio or some other xml editor, even though Infopath is present.
Who keeps the list of valid content types?
What does the OS or browser do with it?
How can I force this XML to open in the program of my choice (Infopath)?
I know this question is really old, but I had the same problem.
I trolled through all the file types on windows trying to find one that only opens in infopath - and there actually is one! Every default install of office has the file extension ".infopathxml" set to open with infopath. So just set your file= part of content_disposition header to "whatever.infopathxml".
xml does not map to any program by default, but will tend to open in whatever someone last used (usually IE's viewer or visual studio), while almost no one will change what .infopathxml files open in.
As I understand it, its still left to the end user. Content-type specifies how the data should be read and verified, but its up to the end user which extension is mapped to which program. You can't force xml to open in one program anymore than you specify which zip program a zip file should open in... the only thing you can do is use a file extension that is almost certain to be unique for that program, such as .infopathxml in this case.
Related
We have a legacy ASP.NET application that allows users to export the contents of a GridView control to Excel. This was achieved using this technique.
Recently, users have complained that they are unable to open their downloaded files in Excel. I tried it myself and discovered that Windows was blocking the downloaded file, preventing Excel from opening it.
It looks like Windows now regards XLS files that have been created from web page content as suspect. Is this the result of a recent Windows update? And is this technique of creating Excel files from web pages not recommended?
Correct, recent updates have broken this behavior (thanks to Nikki9696 for the article).
There are three workarounds listed:
Stop using HTML files masquerading as XLS
Unblock access to individual files (client side solution)
or add the source of the files to the Trusted Locations list in Excel (client side solution)
The best thing to do is #1. You should not be serving files with one data type as another file type. It's always generated a warning for users. Many Office clients that otherwise know how to open XLS files (such as Office for iPad) will choke when presented with an HTML file masquerading as XLS.
Instead, use a library to generate a modern XLSX file (which can be opened by Office 2003 and newer). There are several solutions such as EPPlus, NPOI, and Open XML SDK.
In the future, be careful to use supported solutions rather than cobbling together a hack like serving a file with the wrong extension.
I'm building an application that takes as an input data stored in an Excel sheet. I want the user to be able to select the file they want to load data from, have the application connect to and read from the Excel file stored on the client's machine, and close the connection. Can I do this without uploading the Excel file to the server? I'm able to do everything except for selecting the file using a filedialog box and passing the path & file name to the procedure that connects to the Excel file and processes. I've tried using the file input control but I'm unable to pass the path & file name to the connection string. Any suggestions as to what other routes I might take?
EDIT:
The application essentially takes user input, either via single inputs into textboxes on the page or a bulk upload via an Excel spreadsheet, processes the inputs and spits out a report in Excel format. The only thing displayed on the page are the loaded inputs (via the 2 methods just described) in a listbox that the user can either add or remove additional items.
The short answer is "Only with an ActiveX control in IE unless you write your own plugin for another browser." My opinion is, "you shouldn't."
There is a good discussion already on Stack Overflow: How to read an excel file contents on client side?
The long answer, given the rest of the information you have provided, is that I would recommend the following:
1) Upload the spreadsheet to the server.
2) Extract the data on the server.
3) Return the data to the client in whatever form suits your situation.
4) Clean the original file on the server.
Some further recommendations for you, since you provided so much detail in your comments:
Rather than using a GUID to generate your server-side filename, use a timestamp in the format YYYY-MM-DD-HH-MM-SS-Ticks followed by the original filename.
Instead of deleting the data files immediately, each time you add a file, remove any files older than N days.
This way if you have any issues processing your files in the future, you'll be able to retrieve the uploaded file to your development environment and debug it there. Assuming the data isn't personal information or sensitive in some other way, of course.
Cheers!
So, We pull solutions from TFS. The solution files on TFS are fine. However, when I edit them on my computer sometimes the code will turn to gibberish (particularly, I'll edit them, save them, close them, and open them later when this happens). It's happened with both .NET files and classic ASP files. When I go "Save As" it says is a binary file. Does anybody know how to prevent this? I'm tired of losing work.
Your problem is the encoding of the file that you or member of your team save the file with.
The encoding should be matched and better to be UTF - unicode.
Stand on some file -> goto file-> save as -> on the save button you'll have a little black triangle on the side -> press it -> you'll see with which encoding you are saving the files.
Make sure that all the members of the team set the defaults of saving to the unicode encoding.
I'm making a web app. Part of it includes the automatic generation of word documents (letters). Those documents need to be opened by the end user, then saved back to the server once they've finished editing.
I tried using webdav for this but the only browser I could actually launch word from (using active-x) was IE. I also found a plugin for firefox, but for Chrome I couldn't find a way that worked.
Next I thought about making the clients map a drive to webdav (or similar), then offering up the files as file://... links, but that only works if the webpage is on the local machine.
Before I resort to ditching word (the clients won't like this) and using CKEditor or TinyMCE, is there another way?
In short, I'd like to have links to a document on the page, which when clicked are opened in word, but the file should stay remote - and then when saving, it's the remote file that gets updated.
I've also looked at Zoho but it could be very expensive for this project, plus I don't think it can be white-labelled and also looks a bit old fashioned, UI wise.
Maybe Sharepoint can do what I need? Haven't looked at that much. Also thought of making a client app to run in the system tray and deal with things.
If there was a decent way of editing Word docs from within the browser with something like CKEditor/TinyMCE and once finished, conversion back to Word format actually worked 100%, that would suffice.
I'm open to totally fresh ideas if anyone has any...
Currently Chrome, Firefox and Safari support MS Office plugin. They can open and save documents directly to server. I have tested this with MS Office 2007 and MS Office 2007 just about a month ago.
Ideally, your users would be able to use Word natively. Is there any chance you could create an Office Add-In that hooks into the BeforeDocumentSave event, looks for some indicator that the file is associated with your application, and save the updated file to your server?
Saving to the server via the Word Add-In would probably need to include some unique identifier (in addition to file name), so you could overwrite the previous version server-side. Then, if you were using something like SignalR, you could trigger a refresh on the web page when the file was saved successfully (assuming they were still on that web page) on the server (via FileSystemWatcher).
Had same problem myself.
I solved it by setting up a webdav share on the server with digest authentication (SabreDAV), and tied it into the users table on my app backend.
In relation to the client end, I solved accessing this by creating a small java applet which uses the java Desktop class (getDesktop().open()) to open the file. You will need to make sure the path is handled right for the client machine type (Windows, OS X or Linux)
You will also need to get your end users to permanently mount or map the webdav share locally.
In an AIR app you can use SQLite via the flash.data classes. It appears that by default the encoding of the database created is set to UTF-16le, which means that textual data is stored with two bytes per character, resulting in a nearly 100% overhead for ASCII-heavy database content.
The default for a SQLite database is UTF-8, assuming the shell program (sqlite3) is indicative. Presumably Adobe has decided to override this for some reason, but I'd prefer not to suffer the wasted storage space if possible.
A PRAGMA encoding = "UTF-8"; statement prior to writing anything to the database would normally resolve the issue, but it appears that's not allowed in AIR either.
My workaround for now is to use a "template.db" that I create ahead of time and bundled into the application. In this template.db I've set the encoding to UTF-8 manually. If the database file does not exist already when my program starts, I create it by copying that template to my database file, then proceed to open and use it normally. I've confirmed that TEXT data is then stored as UTF-8, as desired.
I haven't seen any ill effects yet, but this is hackish. Is there a better way to set the encoding to UTF-8? Or is it a Bad Idea for some reason?
With no other workarounds or answers found, I'm posting my workaround as the Answer. It worked fine in a PlayBook app for the last two years, so presumably has no unforeseen side-effects, at least in that environment:
My workaround for now is to use a "template.db" that I create ahead of time and bundled into the application. In this template.db I've set the encoding to UTF-8 manually. If the database file does not exist already when my program starts, I create it by copying that template to my database file, then proceed to open and use it normally. I've confirmed that TEXT data then now stored as UTF-8 as desired.
you may check the execution source file of the project like /bin/debug in C# Visual Studio projects.
The changed committed is not necessarily be executed in your db located in other folders.