Develop Reference

Looking for a Best Practice: Communication between 2 Applications for Filebrowsing and Download

I'm sorry if this Question is redundant but I'm totaly confused and I need some advice for a Best Practice. It's just for learning purposes but for me this is important because I want to figure out how to do things in the best way.
I want to create an application that let's me Browse the Filesystem of my second PC over the Internet connection, not the lokal Network. So, on PC1 I want to have a small Application (App1) that shows the Filesystem in something like a Listbox with simple Navigation (Doubleclick to open a Folder ad a Button to go up one Level in the Filesystem) and a Download function that let's me Download a File from this PC an on PC2 is the counterpart (App2) that interacts with the Application on PC1. App2 reads the Fileysystem and sends the Folder and Filenames to App1 and App1 asks App2 then to get a specific File.
Now I have to specific Questions:
What technology is the best for communication between those to applications while communicating over the internet? WCF? My own protocol over a socket connection? Something else?
How can I manage to download a big File in several session? If the connection drops I want to resume the download and not start all over again.
I hope someone can give me a hint
Thank you very much
CaptnCrash

Use the FTP protocol for this. On the second PC install and configure an FTP server application, and then in your C# client code, use something like http://sourceforge.net/projects/dotnetftpclient/ to do the FTP protocol work.
Alternately, if you really need encryption of communications, use HTTPS which means configuring a web server on the second PC and using something like the System.NET classes to implement a web client.
Whatever you do, do not write your own protocol and do leverage existing .NET libraries to handle the lower level FTP or HTTP communications.

How to modify HTTP responses in a different .NET process

I have a standard web server that serve web pages.
I want to monitor traffic on port 80, intercept every http responses, and add/inject an additionnal header to them.
The process will then act like a proxy between the web server and the client.
Could you please give me some pointers? I'm already aware of SharpPCap, but I'm not sure where to start.
Note: I can't rely on the web server, I can't control it or change it's configuration. However I can install any other process on the same machine.
Thanks a million

I think that SharpPCap is an overkill here.
Try:
listen on a port (say 8080)
for each incoming connection, accept and open one to the server (original one, port 80)
pass everything that comes in from the client straight to the server
pass everything that comes from the server back to the client, monitoring the stream and injecting/modifying if needed

I think what you want to do can be done with IIS 7.0 URL Rewrite module instead of rolling your own code.
http://learn.iis.net/page.aspx/711/modifying-http-response-headers/

Question about C#, servers, XML

So I'm working on a project for my internship and have hit a bit of a brick wall. Unfortunately, the only people I know who are qualified to help me at the office are on vacation at the moment, and Google has been unfortunately unhelpful (or my search skills inadequate), so I thought I'd ask here.
The project is basically to make a server to mimic one that the company (which makes phone apps) already has. What I need to do is have one of their apps send a request to my server (I will have to modify the app to do this, but don't know how), and have my server reply with an XML response that the app already knows how to process. (The main purpose is so that we can see how the app responds when the real server sends it an error by simulating it on my server.)
Now, I already have a few sample HTTP requests and their associated XML responses handy, taken from simulations with the app and the real server. The app is written in C#, and currently sends HTTP web requests to the real server's online location, which responds to these HTTP web requests with XML. My server, however, will not have an online location, so the app will have to be modified to work with sockets on a local host.
My questions:
1) My boss said to create an XML file to associate certain requests with certain XML responses, but I have no idea what he means or how to do this. (He said it could also be done with a .ini file.) Does anyone know?
2) Once I have this XML file that can make these associations, how can I incorporate it into my server so that my server can check the request it received against its table of valid requests and figure out which response to send back?
3) How can one modify the app from using HTTP web requests and responses to using sockets?
If you have any questions/clarifications that you need in order to better answer this, please don't hesitate to ask me.
Thanks!

What you're describing is a web service. Unfortunately, his advice to change a setting in an .ini file make it sound like they have a proprietary system for doing this, rather than using a standard ASMX (which requires IIS) or WCF (which can either run in IIS or as a standalone service, which it sounds like is what you'd want) service.
Without more information about what they're using, I don't know that you'll be able to get much help here.

In response to question #3:
HTTP is a protocol that already runs on a specific socket (normally using port 80).
An internet socket is an endpoint that is used to transport data between processes. If you want to run your own protocol, you will need to create a new socket (with TCP or UDP) on a specific port.
This will however require you to create your own client and server in order to exchange data between them.
To get started, here is a very simple client-server example in C# using a custom socket.
Good luck!

Ask your boss if this client communicates with soap, if so then just go to MSDN and find tutorials on implementing an ASMX webservice, follow the tutorial through and you'll have a shell to start with.

