Develop Reference

How to create a public server in C#

I am a novice programmer. I was trying to learn about networking in C#. I want to know how to create a public server in C#. I tried to search on the internet but I didn't find much. As a public server, I meant to connect to one computer to another from remote or an online server where I can connect from anywhere which is written in C#. I want to know is how to make it and what I need to do that or especially I want the information how can I make one and what I need. I would like to use winform/wpf or console application for the server.(Sorry for my bad English)

There are plenty of resources out there already, you just need to do your research.
A couple notes:
winform/wpf is a technology for desktop programs, with windows and user controls and such. A server has no need for such things.
a server is a server, public or not. Making it public is as simple as making it available at an IP address / domain that is reachable from the internet. This has little to do with implementation.
there are so, so, so many different types of server applications. Some serve websites, others serve databases, and still others just provide raw data in the form of JSON or XML.
I'm assuming since you're just getting started, you're trying to build a web server to serve a website. Here's a tutorial I found by Googling 'c# web server' that seems to get you up and running: https://codehosting.net/blog/BlogEngine/post/Simple-C-Web-Server
Good luck, and remember that SO is a place for technical questions, not a 'how to do a whole thing start to finish' forum :)

I think the keywords you need are
ASP.NET + IIS, for a full fledged server app
HttpListener, for a stand alone server app
The prior is a framework for building a MVC Server application (it also has a subset called WebApi which as the name states is for APIs), and the latter is the class you will need to create a stand alone server application.
In the future, you might want to consider using ASP.NET Core to deploy your application onto linux.
Good luck.

Viewing message streams in Visual Studio for signalR chat application

I recently found a .NET tutorial that showed me how to make a simple chat application in Visual studio using the .NET library, signalr.
I have created the application and made a few moderations including some AES encryption. I have then hosted it on Windows Azure as a website.
The chat application works and has been tested, but I don't know how to view the messages sent from one user to the other.
Can someone tell me where I can find these message streams?
Thanks

