HostingEnvironment.IsHosted and HostingEnvironment.SiteName

[ritchxu]

When migrating an app from .NET full framework to ASP.NET Core (still hosted in IIS with hosting bundle), HostingEnvironment is no longer available. I was wondering what could be the equivalent/replacement for
properties like IsHosted and SiteName?

[davidfowl]

There are no IIS intrinsic APIs exposed in ASP.NET Core. Do you know what they were being used for?

[ritchxu]

We used IsHosted to determine if the codes are running inside IIS. And we use SiteName to find a specific site's logFile directory so we can clean it up.

[khellang]

SiteName alternative: IHostingEnvironment.ApplicationName, or if you just want the directory, you could probably use IHostingEnvironment.ContentRootPath.

IsHosted alternative: You could just try to pull an IIS server variable; HttpContext.GetIISServerVariable("SERVER_SOFTWARE"), but it's kinda ugly.

[davidfowl]

Now that we have in proc IIS we could add an API equivalent for IsHosted. Though I’d still like to know what things you currently have guarded behind that API?

[ritchxu]

Did a quick scan and found the following things behind the IsHosted API, although only the "Cleanup Logs" case matters for our migrating efforts:

1. Invoke HostingEnvironment.QueueBackgroundWorkItem API
2. ** Cleanup Logs (goes hands-in-hands with SiteName)
3. Retrieve ApplicationVirtualPath (also matters, but correct me if I'm wrong, I believe we have equivalent for this)
4. Look up setting using WebConfigurationManager.AppSettings[key]
5. Use GlobalConfiguration.Configuration for assembly resolver purpose

[davidfowl]

• Invoke HostingEnvironment.QueueBackgroundWorkItem API

Not required anymore. We don't have an equivalent in the new world see dotnet/extensions#805.

• ** Cleanup Logs (goes hands-in-hands with SiteName)

Seems like you can use ContentRootPath for that.

• Retrieve ApplicationVirtualPath (also matters, but correct me if I'm wrong, I believe we have equivalent for this)

There's no global equivalent in the new world. What are you using it for?

• Look up setting using WebConfigurationManager.AppSettings[key]

You would just use the new IConfiguration API instead.

Use GlobalConfiguration.Configuration for assembly resolver purpose

I dunno what this is but it sounds like IsHosted is required.

[ritchxu]

• Retrieve ApplicationVirtualPath (also matters, but correct me if I'm wrong, I believe we have equivalent for this)

There's no global equivalent in the new world. What are you using it for?

Our use behind ApplicationVirtualPath varies, we probably should evaluate them case by case and see if ContentRootPath or WebRootPath applies

[MihaMarkic]

@khellang

SiteName alternative: IHostingEnvironment.ApplicationName

But is it really? From my experience ApplicationName is not returning SiteName ever.
I'd still like to get SiteName. I would use it to differentiate the app settings. Imagine having the same exact app files (same directory) running under different site names. I would use SiteName to apply slightly different settings. /cc @davidfowl

[khellang]

SiteName alternative: IHostingEnvironment.ApplicationName

But is it really? From my experience ApplicationName is not returning SiteName ever.

It's never returning IIS' SiteName, no. I was merely suggesting an alternative string to use instead of SiteName.

[MihaMarkic]

Ah, ok, but that doesn't help, since ApplicationName is always the same.

[MihaMarkic]

@khellang Is it correct to state that IHostingEnvironment.ApplicationName returns merely an assembly name, but not the actual Applicaton Name from IIS?

[khellang]

Indeed;

https://github.com/aspnet/AspNetCore/blob/1480b998660d2f77d0605376eefab6a83474ce07/src/DefaultBuilder/src/WebHost.cs#L45-L46