I came across the term hosting environment while i am going through the concept of ASP .Net lifecycle. Can anyone explain me in detail regarding this?
Thanks in advance
Hosting Environment Creation and Responsibilities
An instance of the HostingEnvironment will be created within the ApplicationDomain prior to ASP's creation and initialization of the HttpRuntime and all of the other associated core objects.
The HostingEnvironment contains details specific to the Application itself, such as where the Application is stored at and functions and services essential to managing the entire application.
HttpRuntime Creation and Responsibilities
The HttpRuntime (and several other core objects) will not be created until after the HostingEnvironment and ApplicationDomain have been created.
The HttpRuntime class is responsible for handling functions and services related to handling all of the HTTP Requests and Responses that are performed within the application. It also features some functions to access information regarding the domain of the current application.
Quick Summaries
The HostingEnvironment is responsible for handling application-specific functions and application management and is created before the HttpRuntime (HttpRuntime CANNOT be created until after the ApplicationDomain and HostingEnvironment have been created.)
The HttpRuntime (and its related objects) is responsible for handling run-time operations within the application but not application-specific management operations. (It will NOT be created until after the HostingEnvironment has been created)
This is simply a ready to use environment provided by many vendors on a monthly or annual fee or may be setup by yourself to host or deploy your software there.
You can read more on wiki here about hosting environment
or just google for more information.
Hosting environment can be a reference to the hardware\software\location\configuration used to host software.
In terms of ASP.NET it most likely means:
Using IIS or IIS Express
What version of the .NET framework
What Operating system
Depending on the context it can also mean what hosting environment meaning third party service provider will host your web application such as Go Daddy or Rack Space.
A environment is a Server in which it lives. A server hosting environment is a stand alone hosting cluster of servers in which are able to handle multiple websites for Web Hosting.
Related
Is the Application variable shared when the web application has multiple role instances in window azure? And I am using Dedicated cache worker role. Is Application Variable is preserved the cache? If not then how we can do it?
The Application variable is stored in-memory (see this MSDN reference article). There's no option to persist it or externalize it, so there's no way to share application state across web role instances. The article points this out, in terms of inability to share application state across servers in a web farm.
As this SO answer suggests, you'd need to use some shareable resource for application-level content. In other words, just don't use the Application variable. You could store app-level variables easily in a Windows Azure Table or Cache (either dedicated cache role or shared cache within your web role).
Can anyone tell me that if I use Session(inside an ASP.NET MVC 3 application) in Windows Azure environment with multiple instances(means multiple virtual machines), then it work without any configuration or I need to use ASP.NET Universal Providers or I need to handle this manually by using AppFabric?
You can't use in-process session state, but must use a shared session state provider.
The only supported session state model is to use Azure Cache, but you can use a provider that works with either Azure Storage or SQL Azure.
UPDATE:
I wrote some articles on my blog which go into using SQL Azure for session state with Entity Framework Code First. Hopefully, you'll find useful pointers there, even if you're not using Entity Framework.
Something to bear in mind using the standard SQL Server Session State Provider is that it doesn't have the retry logic which is considered good practice when working with SQL Azure.
This discussion on ASP.NET MVC providers may help you:
http://azureproviders.codeplex.com/discussions/276053
, also, look here for how to implement a session provider using Azure AppFabric Caching:
http://weblogs.asp.net/shijuvarghese/archive/2011/05/04/using-windows-azure-appfabric-caching.aspx
"...Without any configuration..."
As Steve Morgan mentioned, The Azure AppFabric Cache provides a supported mechanism for caching. The cache itself is independent from your compute instances. In fact, a single cache could be accessed by multiple applications, if you wanted to use it in such a way.
Regarding configuration, you'll have to modify web.config, as the AppFabric Cache has a custom cache provider. The web.config snippet itself is auto-generated for you via the portal; it's as easy as copy-n-paste.
You can find out more info on caching, including sizes and pricing, here.
I'm researching some Windows Azure stuff, in order to make a decision whether to move to Azure or not.
Basic information
To answer the question, you'll need some basic understanding of my app so here goes.
The app is an ASP.NET MVC 3 application that connects to a SQL Server database.
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server, deployed to IIS 7 as a website.
I have one SQL Server, where each instance has its own database.
I also have a set of Windows Services to do some background processing. That should be straight forward, as I'll just rewrite those to use a Worker Role in Windows Azure - most of the logic in the services is located in their own class (library) anyway, so the service it self just calls one or more methods in a class.
Now to the question
Whenever someone signs up for a free trial, I add a record to an Admin database I have.
I then have a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders, runs the database deployment script and updates the record to reflect that it has now been deployed, and finally sends an e-mail to the prospect that their free trial has been created - here's how you access it.
So, how can I deploy a new instance in Windows Azure from a Worker Role? Preferably, I'd just add a new website to an existing Azure instance and create a new SQL Azure database for that particular site to use.
Does this require a lot of work to set up? Is it even possible?
Based on two quotes, I would like to suggest calling this a multi-tenant application:
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server,
And...
a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders
If I understand correctly, there is "one" IIS server (well, in Windows Azure, it's one Web Role, scalable to multiple instances), and with each new "tenant", you set up some new stuff to support that tenant.
If that's indeed the case, you can definitely do this from a worker role - just look at Nate Totten's multi-tenant web role blog post and related code. Look at the webdeploy code that actually manipulates IIS.
Further: take a look at Cloud Ninja, a project a few of my teammates published along with Fullscale180. This is a multi-tenant app that demonstrates how to manage multiple customers in a single deployment, as well as monitoring and scaling.
Finally: should you need to actually create brand new service hosts and storage accounts, the latest updates to the Windows Azure Management API support this.
I hope that helps a bit...
I think most of the things you want to achieve are possible.
It will definitely require some work to setup!
For some ideas on how to achieve what you are looking for, take a look at the MS SaaS example - http://www.fabrikamshipping.com/ - especially designed for porting existing apps to SaaS on Azure. Inside this app they have an "onboarding process" - and that process includes setting up new SQL connections and new portals.
There's lots of good blogging (watch the video) about this on http://blogs.msdn.com/b/vbertocci/archive/2010/10/07/new-online-demo-introducing-fabrikamshipping-saas.aspx
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?
We are looking at a standard way of configuring the various "endpoints" of our application. Our application is a distributed system with Windows Desktop applications, Windows Server "services" and databases.
We currently configure each piece using XML files. This is getting a little out of hands as we work with larger customers who can have dozens of Servers running our application and hundreds of desktop clients.
Can anyone recommend a Microsoft technology or a third party that would allow us to centralize all that configuration information and manage it in a one place for all our applications? Any changes would be "pushed" to the endpoint(s) that are interested.
For example, if we were to change the login for one of our database, we would make that change on the database, then reflect that change in our centralized system. Following that last step, any service that needs to connect to the database would be notified of the change (and potentially receive the new data). How and what each endpoint does with that information is outside the scope of the system.
Our primary business is not "Centralized Configuration Services". We are a GIS company that provides solutions for various utilities worldwide.
I've done a couple of things to give myself this functionality over the years. I build enterprise applicatons that may be distributed across many servers. I don't want to bury config settings in each services config file or each web server's web.config file. For application specific stuff I usually create an application settings table in the app's database. The table only has two fields. SettingName and SettingValue. I then write a web or wcf service whose sole function it is to retrieve these settings. I write a function called GetSetting where you pass "SettingName" and it returns SettingValue or an empty string if your setting is not found. This way I can store all application settings for all components of the application in one spot. Maintenance and troubleshooting for this is really easy, I'm not hunting through scads of config files spread across a dozen web and app servers.
For larger scale apps I might create a separate AppSettings database where I add a new field to my table mentioned above. ApplicationName. My web or wcf service for this approach has the same method call (GetSetting) only at this scope I pass ApplicationName and SettingName and it returns SettingValue or an empty string.
Doing either of these things allows you to centralize all app settings for any size application or IT shop. It has worked really well for us.
You could use RSS together with BitTorrent to distribute changes. See Wikipedia. It is not MS specific however, but should provide the flexibility you need - a configuration server holding the configuration and providing the feeds needed to configure the clients and possibly servers.
Any VCS through a secure channel?
For example, git through ssh (both available in cygwin).
I think the first step is to have the secure channel (if you want the push ability, pulling might be different).
As for managing the "versions" in different "branches", what's better than a version control system?
As it goes for the Microsoft requirement, well the Microsoft sofwares in that exists in that area would suck pretty bad in your case (as in not the best tool for the job).