All messages will go through the SignalR Hub, so you could either use breakpoints/debugging to see what is send (if you are running in your development environment). Otherwise you could use tracing in the Hub to see the messages.
There is a extension to glimpse that you might use (I haven't tested it though): http://www.nuget.org/packages/Glimpse.SignalR

You can get some performance counters using the tools provided by Microsoft.
For what I know there is no way to get all messages send or received from the server. When you need to analyze the communication of specific clients, try to use Wireshark or Microsoft Network Monitor.
You could also write your own message logger that writes them to file.
You can use common methods as Trace.WriteLine to write info to the default listener. Then use a listener to write to file / database.
This source may be useful when learning to analyze messages from a webserver.

Fiddler is the best tool for monitoring web traffic. It's stupid easy to use and has a lot of extended features to help debug server/client applications. Take a look at this page which includes a brief description of using Fiddler with signalr.
Good luck!

Web Farm Chat Storage

I got a chat application (webservice) running on a website hosted by a web farm and I don't know how to temporarily store the chat messages. Im using long polling to save resources and I have specified a shared machine key.
Because its running on a web farm the HttpApplicationState won't work and saving each message to my database would cause a lot of overload and overhead, and I doubt that would be a good idea.
So is there any other approach to save the messages in server "memory", note: within a web farm?

The classic solution to this is to use a distributed cache; it's not as popular in .Net world as it might be, but here's an article on MSDN; Microsoft has a product, or you can use the open source Memcached, for which you can also get .Net client libraries and Windows versions.
Please note that while distributed caching is very cool when it works, it does introduce a lot of additional complexity, and exciting new ways for bugs to creep into your app. I'd only go down this route if I really, really needed to.

I found some more help on the topic here. It introduces different caching techniques. Without the use of third-part software.

N-Tier with C#?

I am looking at writing a WinForms app and getting stumped over what seems to be simple issue.
There is a server and database (SQL Server) Open ports are HTTP, HTTPS
There is a WinForms client. It needs to connect a TCP/IP stream (possibly HTTP, SOAP, REST) to the server.
Sometimes the WinForms client goes off-line and then the WinForms client stores its data in a database.
When the WinForms client goes on-line to server, it synchronizes data to the server, gets all the latest data from the server and updates local database.
How do I do that?
Newbie question

As you've conceded, this question shows you might not know where to begin looking for how to architect this kind of application.
I'd start here: http://msdn.microsoft.com/en-us/library/ms973279.aspx
The offline architecture you've described is a little tougher for a newbie than not supporting this, consider making the application only work online first, then add offline functionality.
Also, if you have a web server you will almost always use HTTP, SOAP and REST are strategies that sit on top of HTTP. I cannot recommend that a new developer look at any server communication using direct TCP/IP.
Edit: Answer to related question - there are tons of ORMs and service builders, not a lot of them have built in support for offline workflow but ODX does, but it might be a bit out of date. NHibernate and any of the projects in the Castle Project are very popular components for what you're looking to do also.

No idea how actively this is still being supported by Microsoft, but you might check out the Smart Client Software Factory, it seems to support offline mode and smart reconnecting like you need.
http://msdn.microsoft.com/en-us/library/ff709809.aspx

You could approach this with a 'Service' mindset - Write a WebService (preferably a WCF service) - that forms the synchronization tier between your Winforms app. and remote database.
So, you would have your
1. Local WinformsApp. with a local database (as functional/lightweight as you want it to be)
2. WebService
3. Remote app./DB

Here are some links to tutorials/resources:
http://www.codeproject.com/KB/architecture/three_tier_architecture.aspx
http://services.community.microsoft.com/feeds/feed/query/tag/n-tier/eq/tag/visual%20basic/eq/and/locale/en-us/eq/and
http://msdn.microsoft.com/en-us/library/bb384570.aspx
http://msdn.microsoft.com/en-us/library/bb384398.aspx

IMHO this isn't usually as simple as it may sound
If you were able to go DB to DB, then SQL replication could be the simplest mechanism for synchronisation.
However, since it sounds like you are using a SOA approach, you might need to look at frameworks which have offline support built in, such as the Ent Lib Composite Application Block and Smart Client Software Factory
You might also look at using Queues (e.g. MSMQ) to accomodate network connectivity problems.

Microsoft Sync Framework (http://code.msdn.microsoft.com/sync) + WCF solution here:
http://code.msdn.microsoft.com/sync/Release/ProjectReleases.aspx?ReleaseId=3762
Database synchronisation is not an easy task to get started with, by any means. Good luck.

Generally, you need a local database, or at least a local cache.

Distributed application (WCF/Remoting/web servervices) Vs Web application

I am making a medium sized standard LOB application. Currently its a web application but I am formulating a proposal to revamp it into a Desktop remote application. By this I mean that the database and the application server will be hosted in a remote location. The client application will communicate with the server via the internet through (either WCF / Webservices / Remoting).
My question is this: The only reason I am shifting this from a web platform is due to the constraints of the web (I dont want to do AJAX or Java scripting to minimize those constraints, so please no JS/AJAX recommendations). I have made traditional desktop applications and they are considerably fast but i have never made a remote or a distributed application. I am not sure weather the speed of the application will be faster then the web or not.
As I understand it, the remote desktop application would be much faster. For one, there wont be any post backs involved, (I hate them so much). The data will obviously come via internet, so in that respect, is it better to shift to the remote desktop just for sheer speed and power?
Any help in the right direction would be greatfull. Many thanks.
Zeeshan

I think biggest advantage of desktop clients over web applications is freedom in UI design, and you don't have to worry about any inconsistencies in the client environment, although those are not an issue if you are using a client that runs on silverlight.
Personally I don't like web applications that requires a lot of user interaction, there are some of them that is a pleasure to use but I think it is very easy to do it the wrong way and end up having a buggy or not so responsive application (probably because of the incompatibilities in browsers, I have IE, Firefox and Chrome installed on my computer and I use one for some websites because they run faster on it, and others for other sites because web pages show up correctly only on them). Though this might not be an issue for a silverlight client.
In case of network speed, depending on the things that goes on the wire even with binary serialization remoting might have quite a bit of overhead. For example along with the data it writes full class names, library names and their versions so it can get pretty big and slow even for small amounts of data (although it should still be smaller then HTTP). It also has the same problems that HTTP has over unreliable connections because it uses a similar protocol. For one project we had to write a custom serializer for some objects because binary serialization alone was generating 200K, but our custom serializer for those objects were generating 50K. Then we ended up writing our own network protocol because the one that comes with the runtime was frequently stalling over unreliable wireless networks, and remoting doesn't give any control on the socket created by it (which makes sense in terms of encapsulation but you can't close it and force it to open a new one).
(I am assuming that you are asking about remoting vs web app. not remote desktop vs. web apps, because of your note about post back, you can't avoid it with a remote desktop session)
Rewriting an application just for sheer speed? No, because probably user won't see much difference in response time.

You are somewhat ambiguous with your terminology - do you want a client app that runs on the user's machine, or do you want an app that runs on the server and the user connects via remote desktop (RDP)?
If you are talking about a client app that communicates to the server via WCF etc., then yes it will be faster than a standard web app, although it will still be slower than a native desktop app. It will be faster than the web app not just because of the lack of postbacks, but also because you will be sending pure data through the wire, not a massive amount of HTML/Javascript combined with your data. With a client app, you have several options so consider them carefully - do you want Silverlight, WPF, or a native WinForms app? Each have their positives and negatives.
If you were talking about having a client app running on the server which the user then access via RDP, then you have other considerations to think of. For any more than two concurrent users you will need to consider buying CALs so the users can connect to the server. At this point you should also be considering whether you should be running a terminal server or Citrix type setup instead of using remote desktop.
Edit
When using WCF over a WAN (internet) you will certainly have to consider how you will secure it. WCF makes it trivial to secure the channel, but you need to consider how you will do authentication - there are a couple of different ways, but you can easily google that stuff yourself. The method you choose will be important due to the limited resources or skill-sets of the users.
As for what you write it in, you can't argue with Winforms if that is where your experience is. Personally, i would never again use ASP.NET/Ajax/etc for a web type application, it would be WPF or Silverlight all the way (i would only use ASP.NET for simple web sites). You can use the express (free) versions of Visual Studio to write it in, you don't need Expression (it's just a nice to have, and is more aimed at the design side than the actual coding side). Deploying the app need not be difficult - Silverlight or WPF xbap are delivered via the web, the user has to do nothing (except for the simple install of the Silverlight plugin or installing the right .Net framework for WPF - check this link). Winforms or stand-alone WPF require slightly more work, but you can avoid most issues by writing a good installer.
Whichever you choose, make sure you don't under estimate the time for development (because you will have a bit of a learning curve), and also make sure you budget enough time for testing it - especially the security side of it :)

I have been in a similar situation, although started with a Winforms LOB application.
Heres what we found with WinForms...
It's going to be harder to deploy in your release cycle, to all client machines.
WinForms can't be run on other operating systems easily. (with the exception on mono)
WCF endpoints can get complicated, and you need to manage an endpoint for release/version of your application.
Authentication, Authorization and Security can be tricky to get right!
Heres why you should stick to a html web application.
it's going to be easier to deploy, as you just need to copy one set of DLL's into the bin folder. Can be scripted from a continuous integration or staging server.
Security is going to be easy, by using a SSL certificate.
Silverlight/Flash should fill in the gaps that HTML leaves out.
Microsoft has also combined the connected systems in .net 3.5, they now call it WCF (ASMX/Remoting/etc...). It's got quite a learning curve 4-5 weeks.