I recently added a way for my web application (ASP.NET written in C#) to go to a folder which contains a bunch of spreadsheets and import them into SQL server tables. I set the folders and file names using an admin table so it knows how to handle each file and which table they should go to etc. It even keeps track of the file dates and times so it ignores anything that isn't new since the last time it imported them. Very cool but it only works on my development machine, most likely because the path is easily recognized there.
I'd like others to be able to do this but I can't seem get the web application to access a pre-arranged path on the users local machine. Now I'm assuming this is normal (we shouldn't be able to have a web application reach into someone's machine and grab files!) but is there some way to either do it using a known path or by having a user select the local folder? Is it possibly done more easily if I put the files in a folder within the site?
Dana
If I understand your question correctly, the approach is that you want a user to type in a local file path and you process it.
This will not work through a website. And from a security perspective this is very wise as you point out. So unless you install some client application on the local machine it is not possible.
You will need a file-upload dialog and have the user explicity locate the files for you, click upload and process them on the server.
Some other strategies here:
https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications
but it still requires the user to select them manually.
Related
I have a Windows forms application that uses Application settings using the .NET settings class.
Typically I have a setting such as WindowXSize which is loaded when the program starts, and saved when it ends as follows:
Properties.Settings.Default.WindowXSize = 400;
Properties.Settings.Default.Save;
On load it is just the reverse.
Now this works fine and I have thousands of users with no issues. However, if someone has configured MicroSoft OneDrive to replicate their documents folder, the values never change even if the window is resized.
Not only that, the software can also allow users to save various files in a folder of their choice. Most of the time this is in the documents folder (or subfolder of it). To make sure I get the correct location of the Documents folder I have the following:
path = System.Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
This always returns the typical c:\users\userid\documents folder even if OneDrive is syncing the documents folder. The user can then save the file and there are no errors. However, if the user then tries to load it, the file is not found. So it would seem that OneDrive is completely ignoring the .NET mechanisms for Application settings and file IO.
Is there any work around for this? Or am I doing something wrong?
Note that I refuse to load up OneDrive for my documents on my development machine so as to avoid all these issues as well as many others that exist.
Thanks, Tom
Did you change the directory, where your application stores the user settings?
Default is:
"User settings are saved in a file within a subfolder of the user’s local hidden application data folder." 1
Normally OneDrive does not synchronize this hidden AppData folder. Therefore your question makes little sense. Please add more information.
In my web-app (WebPages, C#.NET) I have a drag and drop file box where user's can drag files from windows explorer and, once dropped, it will save in a given location on a shared drive. This part is working fine. The box looks something like this:
The problem is, that it also reads files from the same directory and my user's would like to be able to open the files from this interface on dblclick. I have written an ajax request with jquery (the ajax, too, is working fine), but I can't seem to get the files to open on the user's machine no matter what I try.
Most references I try and look up point me towards System.Diagnostics.Process.Start(#"<directory goes here>") but this doesn't really do anything. It will open some process on the server side, but nothing opens, either on the server or on the user's machine.
What they'd like to do, for instance, is double click 'Hazcom.xls' and it would use the default associated application to open the file. In this case, of course, Microsoft Excel.
Is this even possible or am I chasing a wild goose here?
Sources I've Tried:
Open file with associated application
http://www.csharp-examples.net/open-file-with-default-application/
How can I open Windows Explorer to a certain directory from within a WPF app?
c# open file with default application and parameters
There have been a few more sources I've tried, as well, but they're all pretty much in the same vein as these.
Additional Info:
The internal Intranet application runs on a server using IIS 8
The solution is desired to be opened on the user's machine and not, say, the server itself.
The path to the files is dynamically changing depending on what they have loaded into the interface.
Though, I'm not expecting this to be a solution viable for client side (jquery) I'd be happy to look into that if that's the only solution available.
I'd also settle for simply opening the file location, instead of the actual file itself, but I've had no luck with this either, for what looks like the same reasons as the original problem.
I'm trying to find a way to write "meta" information to EXE files that are uploaded to my IIS/ASP.NET web service. Here's a little bit of background:
I need to write one arbitary string into the properties
It'll be URL that I write as "metadata", if that matters
Example: https://example.com/someFolder/someOtherFolder
The files are mainly installers originally created by InnoSetup
The web server is running IIS 7.5 with ASP.NET on top of Server 2008 R2 (Standard)
Why am I trying to write this information?
Ultimately the EXEs are made available to users for download. When the application runs, it needs to know the web URL in order to execute properly. Currently we have a plain text box where the user can input the URL, but that has proven to be error prone (despite prompting/error checking/...)
Why can't I just write the metadata in the EXE when it's created?
I could do that, but the EXE could be uploaded to a variety of different servers, each with their own unique URL "metadata". I'm trying to avoid creating a separate build script for each server.
Why not just create a *.zip file with the *.exe and an extra piece of metadata?
I suppose I could do that too -- but then the user would have to actually unzip the download so that the real installer could read the metadata. I had something similar to this before and most people never unzipped the full download and that posed its own problems.
So is this even possible? I guess as a last resort I could use the uploaded EXE to create a new EXE, but I'm trying to avoid doing that (gets into problems with signed EXEs, etc.)
1) I am developing a desktop application that connects to a access database to store some information. This access database is on a server. I can get to that server using FTP sequence. The server also has the capability to establish connection to access database. Right now, my application downloads the database file into a folder on the computer edits it and puts it back on the server. I would really love to know if its possible to connect to the access database, make changes to it all without downloading it so that I can save time.
2) If its not possible to do what I was asking for in question 1. Say, I share my application with my colleges and I want them to be able to do the same with the database editing. after I make an .exe file out of my project and send it to them. Do they need to install ACE.oledb.12 on every computer that I want to run it on?
As Access is a file based system rather than a dedicated database server, "remote connections" don't exactly exist as all data processing has to be done locally. However as long as you are able to setup either a VPN to the server where the Access file is stored, or even better map the path as a network drive then you should be able to access it without having to download the file first. If you only have FTP access though then it wouldn't be possible.
If all you are using is Jet/ACE, the database that Access normally uses, the other users will at least have to have the drivers, which are free, or if you are working within Access itself, you will need the runtime, also free.
Actually, your terminology you using is wrong. You don't connect to a word file. You don't connect to a power point file.
So you have to keep in mind here you are not really connecting to some text file or mdb file that just happens to be sitting on a hard drive.
You are thus simply opening a file.
I mean it is silly to say we connect to a word file, or we connect to a Power point file. So in the case of the office suite and those basic simple files that resides on the disk drive?
We are talking about plane Jane windows file.
A horse is a horse is a horse.
A file is a file is a file.
So you don't connect to the jpg file sitting on the hard drive, you OPEN the jpg file. So if you talking about your current setup it best to use the correct terminology here. You are not connecting to that Access accDB file, but are in fact opening a PLANE JANE windows file. If you look close at your connection string, it will ALWAYS have a fully qualified windows path name in it that resolves to a file sitting on a folder.
So if you place that file on some server, say web server, then then you still faced with having to open that windows file. This is NOT ANY different than wanting to open a power point file. That means if you going to connect over the internet then you need to EXTEND the windows file system (this means you will need some kind of VPN). At the end of the day, if you cannot use windows networking to browse and open the folder where that file resides, then you cannot open that file with Access (or more specific in your case the JET data engine).
So for example, if the server where the file resides is a non windows box, say Linux, then you need to "add or use" or "install" the windows file and networking system on that box. A common choice in Linux is to install and run Samba on that computer.
Keep in mind that in the case of using SQL server, then you are connecting to a SERVICE running ON THAT server. In this case then you not opening a file on the remote box, but are simply are using a socket (TCP/IP) connection to some service. So you not just opening a silly old windows file that happens to be an accdb file on that system in this case.
So as such when you use FTP or http, these are not real "windows" networking systems that allow you to open + use a plane Jane windows file.
FTP will require the WHOLE FILE to be downloaded local.
PROBLEM!
If the web site or web server has the accDB file open, then how are you going to have the web server CLOSE the file BEFORE you upload and OVERWRITE the file? In other words, if that file is open by the web server, then you should NOT be making a copy and even downloading a copy via FTP until the SERVER AND WEB SITE CLOSES THE FILE! This means you NEED permission to STOP the web server while you do this!
So as such, just keep in mind the concept here that you are NOT connecting to some file, but you are just going to OPEN the file. You need to be able to OPEN the file, and you need to be using the windows networking system to do this open file in the case of Access. I mean, you don't have to install Access(JET) on the target computer. You don't have to install Power Point on the target computer to open a power point file.
You don't have to install word on that system to open a word file.
You don't have to install Excel on that system to open an Excel file.
So you are ONLY opening a file that just happens to be on some other computer.
So the Access database engine and software MUST be installed on your computer (no .exe possible here). You can most certainly package up your application as an installable windows application that then can be installed on each computer. So a free edition of the Access runtime is available, but you still going to have to install that free version of Access on computers that use Access, even if it is the free runtime edition. However, these days, I not really aware of any popular development system that produces just .exe files without requiring a runtime of some kind, be it .net, VB6, Java, or in this case Access – so some kind of support and runtime files are quite much a common requirement in most systems in use today.
So, just keep in mind you are opening a plane Jane windows file.
As such, your path name of http, or FTP is not a allowed windows path name and is not a windows file/networking system. As such a path name has nothing to do with windows networking and opening of a simple file sitting on the hard disk. So HTTP or FTP etc. are not based on windows networking and file system.
I don’t think this basic concept is too hard to grasp, but at the end of the day the concept you need to grasp and learn is that when you open a windows file sitting in a folder on the hard drive, then then will you need the windows file system to open such files. The idea and concept of opening a file in a folder might be new to you, but it is a basic requirement and understanding you need to solve this issue.
As noted, you can consider a VPN, but I explain why such a setup is not going to work in this article:
Using a wan with ms-access? How fast, how far?
http://www.kallal.ca/Wan/Wans.html
(do read the above – as it explains that you CAN open such files over the internet, but ALSO explains that such connections are WAY TOO SLOW! – remember high speed internet is WAY TOO SLOW here for this use!).
I suppose another possibility would be to consider the new web publishing ability that Access has. In the following video note how I switch to running the Access application 100% in the browser. The resulting application does not need any ActiveX or Silverlight. So the web pages run + work fine on my smartphone and even my iPad.
http://www.youtube.com/watch?v=AU4mH0jPntI
So you can use the new web publishing feature, and that would allow one to use http: to use the application
I have a website that occasionally needs to have a handful of the tables in its database updated. The updates come from another system that exports to comma delimited text files. I can then either FTP the text files to the web server, send them in through an admin upload page, or manually log in to Remote Desktop to download the text files. I have all my C# code written to parse the files, check the database contents, and decide what to do.
Should I code the sync logic to be part of a file upload page, protected in the admin section of the site or should I create a Windows Service that constantly looks for files to process in a particular directory that I can drop files in through FTP?
I have used Windows Services in the past and they have worked great, but if I ever have to make a change to the code it can take longer than it would if I just had to modify an ASPX.
Are their security benefits one way or another?
Performance benefits?
ASPX page wins the "ease of maintenance" category.
I would create a Windows Service to watch a secure folder and use a directory watcher to look for new files. Since the files are coming from another system, it is asynchronous in nature, and it is much more performant to have a Windows Service running separately to watch for updates as they happen. It can also parse the files and update the database for you.
Depending on who maintains the remote system, the easiest way is to grant permission to the service to access the files on a secure, shared folder. Then you won't need to do anything manually.