Does kestrel support the applicationInitialization feature ?
This is the feature were you can define a page (or pages) that will will be executed after the application starts. Basically to warm up the application.
If it is not supported is there an equivalent for Kestrel ?
If we turn back the time, most people use scripts to ping pages so their web applications can be warmed up. Later Microsoft developed Application Initialization module for IIS 7.5 and above to simplify that (and with some extra functionality like showing a warning page).
However, if we change the scope to Kestrel, then Microsoft has no plan yet to implement similar functionality, as the GitHub threads like this revealed.
You can use pinging as a workaround, and wait to see if Microsoft changes their minds. They did so when porting URL Rewrite functionality to Kestrel, as a middleware.
Again, ASP.NET Core is open source, so maybe someone can step in to implement such a middleware.
Related
We must use C# MS bot in windows service. How to implement it in .Net core for MSBot SDKv4?
All samples using IIS/Azure App service as hosting platform.
They're aren't any examples or samples that show how to explicitly do this. But you should be able to follow articles such as this or this and then tweak as needed. It shouldn't be much different than hosting any other asp.net core application.
The two points to make sure and cover are:
Make sure that the bot/application is configured (whether in appsettings.json or otherwise) so that it has the right configuration data. Specifically appid/password
Ensure the endpoint can be hit by the connector/channels.
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.
I am attempting to integrate a web site with Quickbooks Pro 2012 and would like to know what the recommended method is as I'm having a hard time getting information from the Intuit site.
Can I use QBFC13 with Quickbooks 2012 or do I have to use QBFC12?
Since this is a website, I think the correct method is to use Web Connector, although the web server could have direct access to the QuickBooks company file.
I'm been looking for a recent Web Connector sample (one that doesn't use Microsoft.Jet.OLEDB)
1. Can I use QBFC13 with Quickbooks 2012 or do I have to use QBFC12?
To my knowledge, all newer version of the SDK should work fine on older version of Quickbooks. I believe I read somewhere that they make an effort to keep it backwards compatible.
2. Since this is a website, I think the correct method is to use Web Connector, although the web server could have direct access to the QuickBooks company file.
I personally did not go with the webconnector route, because I needed real time comms. The webconnector will periodically "connect" to your website, and ask if it has any work for it to do. I personally created my own WCF Self Hosted service, which the website conencts to when needed. This wcf service, then interfaces with the quickbooks SDK, and passes the required info back to my website, when it wants it.
3. I'm been looking for a recent Web Connector sample (one that doesn't
use Microsoft.Jet.OLEDB)
Cant help you out here, although the QB specific stuff should generally still apply? Can't see why an example using a Jet DB would make the QB part of it unclear?
You can use either. You just need to make sure the QBXML version used is supported by QB.
Yes, you will need to use the web connector since this is going to a web site.
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