I am exploring the current news for ASP.NET WinForms with .NET 4.6.
The resources I am currently looking at is this Video overview by Microsoft Program Manager Pranav Rastogi and an article on DotNetCurry. Besides the information, that I will require Windows 10 Preview, I can not decipher, what this really means to me as a WebForms developer.
To use HTTP/2 will I...
need to make some changes in a config file?
need to change something in the page / master page?
use a different programming model when it comes to serve resources?
Of course, IIS will need to be configured, but this does not affect me as developer.
Is there actually something I need / can do as developer to support HTTP/2?
Note: If someone sees this as a better fit on Programmers or other SE site, please move.
Basically, HTTP/2 is seemless for web services. The basic functions, request/response multiplexing and header compression, are defined at the network protocol level. That means it can be seen as the matter of web browsers and web servers.
But for the new features like HTTP/2 server push and stream priority/dependency, it needs to be considered for developers. To use those features, web browsers and web servers should provide APIs.
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.
I am new to WCF and going through tutorials right now. I was wondering what are the benefits and disadvantages of using a WPF or an ASP.NET web application as a client for a service. I understand it will depend on the kind of service, but besides the common difference of one being a windows app and other a web application, what are the advantages of one over other.
First of all, the choice of client technology does not depend at all on the kind of service you will be talking to. Both WPF/Winforms and a Web app will be perfectly capable to talk to a web service.
Instead, choice of client technology should purely be driven by requirements on the client side
Factors that you should consider when coosing one client technology over the other are:
Know-How available to you (and your team)
Deployment scearios: How do you get your app to the users, etc.
Client environment: How many OSs do you need to support, how many different browsers would you have to support when doing a web app?
Do you have occasionally connected scenarios, or do you need privileged access to client resources? - This would tip the scale somewhat towards a Rich client.
Even so, in many cases a web app appears to be a very valid option as you have access to a wealth of non-MS tech like Javascript Frameworks, CSS resources etc. etc.
On a personal note: Do not use WCF to define your web services - there are fantastic Open Source Frameworks, most notably ServiceStack that will make you more productive and concentrate on what your service does and less on the mechanics and abstractions.
I am looking to create a lightweight, heavy traffic, db site. It will be standard 3 tiered architecture in asp.net. Part of this site is web-based, but most of the functions will ideally be available on mobile devices, also.
That being said, I know that web services is the classic answer for this, since I can access a web service from many platforms. However, I also know that ashx files are the most light-weight. Is there a way to access ashx files from non-web platforms? and if so, how would this compare to a web service to do the same thing.
a good example: a login page that calls either a web service or ashx file to authenticate.
Thanks!
Eric
[EDIT] I was thinking along the lines of iphone/android/pre type of mobile apps.
How will you display on the mobile devices? You've said "web-based" and "mobile devices" but these can be the same thing. E.g. Through Control Adapters
You should also look at ASP.Net MVC if you haven't. It should help with the tiered design and performance that you are looking to get out of your application.
An .ASHX file will efficiently deliver any content type that you require. That is one of it's key strengths. So the answer to your question is yes, it can be used to deliver to non-web platforms via SOAP or other HTTP transport schemes. This would be a lot more involved than using web services.
With your login example, then main benefit that I see is that your ASHX file can use multiple transport schemes, not just SOAP. So you can use the lighter weight REST for instance.
I'm wondering how many folks using the Microsoft development stack (IIS and/or ASP.NET) are actually using REST? If so, what forms of rest are being used?
REST can be categorized a zillion ways, but for the purpose of this question I'll categorize it as follows:
Radically REST: Using all the
HTTP methods PUT/POST/GET/DELETE
Moderate REST: Using GET/POST
REST Hybrid: Uses just the GET or
POST HTTP method, but follows
RESTful principles of addressability
and state.
In a class I'm teaching we've been trying to implement a "radically RESTful" service on IIS, but we've been having difficulty implementing the PUT method. There doesn't seem to be a lot of buzz on implementing PUT on IIS so I'm wondering how many people are actually using full blown REST? Are you using REST?
I'm involved in a project that uses WCF REST on IIS, but of course I'd recommend having a look at the framework I built: OpenRasta is a .net open-source stack that makes implementing REST much easier.
Google is your friend. The main site is http://trac.caffeine-it.com/openrasta.
I think part of the reason for the lack of buzz around REST on the IIS stack has been Microsoft's original adoption of SOAP as the way, truth and light when it came to web services - especially with Windows Communication Foundation being heavily SOAP focused.
They went on to release the WCF REST Starter Kit, to follow on from the release of .NET 3.5, and also the ADO.NET data services that are part of .NET 3.5 SP1.
As Magnus points out, Microsoft have since released the ASP.NET Web API which builds on the features of the ASP.NET MVC platform to provide a unified approach to RESTful services on IIS.
ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.
The WCF Rest Toolkit mentioned in the answer from "Zhaph - Ben Duguid" is now deprecated.
It has now been replaced with the WCF Web API project.
Edit: Which is now also deprecated and replaced by ASP.NET Web API!
It depends how you approach it.
By default IIS will limit verbs to ASP.NET pages to GET, HEAD, POST and DEBUG. You are, of course, free to tell it to accept PUT as well by editing the handler mapping. Assuming you wanted your own extension you'd do something like
<httpHandlers>
<add path="*.example" type="System.Web.UI.PageHandlerFactory" verb="GET, HEAD, POST, PUT, DELETE, DEBUG"/>
</httpHandlers>
If you want to remap .aspx you, of course, can in much the same way, assuming the server is configured to allow you/
I'm pretty sure the Microsoft ADO.NET Data Services uses RESTful services. It might be worth checking out... aside from being restful, it's a really cool tech.
Here's an extract from a white paper on it:
The goal of Microsoft® ADO.NET Data Services is to enable applications to expose data as a data service that can be consumed by web clients within corporate networks and across the internet. A data service is reachable via regular HTTP requests, using standard HTTP verbs such as GET, POST, PUT and DELETE to perform CRUD operations against the service. The payload format used by the service is controllable by the application, but all options are simple, open formats such as JSON and Atom/APP.
Here's a white paper and it's home page (at least what I think is it's home page)
HTHs,
Charles
What version of IIS? In IIS6 you need to enable WebDAV to enable PUSH requests to get through (no, I don't think that makes much sense either :-)). I don't think that's the case in IIS7 though.
I'm using the .Net class, HttpListener, which is the IIS web server engine(http.sys) without the IIS admin tools. I am handling all of the HTTP verbs. You can add attach the ASP.Net runtime to this if you like, but you don't need to.
In fact in a few cases we implemented a version of PATCH as an experiment. Once you get down to the basics, the verb is simply a string in one of the HTTP headers.
You actually cannot categorize REST in a zillion ways. There are may ways of using HTTP to build distributed applications but there is only one definition of REST.
I have a need to explore VOIP integration into a .Net application. It would be incredibly helpful if the toolset was usable via ASP.Net (version 2.0 or higher), and provided the developer the option to allow interaction on the client either embedded within the web browser or external to the client web browser. It should be compatible at a minimum with Internet Explorer, but would be better if browser independence were an option.
I don't really understand your question -- what are you trying to DO with VoIP? Since you mentioned ASP.NET I'm guessing you mean some kind of server app? If you explain more about what you want to do, we can give you better advice.
You could check out Microsoft's Speech stuff: http://www.microsoft.com/speech/speech2007/default.mspx. As I understand it, Speech Server was moved into being part of OCS. I remember that it supported using .NET 3.0's Workflow Foundation as well as some multi-modal stuff with ASP.NET.
FreeSWITCH is a flexible VoIP system that works for both large-scale server implementations as well as embedded scenarios (say as an ActiveX softphone). There is full .NET and Mono support via mod_managed. (This allows you to create voice applications in FreeSWITCH using any .NET language.) There's also an XML-based API that allows you to send and receive events to control a remote FS server. You could use this from ASP.NET. FreeSWITCH is very active in #freeswitch#irc.freenode.net so you can get a lot of advice there.