I am attempting to connect to my Google Drive using C# and the Google Drive API and then map that as a network or local drive. There are other programs I know that do this like NetDrive (which is extremely useful and robust), but I am looking to create something on my own. I have created a project in the developer console and have been able to connect to Drive using my application and do various read and upload operations, so I know that particular portion is ok. Access and permissions all seem to be set. I just have no idea where to start when it comes to mapping that storage as a usable drive in Windows. Any advice would be most helpful, thank you very much!
There are two basic components for implementing a NetDrive/WebDrive type of solution. What you are looking at is the creation of an Installable File System and Network Provider.
The Network Provider, or NP, is the user mode component that handles the Network layers, including the mapping and unmapping of the drive letter, along with lots of other fairly complicated UNC/Network stuff. To get an idea of what you are in for, check out the Win32 WNET*() API; you will need to implement all of the WNet() calls specifically for your IFS and 'network'.
When you are done, you'll probably have the ability to to do a "net use \MyWebDrive\" in DOS and Map Network Drive in Windows Explorer. You might also be able to use Windows Explorer to enum the contents of the remote file system.
However, now you need to make sure that all third party applications can access your network drive...to do that, you want to implement the Win32 File System API, such as CreateFile, Read(), Write(), CloseHandle(), FindFirst(), etc.
To do this, you can write an Installable File System Driver, FSD, to handle all I/O calls from User mode applications wanting to read/write to the files on that mapped network drive. This will most likely be a Kernel Mode application...a signed/certified file system device driver....probably written in old-school C and maybe even utilizing TDI depending on how you want to do your network IO.
Microsoft is becoming much more strict about installing 3rd party kernel mode drivers and network providers. The WebDrive file system driver is now securely signed using a Microsoft based TLS certificate and our Network Provider has been registered with the Microsoft Windows SDK team as a legitimate Network Provider for the Windows platform.
Once you get these pieces in place, you'll then want to think about Caching. Direct I/O through your NP/FSD over the wire to Google is not practical, so you'll need an intermediate caching system on your local drive. There are lots of ways to do that, too many to go into here. However, just keep in mind that you may have multiple user mode applications reading and writing to your network drive simultaneously (or one app like WinWord which opens multiple file handles), and you'll need to be able to handle all those requests with proper locking and ACLs, and then map those changes and access rules to the remote server.
Don't lose faith...what you are looking to do is possible as WebDrive and NetDrive have shown, but it's not really a project that can be knocked out in a few weekends. I'm not sure about the author of NetDrive, but we've been developing WebDrive full time since 1997. It seems that every Windows Patch changes something and every new version of Adobe/Office/XYZ does something quirky with IO calls that makes us pull our hair out.
Note: There's also another way to implement this beast which may get around the FSD, it's the DropBox strategy. Using a temporary folder on your local hard drive, leverage Directory Change Notifications in a User Mode application to monitor file changes in the folder and dynamically synchronize the changes to the remote end. GoogleDrive and a lot of the other online storage companies do it this way because it's quick-&-easy; however, if many changes occur in a short period, a Change Notification could get lost in Windows Messaging and data might get trashed.
I realize this is a lot to digest, but it's doable...it's cool stuff; good luck!
I suggest that before you start coding, you take time to thoroughly understand Google Drive and map its capabilities to/from Windows. Some sample points of impedance:-
folders in Drive aren't folders at all
A file in Drive = the metadata, content is optional
Drive has a lot of metadata that doesn't map to NTFS (eg. properties)
Will applicable files be converted to Google Docs, or stored as is
How will you map revisions
Permissions
There are almost certainly more, this is just off the top of my head. Your app needs to make decisions regarding all of these aspects. Generally, Drive offers more capabilities than NTFS, so provided you are simply using it as a backup repository, you should be OK.
Related
Need to create a service application that monitor all files being downloaded. I was thinking about using the file watcher class but some end users can change the download directory. Any idea would be great.
Monitoring file system is no indicative of download activity, as you already figured out. Browsers do not expose a cross-platform API to report download events. Browsers plugins do, but that requires the plugin to be loaded, enabled and you'll need separate plugins for each browser out there. So the only sensible approach is a filter driver. In fact the OS exposes a handy helper layer specifically designed for this, the Windows Filtering Platform. Of course, C++ and networking expertise is required. Detecting downloads from all traffic is left as an exercise to the reader.
If you want to monitor files downloaded on computers in an office environment, your best bet would be to install a proxy server.
I've designed a C# game that makes use of an Access .mdb database file to store variables.
The basic idea is that one of the players will 'host' a game, and the other player will join said game, by connecting to the database, reading and writing items into the database. The database is needed to pass variables to and fro the host and client, and both programs check the database regularly for new messages / variables (yes, yes, I couldn't get TCP/IP Remoting to work).
Now, there, the program works fine (mostly the client, since the host modifies only its local database), for as long as the client can find the database file. Currently, the connection string for the client is located in a .ini file, and for the program to work, it (or at least, the server) must be located in the Shared Documents of an XP machine, or the Public Documents of a Vista / 7 machine.
But then some questions occurred to me:
What if the client user places / installs it into another folder in the Shared / Public Documents? I suppose there's a code out there that could 'drill' into the Shared Documents folders to find the path for the database, share names included... is there?
What about installation? The installer default is always "C:\Program Files\GameName". Could it be set (or locked) to a specific folder into the Shared / Public Documents, by default? And is it even recommended to install it into a Shared Folder, what with problems such as Accidental Deletion?
Say, the default is "C:\Program Files\GameName". I could see that a set installation path will solve any connection issues, since every client will look in the same path of the other computer, and it won't matter if it's XP or Vista. Could "C:\Program Files\GameName" be accessible by a C# program over LAN, without any system modification? Are there any security (UAC?) issues?
P.S. Details that people may find in handy:
I'm using Visual Studio 2005. So is my School.
I'm running .NET framework 2.0. So is my school, and unfortunately, I can't change that.
I hate to tell you this, but this is why the approach is fundamentally flawed. What are you going to do when:
File and print sharing on the server is disabled?
The network client is disabled on a client computer?
The server is configured to only allow authenticated users, and the client doesn't have access?
File and print sharing is blocked because of the firewall?
File and print sharing is completely borked for other who-knows-why reasons?
You need administrator access on the server to share a folder, but the current user is not an administrator?
The Access database engine isn't installed correctly on the server or client?
One of the clients corrupts the database? (This is easier than you might think; all it takes is a network glitch where a client temporarily or permanently disconnects from the server).
These are fundamental issues that you can't resolve with the current solution.
Get it working over normal TCP/UDP ports. You'll have a much easier time. There are libraries to facilitate that, see C# Game Network Library - for example it sounds like Microsoft's XNA SDK has functions for networking in a game. If you use a standard method / standard library to implement networking, your odds of success are much higher. Using a client/server architecture means that the server's state won't be corrupted if a client goofs up.
I realize that this probably involves a significant rewrite. Frankly, I don't think you have a choice if you want this game to be commercially successful on a wide customer base without high support costs, and move beyond being a mere experiment.
Get rid of the access database. The described architecture is already 'user unfriendly'
Use either SQL Express or SQL CE which requires no installed database binaries (they can all be included in the applications folder). This way the db will stay in the applications folder (ideally app_Data) and .Net has included support for databases in this folder.
Please stay away from access you will save yourself a lot of trouble.
http://blogs.msdn.com/b/sqlservercompact/archive/2011/01/12/microsoft-sql-server-compact-4-0-is-available-for-download.aspx
I think that there is little point in using Access unless you wanted to use any of the pretty form-based IO that you can you do with its designer. And I doubt that'll be the case here.
I would encourage you to replace all your file IO with a sound data access layer.
Which will rid you of all the "sharing" issues that you are experiencing, file locks, the overcomplicated installation process, etc.
Alternatively to SQL Server Express as suggested above you could also use SQLite http://code.google.com/p/csharp-sqlite/
I'm a C# noob and i want to ask if it's possible for this kind of scenario:
I have a windows form app in C#, is it possible i will only install it in 1 computer(as a server) and it can be accessible from all the computers within the network? If it's possible can you please help me what i need to do, any reference/books/tutorials?
I already googled this but i think i can't find the correct 'search word' that's why i didn't get the desired search result.
Yes it is possible. Put the C# executable in a network UNC Path, and you can access it if you create a link on the destination desktops. XP SP 2 and higher by default can run it. If it has .NET 3.0 or 3.5 or 4.0 framework you may need to install the Runtimes for those frameworks, but .NET 2.0 should be fine with XPsp2. All the frameworks are downloadable from Microsoft's site.
Is this a database driven app or just a straight up stand alone?
You don't need any books, it should work just fine. But provide as many details as you can so we can steer you in the right direction.
You may have to do a large code overhaul to do this. Could you simply install it on one computer and remote login to that computer and access it?
You see the thing about network-accessed programs is that they have two parts--a client and a server. It sounds like you just have one piece. You would need to write a program that is a windows form and install it on all the machines. You would then need to write your server code that receives the data from the client over the network.
You would need to know about socket programming. Here is a book introductory tutorial of C# and sockets.
http://www.codeproject.com/KB/IP/socketsincsharp.aspx
I'm not 100% sure what you're asking, but hopefully this covers it. If not, please edit your question to be more specific.
You can generally run a WinForms application from a shared network drive/folder by copying the executable to that drive (and making sure that all users have appropriate access to that network location).
If you use an automatic installer, it should be possible to select a network share as the place to install the software. Automatic installers tend to also put things in the local registry (e.g. create menu items for the program, which go on the local computer always). In that scenario, you would want to create an installer that creates appropriate shortcuts/menu items on the local computer that point to the pre-installed executable on the network share.
You need to take care that the windows forms application doesn't write data to the network share, or if it does, that it does so in a manner consistent with multiple users accessing that data (in other words, keep in mind that all of your users will share that location).
Put it in a shared folder and access either by UNC path or map a drive to that location. You could also map the drive for all users with group policy.
Alternatively you could wrap your app into an MSI and install it via group policy?
Hope this helps :)
You should use a layered approach to your software design. Create a website to give users access to the application from multiple locations. Then create a service layer to give the website access to the desktop functionality that you require. WCF is a good service layer as it allows consumption through HTTP.
I am scratching my head about this. My scenario are that I need to upload a file to the company server machine(to a folder on c:) from our hosting one(totally different server). I don't know how I should do this. Any of you got tips or code on how this is done.
Thanks Guys
I would set up an FTP server (like the one in IIS or a third-party server) on the Company Server. If security is an issue then you'll want to set up SFTP (secure FTP) rather than vanilla FTP since FTP is not a natively secure transfer protocol. Then create a service on the Hosting Server to pick up the file(s) as they come in and ship them to the company server using C#/.NET's FTP control. Honestly, it should be pretty straightforward.
Update: Reading your question, I am under the strong impression that you will NOT have a web site running on the company server. That is, you do not need a file upload control in your web app (or already know how to implement one given that the control is right in the web page toolbox). Your question, as I understand it, is how to get a file from the web server over to the company server.
Update 2: Added a note about security. Note that this is less of a concern if the servers are on the same subdomain and won't be routed outside of the company network and/or if the data is not sensitive. I didn't think of this at first because I am working a project like this now but our data is not, in any way, sensitive.
Darren Johnstone's File Upload control is as good a solution as you will find anywhere. It has the ability to handle large files without impacting the ASP.NET server memory, and can display file upload progress without requiring a Flash or Silverlight dependency.
http://darrenjohnstone.net/2008/07/15/aspnet-file-upload-module-version-2-beta-1/
There isnt enough info to tell your whole hosting scenario but I have a few suggestions that might get you started in the right direction:
Is your external server owned by another company or group and you cant modify it? If not you might consider hosting the process on the same machine, either in process or as a separate service on the machine. If it cannot be modified, you might consider hosting the service on the destination machine, that way its in the same place as the files need to show up at.
Do the files need to stay in sync with the process? I.e. do they need to be uploaded, moved and verified as a single operation? If not then a separate process is probably the best way to go. The separate process will give you some flexibility, but remember it will be a separate process and a separate set of code to manage and work with
How big is the file(s) that are being uploaded? Do they vary by upload? are the plain files, binaries (zips, executables, etc)? If the files are small you have more options than if they are large. If they are small enough, you can even relay them in line.
Depending on the answers to the above some of these might work for you:
Use MSMQ. This will work for simple messages under about 3MB without too much hassle. Its ideal for messages that can be directly worked with (such as XML).
Use direct HTTP(s) relaying. On the host machine open a HTTP(s) connetion to the destination machine and transfer the file. Again this will work better for smaller files (i.e. only a few KB since it will be done in-line)
If you have access to the host machine, deploy a separate process on the machine which builds or collects the files and uses any of the listed methods to send them to the destination machine.
You can use SCP, FTP (of any form SFTP, etc) on either the host machine (if you have access) or the target machine to host the incoming files and use a batch process to move the files. This will have a lot of issues to address, such as file size, keeping submissions in sync, and timing. I would consider this as a last resort, depending on the situation.
Again depending on message size, you could also use a layer of abstraction such as a DB to act as the intermediate layer between the two machines. This will work as long as the two machines can see the DB (or other storage location) and both act on it. SQL Server Service Broker could be used for this purpose (and most other DB products offer similar products).
You can look at other products like WSO2 ESB or NServiceBus to facilitate messaging between the two apps and do it inline.
Hopefully that will give you some starting points to look into.
Is it possible to write a filesystem for Windows in pure usermode, or more specifically purely in managed code? I am thinking of something very similar to GMAILFS. Excluding what it is doing under the covers (GMAIL, Amazon, etc..) the main goal would be to provide a drive letter and support all of the basic file operations, and possibly even adding my own structures for storing metadata, etc..
Windows provides several approaches to building a user-mode file system for different purposes, depending on your storage location and features that you need to support. Two of them, Projected File System API and Cloud Files API were recently provided as part of the Windows 10 updates.
Windows Projected File System API
Projected File System API is designed to represent some hierarchical data, such as for example Windows Registry, in the form of a file system.
Unlike Cloud Files (see below) it does not provide any information about file status and hides the fact that this is not the “real” file system. Example.
Windows Cloud Sync Engine API
Cloud Sync Engine API (Cloud Files API, Cloud Filter API) is used in OneDrive on Windows 10 under the hood. It provides folder content loading during the first request, on-demand files content loading in several different modes, and offline files support. It integrates directly into Windows File Manager and Windows Notification Center and provides file status (offline, in-sync, conflict, pinned) and file content transfer progress.
The Cloud Files API runs under regular user permissions and does not require admin privileges for file system mounting or any API calls. Example.
Windows Shell Namespace Extensions API
While Shell Namespace Extension is not a real file system, in many cases you will use it to extend the functionality of the Projected File System and Cloud Files API. For example, you will it to add custom commands to context menus in Windows File Manager as well as you can create nodes that look and behave like a real file system (again, applications would not be able to read or write to such nodes, this is just a user interface).
Cloud Files API is using a namespace extension to show your sync root at the top level in Windows File Manager.
It's difficult. I'd take a look at some projects which have done some of the hard work for you, e.g. Dokan.
Yes. It's possible and has been successfully done for the ext2 filesystem.
Note that you will need to write your own driver which will require Microsoft signing to be run on some OSes.
Sure, you can abstract the regular file operations and have them running in the cloud (see Google Apps, Amazon S3, Microsoft Azure etc.). But if you'd like to talk to local devices - including the local HD - you'll have to use system APIs and those use drivers (system/kernel mode).
As long as all you want is a storage service -no problem. If you want a real OS, you'll need to talk to real hardware and that means drivers.
Just as a reference - our Callback File System is a maintained and supported solution for creation of filesystems in user-mode.