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 :)
Related
I'm trying to use client-side Blazor to display some data, provided by existing WCF service. I was able to add a connected service reference, the proxy is generated. But when I'm trying to invoke it like this:
var client = new SoftConServiceClient();
await client.PingAsync(new PingRequest());
there is a bunch of errors, related to MonoTouch. By digging into the code of Mono, there is an explicit NotImplementedException in the constructor of the System.ServiceModel.DnsEndpointIdentity.
Am I right to assume that there is no way now to call legacy WCF service from Blazor client-side? If that's not the case, can anyone share a guide about how to properly do it?
Bonus question: if that is not possible, what would be the best option to approach this? Modify WCF to become REST-ish or just drop it and implement .net core api service?
Thanks a lot in advance!
Core does not support WCF very well instead of not at all. Especially in terms of authentication and security, such as the service created by using WS* binding. But for services created by using BasicHttpBinding or Restful styles services. We could invoke them normally on Core-based clients, whether using client proxy class or Channel Factory.
Please refer to below official repository.
https://github.com/dotnet/wcf
I suggest you re-construct your server project with BasicHttpBinding or using Asp.net WebAPI to create the backend service.
https://learn.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
Feel free to let me know if there is anything I can help with.
WCF is not supported in .NET Core out of the box, however there seems like there is a community project that is working on adding support for it in .NET Core
https://github.com/CoreWCF/CoreWCF
See What replaces WCF in .Net Core? for more info.
Am I right to assume that there is no way now to call legacy WCF
service from Blazor client-side?
Yes, you're right... WCF is not supported in Blazor client-side, and it won't be supported in the future. Microsoft has decided to stop supporting it as from .Net 5.0, and suggest to use Web Api instead.
Depending on how much you are invested in WCF, you may shift to Web API, perhaps gRPC, or go on using WCF, hoping that the efforts of the community to port and support WCF might succeed.
I was able to to put WCF 4.7.2 using techniques found with SoftCore in .Net 5.
I can also work SoftCore Hosted Example Blazor Server.
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.
following my previous post about my game server, I've decided that I want to create a web-based server, and not a WPF one.
Currently, the server is a console application. I run the server, it has a TcpListener, and I interact with TcpClients, and the only real console-y thing I have, is a bunch of Console.WriteLines that I intend to get rid of. The server itself is part of a class library, which contains all the server logic, so that it'll be easy to wrap it in whatever platform I need.
Say I have a library with all my server-side logic, and I want the GUI of the server to be a web client, while still having a server that runs in the background and keeps the game running - How do I do that with ASP.NET?
Since all my code is C#, it's natural that I would pick ASP.NET, and use MVC with Razor, allowing me to use my original classes as data in the website.
I can handle the website part of the ASP.NET, but what I need advice with is how I create a server that acts like my previous one (runs in the background, has some sort of GUI, for input, commands and etc), and also has a website as the GUI.
Thanks in advance!
for reference, all my ConsoleApplication code is here, showing just how little the platform that runs the server has to do.
And regardless, this is the link to my game code, if anyone is interested. I'm always interested in opinions and constructive criticism!
This is an article about self hosting webapi and static files in a console application using Owin, no support for MVC. Asp.Net Core has a similar work flow (though it's not called Owin anymore), and MVC is available. Asp.Net Core apps are actually self hosted in a console application using Kestrel. When you host asp.net core in IIS all IIS does is act as a proxy.
I am planning to use Angular JS + Web API together for my application.
Technologies : VS 2013, .NET 4.0, MS Server 2003.
I have my Web API & Angular JS Client on two different domains [Mandatory]. I tried achieving what i need using .NET 4.5/4.5.1 with CORS in Web API, but because MS Server 2003 does not support installation > .NET 4.0 have to give up the thought. So the solution might not be fully viable for my case.
Can someone suggest how to achieve this with the above mentioned restrictions in mind?
Any help is highly appreciated. Thanks.
One way to do this (to 'avoid' CORS that is) is to implement a solution that has a sever-side component as well as the client-side (angular). AngularJS would call the server-side (same web site, really, but a different path) that would then call the server. Thus, a client is not calling the web API directly, but the server is.
There's security concerns to be aware of, of course, but the general idea still applies: make your API calls from the server instead of client, and have the client call the server.
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?