We Keep Coding

How do you pull values from a linked App.config in Web application when Web.config exists?

I have a mvc .NET web application written in C# and I have a web.config file associated with it for web specific configuration values. I also have a windows service application that will be running on the server in the background that has a App.config associated with it. I have linked the file within the web application and can see the file with updated values. But I am unable to use those values in my controller to display them to the UI. Is there a way to make a call to the app.config values to use in the controller and views of the web application? Right now it seems like they are coming in null due to them not being in the web.config.
Any help is apprecaited.

As long as permissions are worked out, you should be able to open the shared config file thusly:
var map = new ExeConfigurationFileMap();
//TODO: resolve this path in whatever way makes sense for your situation.
map.ExeConfigFilename = #"C:\MyConfig.config";
var config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
//do something with config, e.g. config.AppSettings.Settings["Blah"];
Otherwise, you can do something like put shared settings into machine.config, but it's typically wise not to mess with that file.

ASP.Net Core Web API, deployed under IIS is returning 404

I have a new Web API developed in ASP.NET Core. This Web API is supposed to be deployed in IIS and will have to work over SSL, so I have the [HttpsRequired] attribute on all my controllers. I struggle to make it work while deployed, so for now I relaxed the requirements and commented out those attributes. Doing so, I was able to create two bindings in IIS, one for HTTPS and one for HTTP. Given that my Web API is created in ASP.NET Core, I followed the deployment steps Rick Strahl has in his excellent blog post. I have selected "No Managed Code" for the .NET CLR version. The IIS machine is a 64-bit Windows Server 2012 R2 environment - not sure whether this matters or not. The .NET Core Windows Server Hosting bundle has been installed on the server and I can see the AspNetCoreModule listed in the Modules grid.
If i try to access the Web Api (I created a very simple GET method that returns some information regarding the assembly) with Fiddler, I get a 404 error. For now, i run Fiddler on the same machine, so I tried all combinations (localhost, IP address and full machine name in the domain).
No errors are logged in the EventViewer. Does anyone have any suggestion on how to troubleshoot this issue?
TIA,
Eddie
EDIT1: Here is my controller:
[Route("api/info")]
//[RequireHttps]
public class InfoController : Controller
{
private ITncRepository _repository;
public static ApplicationAssemblyDetails ApplicationAssemblyDetails { get; set; }
public InfoController(ITncRepository repository)
{
_repository = repository;
ApplicationAssemblyDetails = ApplicationAssemblyDetails.Current;
}
[HttpGet("")]
public JsonResult Get()
{
return Json(new WebApiInfoModel()
{
CurrentTime = DateTime.Now,
CurrentUtcTime = DateTime.UtcNow,
AssemblyName = ApplicationAssemblyDetails.ApplicationAssembly.FullName,
VersionNumber = ApplicationAssemblyDetails.VersionNumber,
BinFolder = ApplicationAssemblyDetails.BinFolder,
BuildMode = ApplicationAssemblyDetails.BuildMode,
TradeMark = #" © 2016-2017 * SomeCompany (www.somecompany.com)"
});
}
}
The ApplicationAssemblyDetails is a nuget package that gives some info about the current assembly. WebApiInfoModel is my model class for the Web API Information I want to pass back as a test to the client.
The web.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\My_ASP_NET_Core_Web_API.exe" arguments="" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" />
</system.webServer>
</configuration>
Finally, to answer your last question, Ignas, I use a Publishing Profile that uses the File system as a method, targets the .NET Framework 4.5.2, using the release configuration. Given that my project is a Web API and not an MVC 6 Web Application, the publishing package creates a stand-alone application. Since the clients need to call my Web API using SSL, I think that it has to be hosted in IIS, so running the standalone application would not work. Of course, for testing purposes, I could try to run it. That's why I commented out the [HttpsRequired] attribute. I will try that and report back, but for now I hope I gave you all the information you required.

I'm having a setup very close to yours (Asp.Net core, Web API, IIS, HTTPS ...) working fine on my end.
I faced the same issue at some point because I was not using the proper path to access my controller/action, it depends on how you deployed it under IIS. For instance, in my case when I use Kestrel directly it goes through a URL like that:
http:// localhost:5000/controllerName/actionName
But I can also contact my Web API via IIS and in that case I need to use a URL like that:
http:// localhost:5001/applicationName/controllerName/actionName
Have you created an application under IIS that could explain you getting a 404 because you would not use the proper path?
For instance, in my case:
screenshot of the asp.net core api under iis
And I'm accessing it, through the URL:
https: //servername:serverport/RequestPortalAPI/ControllerName/ActionName

In the end, it was a matter of properly configuring Widows Authentication. For Fredrik and anyone else reading this post for a solution, these are the steps I performed:
In IIS, in the Authentication form for my Web API, I disabled Anonymous Authentication and I enabled Windows Authentication:
Make sure that "Negotiate" is at the top of the list for Enabled Providers:
In the Application Pools, I configured my Web API to run under an account that the UIT department of my client has given me:
The configuration file of my Web API (web.config) contains the following settings:
Now we are getting into the dark areas of the problem. In order to use Windows Authentication and let the credentials of the caller be passed through to the backend (in my case a SQL Server database), the Web API has to be configured to use Kerberos. I found this after I opened a ticket with Microsoft and I worked closely with one of their engineers. For this to happen, you need to follow these steps:
Create a Service Principal Name (SPN) for your Web API and the domain account it runs under. You need to run this command:
Where hostname is the fully qualified domain name of your Web API. The Domain\Username are the domain account under which the Web API is running. You need special domain privileges, so you may want to involve someone from IT. Also, from now on, you need to access your Web API by the full domain name, not by IP address. IP address won't work with Kerberos.
Also, with the help of your IT person, you need to enable delegation for any service using Kerberos for the domain account under which you run your Web API. In the Active Directory Users and Computers, locate the account you use to run your Web API, bring up its properties, click on the Delegation tab and enable the second option "Trust this user for delegation to any service (Kerberos Only):
We have also made some changes on the server that runs our database, but I am not 100% those are truly required, so I won't add them here because I don't even know if you use SQL Server or some other backend repository.
Let me know if you need those as well and I will add them later.
Good luck,
Eddie

