Hey guys I just encountered with a bit of confusion while learning ASP.NET MVC. So, please can you explain in simple terms why need to host web application to web server if, as I learned MVC, controller is there to handle requests and responds, that is, why on earth need IIS while there is controller. Yes, you can say this question is quite stupid but I cannot tell them apart Web server and controller thus I need your help.
TL;DR: IIS serves your controllers as callable end-points. IIS is a web server. You can read more about MVC life-cycle on https://learn.microsoft.com/en-us/aspnet/mvc/overview/getting-started/lifecycle-of-an-aspnet-mvc-5-application
About IIS server:what-is-iis-server
Long Story;
IIS: this guy hosts your any application. the application can be MVC, ASP web site. It basically runs a process to listen specific port(s) if there is any request on it. So it stands outer of your served application.
Controller: When IIS(with net core you can serve your application via many web-servers (I personally use kestrel)) handle a request and addresses your application, your MVC pipeline kicks in. It handles the request(this request shaped for the application by IIS already) then, execute routes-handlers-filters. Then finally, your controller can process its method.
Related
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
Objective:
We have a Windows Service/generic EXE that also hosts a WCF service (.Net 3.5). I'd like to be able to take a third party ASP.NET component in a DLL, and host it through that WCF Service.
Is this possible to do, in any way?
It seems like if you want to host a ASP.NET app, it must be through IIS, but we don't use IIS.
Is there any way that we could load the ASP.NET app into memory, make the app available through an endpoint, and receive requests back from the app?
Specifically, we'd like to take the "Microsoft.ReportViewer.WebForms.dll", expose the web form in a web page, and accept any requests back from the web form.
http://msdn.microsoft.com/en-us/library/ms251723.aspx
Looking for anything to get me started. Thx.
From owin.org
"OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools."
Essentially Owin implementations, like Katana (OWIN implementations for Microsoft servers and frameworks.), help you self host web apps, even in a Windows NT Service.
According to this post, hosting a WebForms app outside IIS/ASP.NET is not possible.
WebForms are tightly coupled to ASP.NET/IIS and cannot run directly on
OWIN/Katana (e.g. outside of ASP.NET/IIS). However, you should be able
to use Katana's middleware (Security, CORS, etc.) in a WebForms
application.
http://katanaproject.codeplex.com/discussions/571291
I am in to a project that uses Silverlight and am not quite clear on few things with SL.
I understand that SL downloads the xap on to the client browser and makes a lot of things easier that way. The aspx or html page loads SL plugin and downloads xap in browser. I have my web application deployed in IIS and have few WCF web services hosted on IIS (http) and also a few as windows services (net.tcp).
What about wcf service calls that I make from Silverlight code ? Since I can call WCF http or net.tcp based services directly from Silverlight code, it makes me wonder if the SL client is able to directly talk to the web services from browser (or) SL calls run to website which then makes the service calls ?
I am guessing am missing to understand some basics here. Please can someone explain what happens in this scenario in SL. Any links to some deeper understanding is much appreciated.
Thanks.
Silverlight can communicate directly with about anything in the local or external network when tcp is the underlying protocol, bar some security restrictions.
When you communicate with a local WCF Service based on tcp, for example, you still need the clientaccesspolicy.xml be served by http on the save host - or run Silverlight with elevated permissions.
For http, Silverlight can use both ask the browser to make a request or make a request directly (I'm not sure which is used for wcf), tcp will always be done from the plugin directly.
The Silverlight application has to be hosted by a website, but the website doesn't need to do anything beyond that for Silverlight to work, or for it to access a WCF Services. You can host a Silverlight app as purely static files.
can you please tell me what is the difference between webservice and webapplication.
A web service:
Typically returns XML or JSON or something like that, something that is easily decoded by a program
The results you get from a web service is typically not just shown to a person in its raw form (ie. since it isn't HTML, the results have to be reformatted, like placed into a form)
The intended usage of a web service is that it is something an application can talk to
A web application
Typically returns HTML or image data or similar
The results you get from a web application is usually shown to a person, through a web browser
As for similarities:
Both typically use HTTP(S) as the transport
Both typically use HTTP authentication/authorization to secure data
Both are typically hosted by a web server
So the main difference is who usually talks to them. A web service usually by another application, a web application usually by a web browser. Other than that they're pretty similar.
Here is the Web Application and here is Web Service
Web application: any application which resides on a server, and mainly used by human using web browser. All user interactivity is done through web pages.
Web service: server-based application (as above) which may be accessed over the web via HTTP, but is meant primarily for interaction with other programs. Generally it is WEB API for other applications.
In a nutshell, a Webservice uses special HTTP transport protocols to communicate to other servers. Webservices are meant to be used by other applications.
In the ASP.Net world, a web application is a type of Visual Studio project that allows building ASP.Net websites in a particular configuration. E.g. A Webservice can be built using a Web Application type project. Or a Web Application can also refer to a website that is meant to be used directly by an end-user ( unlike web services ).
Here are a few links and related SO questions...
What is the difference between an asp.net web method and a wcf service?
ASP.NET Web Site or ASP.NET Web Application?
Introduction to Web Services and ASP.NET
check this
http://en.wikipedia.org/wiki/Web_service
http://www.w3schools.com/webservices/ws_intro.asp
I have a .net application running on server. Now I want to comunicate between my ASp.NET website and the server application.
Currently I use database, server writes info to the db and site uses it etc. However adding new fields to echange and exchanging complex object is a pain.
Is remoting the way out? If yes, what are the common things to keep in mind while doing this.
both server and asp.net site is on the same server
both is under my control
is there any other better way than using remoting?
It is .NET 2.0
The purists will say that remoting is an old, dead technology, and the way to do it now is to use WCF.
If you're attempting to have some SOA thing, the best thing is to a web service for your server application and access it from your ASP.net website application. It's the best way to do.
However I don't really understand what the purpose of the "server" is? Couldn't your ASP.net website - as you say - be your front-end of the server application?? Your "server" would then simply be the business and data layer and there would be no need to use remoting or WCF.
I would say webservices if want to stay .net 2.0, otherwise it think you should take a look at WCF.
If you need direct interaction between assemblies (ASP.NET and some server application or service) you should use Application Domains and cross-domain calls (some good example here) or using WCF, which is better. Also you can use web services if your server application can be accessed via web without major resulting drawbacks (security issues, server deployment change, etc.).
Actually, u can deploy a WebService on that server. WebService is base on SOAP, it can exchange data object with your website.
If you can update to .Net Framwwork 3.5, you can try to use WCF instead.