First I'd like to say that it sounds like you have some unclear requirements that you should probably clarify with your boss. If you're not exactly sure what he means you should find out because nothing sucks more than having to support someone's creative interpretation of requirements.
1) It sounds like your boss just wants a way to easily change associations for testing without having to rebuild the app so he's asking you to store those associations in an xml/ini file that can easily be modified. In c# you can easily go between XML and DataSet objects so this should be trivial. I would create the data structure in a DataSet first and then use the GetXml method of the DataSet to output the xml format.
2) In .NET you can store objects in Cache and create a Cache Dependency that is a file association. Thus whenever the file is modified the Cache is purged. Whenever your program handles a request it pulls the object from Cache, if the object isn't in Cache then you have a condition block rebuild it from the xml/ini file on disk. I would have that condition block call out to a function that then loads the above mentioned xml format into a dataset that is then stored in the Cache with a Cache Dependency.
3) If you are trying to test an applications i/o, modifying it to use a different transport layer sounds like a bad idea. If the app currently works over HTTP to send requests then just route the HTTP request. I would suspect that the app probably has a configuration somewhere defining the path of the webservice it currently calls out to, once you know what that path is you can either change it, or if that's not possible setup a DNS rule on the server running the app to route it to the location of your application. On windows this is as simple as adding a line to the hosts file.

Available options for hosting FTP server in .NET application

I need to implement an FTP service inside my .NET application (running as a Windows Service) and have not had much luck finding good/current source code or vendors. Ideally it needs to be able to respond to the basic FTP Protocol and accept the data stream from an upload via a stream, enabling me to process the data as it is being received (think on the fly hashing).
I need to be able to integrate it into my service because it will stack on top of our current code base with an existing custom TCP/IP communication protocol. I don't want to write (and then spend time debugging and performance testing) my own protocol, or implementation.
I have already found plenty of ftp client implementations, I just need an acceptable server solution.

There is an article about rolling your own FTP server in C# here. It's a bit old, but it might be complete enough for your requirements.
If you can get away from the need to process inbound data on-the-fly, I'd suggest just using an off-the-shelf FTP server (maybe even IIS), and process the received files from a folder. Your service could easily monitor this folder for new files. The other benefit of this is that files could be received even if your service is not running or restarting, and testing would be easier as you can drop your own files into the monitored folder.
Good luck!

Hope you find RemObjects free IP nice to use,
http://www.remobjects.com/ip.aspx
After installation you will see the samples.

WCF communication with several clients without IIS

we're working on a peer to peer comm software that would allow a number of grocery stores to sync their inventory with what we call "headquarters".
To so this, we're thinking WCF+WPF, and no IIS and web services. My experience with WCF is basically zero, so my question is whether a TCP comm solution using WCF would work. The data that's being transferred is quite limited, about 2MB for a compressed plain text file (so we're sending binary data!), and this is done once per day only. So bandwidth/load shouldn't be an issue here.
The idea at this point is to have a WCF "server" running at HQ. Stores make themselves known to that server and then send files back and forth (simliliar to a chat application).
What I'm not sure of: does every store need to have a WCF "server" (or endpoint)? How would the server (=HQ) send a file to one of the clients (=stores)? Every store can send a file to any other store, and the HQ, and every store can also "request" a file from any other store/HQ.
Two limitations: None of the machines/computers involved can run Windows server for budget reasons, and as stated before IIS is a no-go.

If you are only sending files back and forth, I might question whether or not WCF even makes any sense. Have you considered just using a file transfer protocol, like scp or sftp?
Every machine will have to accept connections and have a file drop location setup, and then yuor application will have to monitor that location for new files. I love WCF in general, but a file transfer protocol is going to have a leg up if that is all you want to do.

If you direct all of your traffic via the server then there's no reason why you couldn't achieve this with WCF. The server would host WCF services in IIS with the stores having a client that was able to upload and request files. With this method, stores would not be able to directly transfer fiels to each other, but they would have to do it via the main server, which would suit your needs if you don't have the budget for the other scenario.
If all transfers are made once per day, the requests for files would be made with each client requesting what files they require, followed by each client uploading any files that are required by the server or any other client. The final step would be the server distributing the required files to each client. Obviously, this is a simplified view of it, the actual process may require some more thinking.

You don't need to host WCF in IIS, but is there any particular reason you don't want to do that?
You can host WCF in a ServiceHost, but then you need to build, maintain and deploy a lot of server/service features that IIS provides for free, such as application process recycling, activation-based hosting, etc.
In any case, it almost sounds like you need peer to peer networking. You can do that with WCF using the NetPeerTcpBinding.

If you have an opportunity to redesign your application, I suggest you do. You can throw strings around in WCF but if you can create a data contract you can keep all your communication strongly typed.
If you have access to windows server 2008 then the new IIS can host your WCF even if it isn't using tcp. Otherwise you just need to write an application that opens a service host, which you would usually wrap into a windows service. But as #MArk Seemann pointed out, you get lots of freebies by running your service in IIS.
Don't have any experience with the PeerTcpBinding but I can tell you that the NetTcpBinding is nice and fast plus it comes with all sorts of goodies like encryption and authentication if you want it.