config web service from code behind

I am creating a windows mobile 6 application which will consume a web service (.asmx) for different clients.
As I know, I will need to manually “Add Web Reference”; then I will be able to call those functions.
Is it possible to configure web reference as a variable from code behind?
That way I can keep the url of web service in a text file. For different client, I just need to edit that text file instead of recompile that application again.

You'll have to add the Web Reference at design time.
At runtime, you can modify the URL of your target web service using the Url property. Here's an example of pulling the target URL from the app.config:
var ws = new MyWebService();
ws.Url = ConfigurationManager.AppSettings["SomeUrl"].ToString();
The only catch here is that the WSDLs of the design-time and run-time services must match.

Yes, just add something like :
<configuration>
<appSettings>
<add key="WebReference" value="URLofASMX"/>
...
then call it by :
string URL = ConfigurationManager.AppSettings["WebReference"].ToString();
You'll need to possibly add a new reference to System.Configuration to the project if you can't access ConfigurationManager just by including System.Configuration.

ASP.NET MVC Configuration Manager error

The WSAT throws the following irrespective of the project or the connection type,
An error was encountered. Please
return to the previous page and try
again.
Even on a brand new ASP.NET MVC 2 website where user authentication and registration work through the default account controller without a quibble, the WSAT fails to run.
Things I've tried,
Tried to open it in IE.
Tried to use it with MySQL to setup
user authorization, role and profile
management. This was the goal which
is starting to seem more and more
like an uphill battle.
Tried it with a brand new ASP.NET
MVC 2 application.
Help would be greatly appreciated.

Found it. Apparently the configuration manager will not work if the directory path to the solution contains invalid characters, in my case it was a space.
Should be documented somewhere, this was a good waste of four hours..

Http modules integrated into IIS 7 processing pipeline

Q1 -IIS7 by default automatically registers FormsAuthenticationModule ( which is defined in root web.config file ), but does the term “Http module being integrated into IIS 7 processing pipeline refers” only to cases where this registered module is also configured to work with non-Asp.Net applications?
In my opinion if module is not configured to work with non-Asp.Net applications, even if it is automatically registered by IIS 7, then we can’t really claim that it is integrated into IIS 7’s processing pipeline?!
Q2
A) IIS7 automatically registers some of the modules defined in root web.config file.
If we configure ( via IIS7 manager ) UrlAuthorizationModule ( which is defined in root web.config and which IIS 7 registers by default ) to be used with non-Asp.Net apps also, then IIS7 puts the following entry into application’s root web.config file:
<modules>
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="" />
But why did IIS 7 also include <remove name="UrlAuthorization" /> element?
B) I assume if we then change our mind and decide to use this module only with Asp.Net applications, we can safely remove the following element:
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="" />
from application’s root web.config file, since now our application can use UrlAuthorizationModule defined in root web.config?!
Q3
I realize IIS7 by default registers FormsAuthenticationModule defined in root web.config file, but assume we register another FormsAuthenticationModule in web.config contained in a root directory of some web application.
I assume when request for web page is received, two instances of FormsAuthenticationModule will be executed for that request?
thanx
EDIT:
A1.
"integrated" vs "classic" processing pipelines is a property on the application pool. It is correct that modules can be set to run only in "integrated" pipelines.
My question was referring to IIS 7 in integrated mode. Namely, my book uses the term “Http module being integrated into IIS 7 processing pipeline refers” to describe a situation where custom Http handler has been registered with IIS 7 (running in integrated mode). But it doesn’t say whether the term refers to situation when this registered handler is configured to work with non-asp.net applications also or do we also use this term when registered Http handler is configured to only work with Asp.Net applications?
A2. B. Yes, you can remove the "remove" as well as the "add" lines. This is what the GUI will do if you change it back to inherit the settings.
But in my case IIS 7 doesn’t remove
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="" />
from application’s root web.config file,,it just changes the value of preCondition attribute back to "managedHandler"
A3. I think you'll get an error if you try to add 2 modules that have the same "name" attribute. If you really want it in there twice then change the "name" of the 2nd one.
I apologize, I should be more specific, but my question was referring to a situation where two modules would have different names.
So in that case there will be two instances of FormsAuthenticationModule running?
thanx

Just noticed that you are using Stackoverflow. Please check my latest answers at iis.net.
http://forums.iis.net/t/1157580.aspx
An important thing is that applicationHost.config and root web.config actually have different meaning still, so don't be confused if an item appears in both files. That actually has different meanings.

A1. "integrated" vs "classic" processing pipelines is a property on the application pool. It is correct that modules can be set to run only in "integrated" pipelines.
A2.
A. In order to change the "preCondition" attribute, it had to remove the first version and add it again.
A2. B. Yes, you can remove the "remove" as well as the "add" lines. This is what the GUI will do if you change it back to inherit the settings.
A3. I think you'll get an error if you try to add 2 modules that have the same "name" attribute. If you really want it in there twice then change the "name" of the 2nd one.