I'm new to signalR hope someone here can point me the way before I dive into it.
I've got an asmx asp.net website (4.5).
I have running applications (ios/android) that are consuming it,
I want to improve my chat mechanism and after short research I've came into the SignalR.
My question is if I can work in the same website with both signalr and asmx webservies without interfering.
Thanks.
Yes, you can.
SignalR provides a "hub" which you can place in your asmx page. This hub then provides a connection to the server to send and receive SignalR events.
I recommend that you get started by checking out http://signalr.net/ and play with some samples there.
Related
I would like to implement SignalR into one of my WPF applications for its real-time capabilities to communicate between client and server. However, everything I have read points to SignalR only being used on web browsers. Would it be possible to use SignalR in my application that does not include any web browsers (without adding a WebBrowser element to my project displays)? To try to clarify, I would like to use all the perks of SignalR such that a couple displays in my application update their data in real time, with no web browsers. If so, what would this look like? Thanks!
Yes, SignalR has .NET, Java, and JavaScript clients. A web browser isn't necessary. Technically anything that knows one of the transport protocols that SignalR provides (such as web sockets) could have a client written for it.
I am trying to figure out if ASP.net on the client side in order to support SignalR. I would rather not be reliant on asp.net if at all possible for the webclient. I haven't found anything thus far that leads me to believe that it is required, but I could be overlooking something obvious.
EDIT:
As noted by the comments my question was not correct. I am ultimately trying to find out if ASP.net is required to use SignalR. From Lain's comments below it doesn't sound like it is which is excellent!
Any information would be greatly appreciated.
No. ASP.Net isn't required on either the client or the server side.
ASP.Net is a server-side platform for .Net, so can't be used as part of a client.
There is a native C# / .Net client, but this is lightweight and does not require any http server platforms.
The server side or 'Hub' can be process self-hosted, or hooked into an existing IIS site. It does not use ASP.net directly, but can work side-by-side with an ASP.Net website.
You will need a hub running to connect to for your client.
For more information, see the SignalR project site, which has examples:
http://signalr.net/
SignalR is a libbrary build for asp.net that employs features like web sockets, long polling, forever frames. If you want to distant your self from asp.net you could implement any of these features with any server side language (directly not through signalR).
But for specifically using signalR without asp.net (although may be doable) is something I would prefer not to try or suggest. All that for the server side.
For client side simple javascript would suffice, so you do not need to use any microsoft technology there.
No ASP.NET is required for SignalR.
You'll need to have a class that Implements IHub and that class has to be in C# or VB which is obviously a language of .Net framework.
Also, the hub javascript file is outputted by signalr using c#
And any framework will be proud to announce itself platform agnostic, and signalr's home page's title itself mentions ASP.NET SignalR So defenitely you are going to need .Net.
And you need to have this RouteTable.Routes.MapConnection<MyConnection>(...); which is obviously c# in Global.asax, which is obviously executed only by a asp.net website.
And last but not the least, SignalR is implemented in C# and you need ASP.Net so that signalr executes c# in runtime.
That's a lot of reason, why you should definitely have asp.net :)
I am currently developing an IRCX AJAX Chat based system and have a few questions regarding the Server and Client implementation; Any suggestions are welcome:
Server
Should this be implemented as a Web Service, or a Windows Form application? I have experience in developing Windows Forms based servers, however I am wondering if this would be better implemented as a Web Service and if so, why?
Client
How are Web Based Clients implemented today and what is the preferred method to implement a Web Based Client?
My solution so far are
ASP.NET Web Forms with an AJAX Update Panel (This seems the most viable)
Using jQuery connecting to the web service with a JavaScript timeout
Polling
How frequently should the server be polled for new messages? 0.5 seconds seems a bit excessive and anything between 2 or 3 seconds seems sluggish.
Thanks for your input.
Have a pool of connections and maintain a sort of proxy between the server and clients that sends the data to the right client based on a session id. This would mean your chat server is protected against packet attacks and you would not have to deal with web sockets which an attacker could hijack and do what they require with it.
I know the question is old, but there's an even better approach now.
SignalR is designed for things like this (real time web functionality)
SignalR can be used to add any sort of "real-time" web functionality to your ASP.NET application. While chat is often used as an example, you can do a whole lot more. Any time a user refreshes a web page to see new data, or the page implements Ajax long polling to retrieve new data, is candidate for using SignalR.
Here's a tutorial for a basic chat application HERE.
For more information, visit the SignalR website.
I believe using ASP.NET (Sockets and an Update Panel) seems to be the best approach. Using jQuery in this context now seems a bit invalid because it would not maintain a persistent state with the Chat Server which is required for Real Time Communication.
An alternative way I found would be using a Web Sockets and Backbone.JS to deal with the data returned from the server.
http://blog.fogcreek.com/the-trello-tech-stack/
Background
I have a windows console app written in C# which needs UI. I started using WPF, but as I come from a web background, I want to use html, and some features of html5, including web sockets for real time communication with another application.
Initially, I'll use a web browser as the UI, though I may later host a web browser in the main app. This bit doesn't concern me at the moment.
After a lot of googling/reading, I'm going round in circles. It looks like WCF can be used to serve html, json based web services, and possibly web socket streams.
A lot of googled info relates to pre .NET 4.0 community projects. Even post 4.0 there are several NuGet packages which seem to me to overlap what is already in the framework. To a WCF noob, it's all a minefield.
So, what areas of .NET 4.0 WCF and the various open source projects should I be concentrating my efforts on.
Requirements
I require a lightweight self hosted web server. It cannot be IIS based, as users will not have it installed. The server (or servers) must:
Be able to server complete web pages, including html, linked images, css and js files. C# MiniHttpd does the job well, but is not based on http.sys. HttpListener seems to be the core of what I want, but I haven't found a complete web server project based on it.
[optionally] Be able to parse those pages through asp.net or razor
Be able to respond to web service call via json. This bit I have a working example using System.ServiceModel. Is this the right way to go?
Be able to work with the emerging Web Sockets standard. SuperWebSocket is actively developed, but doesn't appear to be http.sys or wcf based.
Preferences
I would prefer to stick to one basic stack for all 3 of my main requirements - and I suspect WCF may be that platform.
I would prefer an http.sys based approach for all three requirements, so I can reserve the relevant url/port/namespace combinations and prevent conflicts with other web servers or services
Although other SO questions may help with individual aspects of my requirements, I need advice on a more holistic approach.
Ok, answering my own question feels wrong, but...
I have since found a great CodeProject article that provides an easy to use self hosted web server for serving the html, css, js and images, and serves the json requests.
Developing Web 2.0 User Interface for Self Hosted WCF Services using HTML5, CSS3 and JQuery
I still have to settle on a WebSockets solution, but the above project is as close to what I need as is possible at the moment. It doesn't support rendering asp.net or razor, but these were my lowest priorities, as I'm happy to use only pure html and javascript for the front end.
I'll try to post more specific questions in the future :)
Except for your WebSocket support requirement, the OpenRasta framework currently supports what you describe. It definitely can run in http.sys and can be used for both creating REST services and as a web app platform. It also supports Razor and other view engines. The link page has a good comparison chart toward the middle that compares it with ASP.NET MVC & WCF.
In March 2014, a solution which fits my original requirements is ASP.NET Web Api. It can be self hosted, and can apparently be set up to serve html etc as well.
Is it possible to serve a web page from a self hosted web API in a windows service?
We are in process of re designing an old windows client server based application to web based application.
This application is built in C# using Remoting and WCF. On client side its Windows and WPF.
My Queries
What all concepts should be taken care when we make this application web based?
What design patterns should be followed for Web Based Architecture?
In WCF part we are using Net TCP Binding which can be easily migrated to HttpBinding, but I am more concern over Remoting, will it able to Serve the purpose, means can Remoting serve the purpose when Http calls are being made?
I would probably merge "remoting" with wcf and use httpbinding endpoint. font-end you could decide to use MVC pattern which will give you a better performance.
Sorry to answer your question with a question but: From an architecture or business point of view, why would you want to do this?
Your original application uses Remoting, which does not work over the Internet, therefore I am assuming that this is an internal application.
A web application would have the following tiers:
The presentation which runs on the browser
The Web Server which sends the pages to the browser
The application server which would host your WCF services
The database server
As you see the web application in the browser does not call the services directly (unless you use REST based services)