I have an Azure Website developed for which I would like to reduce the initial loading time. On a regular ASP.NET site I would configure the Application Initialization IIS module, but with Azure Websites direct IIS configuration is not possible.
The website is running in reserved mode if that makes any difference.
Actually, Application Initialization module is installed by default for Azure Web Apps. You can directly configure it from either your web.config file or through apphost.config XDT. Just stick something like below in a web.config in the root of your web app.
<system.webServer>
<applicationInitialization
doAppInitAfterRestart="true"
skipManagedModules="true">
<add initializationPage="/default.aspx" hostName="myhost"/>
</applicationInitialization>
</system.webServer>
Application Initialization is not supported with Windows Azure Websites. because it is a native module and Windows Azure Websites does not allow configuring native modules via web.config.
Alsom the content for Windows Azure Websites are physically located at a centralized location and from there they loaded and executed to webservers. While shared instance gets a slice of host VM, versus reserved instance get a full host VM to run your web applications, in both cases the website application is coming from same centralized located so it does not matter if you have reserve instance to get Application Initialization working.
Application Initialization is necessary for your application and your websites is running in reserve mode, you can use Azure VM or Windows Azure Web Role to have it working.
Currently there's "Always On" setting for Azure Websites which does pretty much the same thing.
Related
In my current project. The previous dev has hosted an asp.net core 6 Web API as a window service using Kestrel on azure window virtual machine. I have to create a replica on the same API; please take a reference to the below links.
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/windows-service?view=aspnetcore-6.0&tabs=visual-studio
https://dev.to/sumitkharche/how-to-host-asp-net-core-3-1-web-applications-as-windows-service-52k2
I can create, build and install the API as a window service in an azure virtual machine and local machine as well, which also works in localhost: port.
Now I want to map that API to some domains like www.someting.com. But cannot find a way how to map a domain.
In this window service way, API hosting is pretty new to me, and there is also not enough documentation that can help me.
Please suggest.
I've created a simple Stateful Actor and a Web API (self hosted) and deployed it to Azure. It has worked and I can browse the nodes in the Service Fabric Explorer.
Azure gives me a url but when I add /api/values to the end (which works fine locally) it downloads a file called values and I can't open it as it is a binary file.
I want to call the web api from a Xamarin app (ie normal Rest api call) but if I can't call it via a browser I'm a bit stuck.
I would comment this on Stephen's answer, but I lack sufficient reputation.
To add a custom port to the Load Balancer after the service fabric cluster has been created you can (in the newer Azure portal):
Navigate to the load balancer resource for your service fabric cluster.
Under "Settings" find the "Load balancing rules" option.
This will have at least two rules, more if you did setup custom rules during the setup of the cluster.
Add a new rule.
Give it a name
'Port' is the external port you'd like to hit.
'BackendPort' is the port your service is configured to listen on.
The defaults on the other settings work in a pinch.
Note if you have multiple ports to enable, they each need their own rule.
I do know the above worked in my 'hello world' sandbox project.
I'm climbing the service fabric learning curve myself so I can't comment with authority on the other settings.
Have discovered what was missing.
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cluster-creation-via-portal/
This link here walks through creating the Service Fabric app on Azure and in particular the field "Application input endpoints" needs to have the port you want to use. For the samples, they are mostly port 80 or 8081.
There is supposed to be a way to add these ports afterwards which I tried (and so did a Microsoft support engineer) and it did not seem to work. You are supposed to be able to add these ports to the Load Balancer associated with the Service Fabric App.
I recreated my Service Fabric app, exactly as I did before but this time filled in the ports I want to use in the Node Type section and now I can hit the webapi services I've deployed. This field can be left blank which is what I did first time round and was why I had issues.
Not really related to Service Fabric, it's just how you set up your HTTP response headers in Web API. Recommend tagging this with asp.net or asp.net-web-api for a more thorough answer.
Tutorials and technical resources around Azure Service Fabric Stateless Web API tend to be slightly disjointed, given that the platform and resources are still quite immature.
This Stateless Web API tutorial, at the time of writing, is very effective.
As prerequisite to the tutorial:
Update Visual Studio to the latest version (Extensions and Updates)
Update the Service Fabric SDK to the latest version (Web Platform Installer)
Explicitly specify the EndPoint Port attribute (defined in ServiceManifest.xml) when setting up your Azure Service Fabric Cluster Node Type parameters
Following these steps will successfully allow deployment to both local and remote clusters, and will expose your Web API endpoints for consumption.
When inspecting a dump file from our application in NTSD, I ran the !DumpDomain SOS command. I was expecting to see just the system, shared and default app domains, but in addition the was a domain called /LM/W3SVC/2/ROOT-1-130793976001194923 which had loaded quite a few assemblies.
Where does this app domain come from and what is the purpose? Our app is hosting IIS - is IIS creating this app domain?
Yes, IIS creates an AppDomain per website like
/LM/W3SVC/2/Root/Website1-x-xxxxxxx
/LM/W3SVC/2/Root/Website2-x-xxxxxxx
If one of the .NET application crashes, it will not affect the others.
From MSDN:
When a request first enters managed code (managed modules or handlers), the IIS ManagedEngine module creates an application domain. The application domain then performs necessary processing tasks, such as authenticating a user with Forms authentication or other application services provided by managed code.
Can I use Dreamweaver to build an HTML based site and then upload this site to the Azure platform via ftp, more specifically will Windows Azure recognise the default page for my website without explicitly having to reference it in the URL?
Azure PaaS (either Cloud Services or Web Sites), no.
Azure IaaS, yes... with a bunch of initial setup.
You could spin up an Azure VM and host a plain HTML web site from within IIS there. You would need to configure the IIS web site (e.g. start page) and set up the FTP server when you first provision the server.
My gut feeling is that Windows Azure is not a very economical hosting model for a project of this kind though.
This question has probably less to do with actual programming and more to do with environment setup.
I'm developing an application for a Windows CE device, which will use a service hosted in Microsoft Azure. Obviously, this is all under development, and the service itself has not yet been uploaded to Azure. So I'm using the emulators provided by MS to deploy the service locally. Also, I don't think uploading the service to Azure just to debug it is a good idea, as that could net us a bill for Azure we don't yet want to pay.
Also, please note, I'm using VS2008 for the Windows CE project and VS2010 for the Azure project (thank you MS for dropping support for mobile devices -_-).
The problem is, the service seems to be accessible only via 127.0.0.1 or localhost, and if I physically connect a Windows CE device or use an emulated one, it becomes a new entity on the network, and cannot access that service any more.
How can I debug my Window CE application and have it see the service, whilst still being able to debug the service itself?
You are correct, the development fabric (the compute emulator that allows you to build an azure application and debug it locally) is only meant for local development. There are some hacks that allow you to get around that, but I wouldn't recommend it.
My recommendation would be to spin up the service in a more traditional hosting environment, at least in these early stages. You can define it as a web app just as you always would have, and get it functioning. Then, when you know its mostly complete, create a cloud service project and do an add existing to bring your web app into the cloud service solution. Once in, its a simple matter to add the web app as a web role.
From there, you can complete testing of the service in both the local and hosted azure environments as needed. This allows you to minimize your development costs while still leveraging the power of the cloud. As an upside, you also have done most of the basic work to ensure your service is compatible with multiple deployment scenarios giving you a greater degree of choice for its final production state.
OK, I don't know if this was intentional, or if I found one of the mentioned hacks, but I saw that IIS hosts the Azure site I created on port 5100, and the binding for this site is *, so it accepts all connections.
Using this I could access the service from my emulator, and I could still debug all Azure related stuff.