While reading a blog I found that ASP.NET Web API could be self hosted. There are loads of links telling how to self host Web API but I could not find any link explaining when it makes sense over IIS. Could someone please point me to couple of scenarios where self hosting of Web API is more suited than IIS hosting.
Thanks,
Ravi
Generally speaking, you would use self hosted Web API to get a better performance and to get rid of unnecessary pipelines of IIS. Additionally, you get better control over handling http requests, configuration and so forth. Since you have less dependencies on other apps your deployment and troubleshooting gets easier and less complicated.
Having said that, you have to write code to handle everything, even simple things (such as returning static files) that are simply done by IIS.
Thanks to the ASP.net Core, you'd be able to host your apps on Linux, MacOS and Windows. So, going cross platform would be another reason for using self hosted apps.
Related
My Heroku-app is being used by other people, on other websites then mine.
Is there a way that only my site can use the app?
I have a small site so i use a free account, this way my free "dynos" are gone very quick.
You have some options...
If your app or api is being used by javascript web apps in the browser then setting a CORS heading specifying your top level domain should do the trick.
If your app or api is being consumed by other servers or non-browser based processes then specifying an authentication process such as http basic (user/password) should restrict access to the set of clients that you control. If your service is successful then congratulations! Maybe you should scale up and start charging?
It seems like your goal is to stay in the free tier at Heroku.
Heroku starts your dynos triggered by the request coming in on their router mesh. This means every authentication or blocking technique inside your application will still lead to the dynos being started (that includes CORS).
Heroku itself doesn't give you configuration for their routing in the free/low-price tiers. If you pay for it, there is private spaces.
One possible solution is to have another layer over your app that does the authentication.
For example this could be:
cloudflare
Amazon CloudFront (not sure, with the Web Application Firewall)
other CDN
These will likely have a free tier that's enough for you, but also be rather complex to setup for a beginner.
I hope I could help you a little
I'm new to web developing and had to design a website for college. I decided to make it from scratch. I am currently hosting the website on Google Drive and it's working fine. Does this mean that it will work fine on a hosting company's web server? The main reason I ask is because of the many errors I get when using Markup Validation!
There's a lot of variables involved in this decision. The main assumption I'll make is that it's a flat site with no server scripting involved. If that's the case, you shouldn't have any issues copying them over to another web server. Though you should fix up those Markup Validation errors.
When I mention server scripting, I'm referring to PHP/ASP/Coldfusion/etc code that may be in your pages.
There are so many things today? I'm looking to host web api in windows service but recently I come across this link http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
is this a new thing and should we use this OWIN, Please suggest?
Does this OWIN make thing more faster or what are the benefit to use OWIN?
OWIN makes things a bit simpler and cleaner when self-hosting.
You might want to check out the OWIN Web API 2 self host in windows service example on GitHub.
Web API is based on owin, and owin is an abstraction. Instead of those old times when web api team was responsible for making web api availble on several hosts such as IIS, self host, etc, it just relays on owin. Owin has several implementations based on IIS, ASP.NET, ASP.NET Core, Self Host etc.
For example see the following sample of running asp.net web api odata on asp.net core using owin & kestrel: https://github.com/ymoradi/OwinAspNetCore
After doing more searching OWIN and Kanata are just layers on top particularly WebAPI, they are rather an convenient composer from what I understand from here http://msdn.microsoft.com/en-us/magazine/dn451439.aspx
for my purpose, I use WebAPI ONLY, so I don't need all these extra things.
I need to migrate an ASP.NET application to Azure. The application needs database access and access to temporary files and also using out-proc COM objects. Turns out there's "Full IIS" mode that offers some rather vaguely phrased advantages (from here):
However there are a number of useful capabilities that only exist in IIS, including support for multiple sites or virtual applications and activation of WCF services over non-HTTP transports through Windows Activation Services.
Now obviously using Full IIS forces me to deal with the ASP.NET part and role part working in different processes and that's a big deal so I need to know whether I need Full IIS mode in the first place.
How do I decide if I need Full IIS mode? Is there a full checklist?
I think your default answer should be use Full IIS in Windows Azure capabilities. The hosted web core offering is really there for backwards compatibility as it was the original model prior to 1.3 SDK. Full IIS is the default and you must explicitly opt to go back to HWC.
The reasons that most people wanted full IIS were around a few, but important limitations:
Better support for IIS extensions (e.g. Smooth Streaming, Web Farm, ARR, etc.). HWC did not always support the modules and combined with a missing admin permission, made it really hard if not impossible to use all the modules that folks wanted to use.
Support for multiple web sites, vdirs, and application pools. HWC is a single app pool (the hosting process) and no way to support multiple web sites. There was a serious concern about needing to dedicate 1 entire role to a single web site. With Full IIS, you can have multiple sites and use host headers to get more bang for buck out of web role (especially with small web sites)
Support for standard tooling - Web Deploy, AppCmd, etc. don't work really well (if at all) with HWC. Anything that modified the applicationHost.config usually had issues with HWC.
WAS support. This allows you to use WCF with IIS as a host in non-HTTP transports.
In general, with Full IIS you have parity with what you do on-premises so it makes it much easier to configure and setup.
Regarding the RoleEntryPoint/HWC process model versus the RoleEntryPoint and separate Full IIS process, I am not sure that is really an issue. There were a few quirks perhaps initially, but what concerns you the most about this?
I got a lot of theoretical answers from Google that WCF is better than Web Service etc. etc. But I want to know from the programming and implementation point of view. I am very new to coding and want to know that how do we implement all three of these technologies? How are they different and in which scenario we should used which technologies?
Thank you in advance.
A web service is an API that is hosted for access via a network connection - often the internet - and usually accessed over HTTP (or HTTPS).
WCF is a Microsoft .NET development framework that can be used to implement web services. That is, WCF-services are a subset of all web-services.
Windows services are a separate beast entirely: they are long-running programs that run on your local Windows machine, typically with no user interaction and on system accounts. They are used to handle many things in Windows, from low-level driver functionality to software updates.
You're really comparing apples and oranges. A web service is simply a program that you can "call" using the HTTP protocol. Typically, HTTP requests sent to the service contain some XML describing the method called and any parameters. The response from the service likewise contains XML with the return value and any output parameters. It's a little more complicated than this, but it gives you the basic idea.
Windows Communication Foundation (WCF) is a framework for building network services. You can use this framework to build web services if you wish. I suspect that what's tripping you up are the various Visual Studio project templates. You have one for WCF services and one for web services. The web service template builds a web service that runs inside of IIS. The WCF template gives you far more flexibility (you can make a web service as a stand-alone application, for example), but it is far more complicated.
If you're just beginning, I'd start with web service template and IIS-based web services.
MSDN is always a good reference:
Web Service Tutorial:
http://msdn.microsoft.com/en-us/library/8wbhsy70%28VS.80%29.aspx
WCF Tutorial:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
I think its always easier to learn by doing.
Good luck