I am just wondering how SharePoint Timer Job works with external services.
We have a web part and timer job that both call external service. Web part didn't pass our proxy as well, but after we changed proxy setting in web.config of that web application it works now.
How can we set our Timer Job to pass the proxy? It seems that is not related directly to our web application where we have installed our web part.
Read the same web.config with this code:
SPWebApplication webApp = this.Parent as SPWebApplication;
Configuration config = WebConfigurationManager.OpenWebConfiguration("/", webApp.Name);
String appValue = config.AppSettings.Settings["appSettingKey"].Value;
Related
On IIS I can configure my web-service with Application Initialization, AlwaysRunning and Preload enabled to make sure the first request is fast enough. Now I am trying to create a similar web-service within Microsoft Azure. However, the first request is exteremely slow. I tried to speed it up using "Always on", but this doesn't work. What configuration is needed to make sure the warm-up works correctly in Azure?
I would like to make Azure react the same way as IIS when restarting the application or refreshing the web.config. Besides the "Always on" functionality, I can't find the settings that are needed to do this. I have searched on other pages, but most solutions are about the warm-up of a website page. Is there a (simple) configuration to use for the warm-up of a web-service within an Azure app service?
Have you enabled Preload?
When you create the Web Service Application in azure...
Under Settings, Configuration, Path Mappings..
I have a simple asp.net core 2.0 WebApi app running in Kestrel behind an IIS reverse proxy. The single route is pretty simple, it just makes a http request:
using (HttpClient client = new HttpClient())
{
client.BaseAddress = new Uri("http://www.google.ca");
HttpResponseMessage response = await client.GetAsync("/search?q=test&oq=test");
return Ok();
}
However, this request consistently takes 2-3 seconds to complete. Yet, if I run Kestrel directly without IIS, the same code takes ~100ms.
I followed all the Microsoft docs for configuring kestrel with IIS.
TL;DR Needed to configure HttpClient to not use the default proxy settings
HttpClientHandler clientHandler = new HttpClientHandler();
clientHandler.UseProxy = false;
using (HttpClient client = new HttpClient(clientHandler))
{ ... }
The long explanation is that asp.net attempts to use the machine's default proxy configuration settings for each request. My IIS is configured to run under the Network Service account which has limited access, and as such, will eventually fail (presumably because it doesn't have access to the registry) to find the proxy settings and just connect directly. This process apparently takes about 2.5 seconds.
For my kestrel tests, I was running dotnet .\api.dll from the command line, which uses my logged in credentials, and could successfully access the proxy settings. However, when using IIS, it spawns the dotnet process under the same Network Service account that IIS is running as.
Is it mandatory to refresh the application pool and website hosted on IIS 7.5 when are changes made to the web application's web configuration ?
It does it automatically, so no it's not mandatory to do it a second time, it just happens. :)
ASP.NET Core out of the box supports hosting in IIS and self-hosting scenarios using the Kestrel and WebListener HTTP servers. Accordingly to web.config / project.json looks like IIS is used, but if so it is not clear for my "why" so, as now IIS is acting just as a reverse proxy and the application itself runs as a separate process using the Kestrel HTTP server.
So the main question is "what" and "why" is used by default, if deploy to Azure?
Yes, when you publish to Azure App Services, IIS is used to host your application. As you said, it acts as a reverse proxy to your application, which is running Kestrel HTTP server. But IIS does more than that - it also manages the application process through application pool, which includes or may include:
restarting the app when web.config changes
starting the app on the first HTTP request
running the app as a specified user
recycling the app pool (and effectively restarting the app) on certain conditions
starting multiple app processes
handle webdeploy (this is what happens when you hit "Publish" in Visual Studio
In my MVC web app, one controller function (Validate) calls a service. See below code and note that MessageHandlerClient is a service proxy generated in Visual Studio. The service proxy call client.ValidateMessage(formdataasbson["HLmessage"].ToString()) works fine in my local dev environment. When I publish the project to Azure, calls to Validate controller function no longer work. Suspecting a problem with the proxy, I changed Validate() to give back hard-coded results, re-publish to Azure, and all works fine - confirming a problem with the web service proxy behavior in Azure.
[HttpPost]
public ActionResult Validate(String serializedformdata)
{
try
{
BsonDocument formdataasbson = this.serializer.JSONFormtoBSON(serializedformdata);
MessageHandlerClient client = new MessageHandlerClient();
this.jsonresponse.ReturnValue = "true";
StandaloneValidator.My_ServiceReference.Error[] results = client.ValidateMessage(formdataasbson["HLmessage"].ToString());
this.jsonresponse.ReturnMessage = results.ToJson();
return Json(this.jsonresponse);
}
catch (Exception ex)
{
this.jsonresponse.ReturnValue = "false";
this.jsonresponse.ReturnMessage = ex.Message;
return Json(this.jsonresponse);
}
}
What's more, I see details of the web service proxy in my local web.config file as below (IP intentionally obscured):
I have read various posts about web.config in Azure and the fact that it is not writable, so I'm suspecting my local ..... proxy info is never published in Azure. If indeed web.config does not publish from local to Azure, then I understand why my proxy doesn't work. The question is.....what should I do to fix??!
EDIT: I see various posts discussing migration of some settings from web.config to csfg files for Azure - perhaps a viable solution? Given that I am not coding manual read of these settings (I simply created service proxy from URL to service) I worry about auto-generated code or any "under-the-hood" behavior of the service not knowing how to read migrated settings from csfg.
Based on what you have written above, it seems you are confused with Web Role and Web Sites. First you would need to understand the difference between these two so you can make better decision on what to choose for your application. Here are some useful links:
SO discussion on difference between Azure Web Sites and Web Role
MSDN Article on when and why to choose Azure Web Sites and Web Role and Azure VM
Windows Azure Web site, you do not have full control over IIS web server and because of that some of the settings web site specific settings are configurable and others are not. In Windows Azure websites, most of machine and system specific settings added into web.config are overwritten so these settings does not work. Also you can not RDP to your Azure Websites instance as well.
If you have to use ASP.NET MVC application which MUST need proxy configuration, you must deploy it to Windows Azure Cloud Service.