OK so we have something that is currently using OpenExeConfiguration for reading a config file, however this doesn't work when running in the web context.
I've tried a variety of different ways of opening the web.config programmatically but I can't seem to get it to read the correct web.config file. In case it matters I am currently debugging it in VS 2008.
1. config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(System.Web.HttpContext.Current.Request.ApplicationPath);
2. config = ConfigurationManager.OpenMappedExeConfiguration(new ExeConfigurationFileMap { ExeConfigFilename = "web.config" }, ConfigurationUserLevel.None);
3. config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
4. config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(null);
5. System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(System.Web.Hosting.HostingEnvironment.ApplicationVirtualPath);
It either opens up the wrong config file (either the machine config, or the VS /IDE/Web.config) or complains about the error:
{System.Configuration.ConfigurationErrorsException: An error occurred loading a configuration file: Failed to map the path '/'. ---> System.InvalidOperationException: Failed to map the path '/'.
Edit -
OK so a combination of
config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
AND running Visual Studio 2008 As Administrator worked. Am hoping we don't run into security/permission issues when we deploy to our web server / client environments!
So in the end I used this code (had to handle whether the web application was running, or if our unit test code was running).
System.Configuration.Configuration config = null;
if (System.Web.HttpContext.Current != null && !System.Web.HttpContext.Current.Request.PhysicalPath.Equals(string.Empty))
config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
else
config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
Also have to be running Visual Studio in Administrator mode - which I found out you can set as a property on your shortcut so you don't need to remember each time in Windows 7 to right click and run as administrator :)
Related
I create release pipeline on Azure DevOps server and i have a some problem.
How i can change properties in .net core configuration file (appsettings.EnvName.json).
When I create application on framework I had parameters.xml where I set XPath to value, default value and property name. And on pipeline I set key-value. But on net core app this method don't work =)
I want to use about the same approach. What would I indicate the path to the value and its value. For example:
ConnectionStrings.Db1="Server={DB1.Server};Database={DB1.DbName};Trusted_Connection = True;"
ConnectionStrings.Db2="Server={DB2.Server};Database={DB2.DbName};Trusted_Connection = True;"
Now I have added a step to execute an arbitrary powershell script on a remote server
$jsonFile = 'appsettings.Template.json'
$jsonFileOut = 'appsettings.Production.json'
$configValues =
'ConnectionStrings.Db1="Server={DB1.Server};Database={DB1.DbName};Trusted_Connection = True;"',
'ConnectionStrings.Db2="Server={DB2.Server};Database={DB2.DbName};Trusted_Connection = True;"'
$config = Get-Content -Path $jsonFile | ConvertFrom-Json
ForEach ($item in $configValues)
{
$kv = $item -split "="
Invoke-Expression $('$config.' + $kv[0] + '="' + $kv[1] + '"')
}
$config | ConvertTo-Json | Out-File $jsonFileOut
But I don’t really like this solution, how can I do the same in a more beautiful way
dotnet core handles this in a different way. Full framework based on app.config transformation. It means that you defined one file which later was trasnformed for given build configuration (like Debug, Release, or your own). In dotnet core you define appsettings.json for each environment. This works very well because all settings are in your compiled app. And then at runtime bases on ASPNETCORE_ENVIRONMENT environment variable a proper settings is selected. Thus you may have one package for your all environments without recompilation. To benefit from that you must define file per each enviroment, but this is not transformation. This is full file.
For instance file for your local development may look like this:
{
"ConnectionStrings": {
"BloggingDatabase": "Server=(localdb)\\mssqllocaldb;Database=EFGetStarted.ConsoleApp.NewDb;Trusted_Connection=True;"
},
}
And file for your dev enviroment appsettings.dev.json like this:
{
"ConnectionStrings": {
"BloggingDatabase": "Server=102.10.10.12\\mssqllocaldb;Database=EFGetStarted.ConsoleApp.NewDb;Trusted_Connection=True;"
},
}
And then to configure loading this file you have to have configured Startup method:
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
.AddEnvironmentVariables();
this.Configuration = builder.Build();
}
This will load all your appsettings file and later use proper file based on enviroment variable.
To set this variable you may use this command in command prompt setx ASPNETCORE_ENVIRONMENT Dev or this in Powershell [Environment]::SetEnvironmentVariable("ASPNETCORE_ENVIRONMENT", "Dev", "Machine")
I hope it help you understand how settings works on dotnet core. If you need more guidance please check this links:
Configuration in ASP.NET Core
Use multiple environments in ASP.NET Core
To sum up you don't need to change your settings in release pipeline. You need to preapre full file per enviromnet where you are going to host your app. You can be interested in replacing some values in file based on variables in your pipeline. You can consider few options here like
token replacement
JSON variable substitution example
This is usefult when you don't want to keep your secrets directly in source code.
EDIT
If you want to replace values in you appsettings file one of the option is token replace. For this you must first instead of values keep token in your file. For instance #{SomeVariable}# will be replaced with value of SomeVariable` from your pipeline for this confirguration of token replace task.
I have ASP.NET Core (2.1) project that has appsettings.json. I use WebHost.CreateDefaultBuilder(). The appsettings.json file has following configuration in File Properties:
Build Action: Content
Copy to Output Directory: Do not copy
After build the appsettings.json ends up in bin\Debug\netcoreapp2.1\MyProj.runtimeconfig.json.
The ASP.NET Core runtime loads it fine.
I created WebJobs (for .Net Core 2.1) and wanted to do the same - set Build Action to Content and let it loaded. In the Main() of Program.cs I have code like
var builder = new HostBuilder()
...
.ConfigureAppConfiguration(b =>
{
var environment = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
b.SetBasePath(Directory.GetCurrentDirectory());
b.AddJsonFile("appsettings.json", false, true);
b.AddJsonFile($"appsettings.{environment}.json", true, true);
b.AddEnvironmentVariables();
// Adding command line as a configuration source
if (args != null)
{
b.AddCommandLine(args);
}
}
But the runtime tries to load appsettings.json (instead of MyWebJobProj.runtimeconfig.json). So I had to set Build Action to None and Copy to Output Directory to Always.
However I would prefer the same approach like in ASP.NET Core - it handles somehow the file name transformation. Although in WebHost.CreateDefaultBuilder() is basically the same code like I have in my WebJob. What does the magic file name transformation in the configuration and why it works only in one type of project?
The file [ProjName].runtimeconfig.json has a completely different meaning than appsettings.json. Ensure that appsettings.json was copied to output (set 'Copy to output' to 'always' or 'newer').
I know you can open files from Symfony profiler or exception file links using this in project/app/config.yml :
framework:
ide: "phpstorm://open?file=%%f&line=%%l"
More info: http://developer.happyr.com/open-files-in-phpstorm-from-you-symfony-application
However as I'm using vagrant, the file path of the server doesn't match my host.
I have created a PHP web application server in PHPStorm with the propper path mappings, but still doesn't work.
Any ideas?
Thanks
When running your app in a container or in a virtual machine, you can tell Symfony to map files from the guest to the host by changing their prefix. This map should be specified at the end of the URL template, using & and > as guest-to-host separators:
// /path/to/guest/.../file will be opened
// as /path/to/host/.../file on the host
// as /path/to/host/.../file on the host
'phpstorm://%f:%l&/path/to/guest/>/path/to/host/&/foo/>/bar/&...'
Symfony FrameworkBundle Configuration - IDE
The answer given by Jeffry no longer works unfortunately :(. When In configure that with my paths the profiler throws:
ParameterNotFoundException
You have requested a non-existent parameter "f:".
I have configured the path according to this line in the SF docs: This map should be specified at the end of the URL template, which results in this:
phpstorm://open?url=file://%%f&line=%%l&/path/to/guest/>/path/to/host/
However, it does open PHPStorm, but phpstorm does not open the file, so i'm a bit stuck here now.
This solves the issue with the file not opening in PhpStorm from a Vagrant:
phpstorm://open?file=%%f&line=%%l&/path/to/guest/>/path/to/host/
Source: https://youtrack.jetbrains.com/issue/IDEA-65879
I have the following code to read the 'loggingConfiguration' from web.config file that is using EntLib 4.0
Configuration entLibConfig =
System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration
(#"/Web.config");
LoggingSettings loggingSettings =
(LoggingSettings)entLibConfig.GetSection(LoggingSettings.SectionName);
The loggingSettings object is null after the 2nd line executes.
Any suggestions on what is going wrong here?
ExeConfigurationFileMap exc = new ExeConfigurationFileMap();
exc.ExeConfigFilename = #"Web.exe.config";
Configuration _config = ConfigurationManager.OpenMappedExeConfiguration(exc,ConfigurationUserLevel.None);
LoggingSettings log = _config.GetSection("loggingConfiguration") as LoggingSettings;
Try this, it works for me.
The reason why you get null returned for LoggingSettings is that there is no LoggingSettings configured in the web.config that you are opening. This is probably because the path specified is incorrect.
I have a web appliation set up with 2 web.configs: The first in the root and the second in a Config folder.
/Root
web.config
/Root/Config
web.config
The web.config in the Config folder contains the LoggingSettings. The code to read the LoggingSettings from a page that is not located in the Config folder is:
Configuration entLibConfig =
WebConfigurationManager.OpenWebConfiguration(#"~/Config");
LoggingSettings loggingSettings =
(LoggingSettings)entLibConfig.GetSection(LoggingSettings.SectionName);
This should work in the Development Web Server as well as IIS.
Is there any reliable way how to check whether ASP.NET 4.0 registered on IIS 7.5 programmatically? I need to test it in the installer as prerequisite, before ASP.NET application installation start.
If ASP.NET 4.0 not registered on the IIS, later during the installation just installed application cannot be run and returns 500 internal server error (and it is too late to solve the problem). Instead, I want to show some warning (and hint how to solve the issue) before any installation steps started. But no reliable solution found yet.
AFAIK, registry entries reading sometimes may not work correctly. So now, I run aspnet_regiis.exe -lv to list versions (as suggested here) and parse the output. But even if .NET not registered correctly my test (falsely) succeeds, because the output is (contains version 4.0):
2.0.50727.0 C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll
4.0.30319.0 C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll
(Win7 32bit)
Running aspnet_regiis.exe -ir can repair it in this case.
It's similar issue as this question, but I need test it programmatically.
Do you have any ideas or experiences?
Using your own answer as a basis, this can also be done using the command line (with elevation):
%WINDIR%\System32\inetsrv\appcmd.exe list apppool /managedRuntimeVersion:v4.0
If anything is returned, ASP.NET 4.0 is registered.
The issue with this approach is that it seems to be possible to create 4.0 application pools manually even if the filter is not installed, and then this method would not work.
EDIT:
I have ended up running these three checks:
aspnet_regiis.exe -lv (should return a line containing "c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll")
appcmd.exe list apppool /managedRuntimeVersion:v4.0 (should return a line containing "MgdVersion:v4.0")
appcmd.exe list config -section:system.webServer/isapiFilters (should return a line containing "c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll")
Note that I only care about 32bit versions.
If all three checks pass, it can be concluded that ASP.NET 4.0 is registered. Still not 100% false positive-proof though.
This is an old question, but I'm posting an answer because your question is one of the top results on google, and it's unanswered.
The registry key you are looking for is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0. If that key is present, then .Net 4 has been installed and is registered in IIS.
If you just want to check if .Net 4 is installed, you can check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full.
In Powershell it could be done like this:
# load the IIS-Commandlets
Import-Module WebAdministration
# get the isapi filters currently loaded
Get-WebConfigurationProperty -Filter "/system.webServer/isapiFilters/filter" -name *
An output could look like this:
name : ASP.Net_4.0_32bit<br/>
path : %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll<br/>
enabled : True<br/>
enableCache : True<br/>
preCondition : runtimeVersionv4.0,bitness32<br/>
ItemXPath : /system.webServer/isapiFilters/filter[#name='ASP.Net_4.0_32bit']<br/>
Attributes : {name, path, enabled, enableCache...}<br/>
ChildElements : {}<br/>
ElementTagName : filter<br/>
Methods :<br/>
Schema : Microsoft.IIs.PowerShell.Framework.ConfigurationElementSchema<br/>
name : ASP.Net_4.0_64bit<br/>
path ........
Based on that we could write this code to check and install .NET 4 if needed:
$DotNet4Missing = $true
# lets make sure we got .net 4 correctly setup
$isapiFilters = Get-WebConfigurationProperty -Filter "/system.webServer/isapiFilters/filter" -name *
"/system.webServer/isapiFilters/filter count: {0}" -f $isapiFilters.Count
foreach ($filter in $isapiFilters)
{
"filter.name: {0}" -f $filter.name
if ($filter.name -eq "ASP.Net_4.0_64bit")
{
"-> Found .NET 4 - GREAT!"
$DotNet4Missing = $false
}
}
if ($DotNet4Missing)
{
"Missing .NET 4 IIS integration - running aspnet_regiis.exe"
$pinfo = New-Object System.Diagnostics.ProcessStartInfo
$pinfo.FileName = "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe"
$pinfo.RedirectStandardError = $true
$pinfo.RedirectStandardOutput = $true
$pinfo.UseShellExecute = $false
$pinfo.Arguments = "-iru"
$p = New-Object System.Diagnostics.Process
$p.StartInfo = $pinfo
$p.Start() | Out-Null
$p.WaitForExit()
$stdout = $p.StandardOutput.ReadToEnd()
$stderr = $p.StandardError.ReadToEnd()
"aspnet_regiis.exe stdout: {0}" -f $stdout
"aspnet_regiis.exe stderr: {0}" -f $stderr
"aspnet_regiis.exe ExitCode: {0}" -f $p.ExitCode
}
Summary: The problem described above occurs on non-server operating system (Win7). The .NET 4.0 is not registered on the IIS even if you install IIS before .NET 4.0 (and so .NET should be registered on IIS correctly). This causes unexpected problems during any ASP.NET application installation -- until aspnet_regiis.exe -ir is ran from the commandline. There is no problem with Win 2008 (i.e. when IIS installed before .NET 4.0 then .NET is registered correctly on IIS and everything works as expected).
So finally my colleague told me what possibly could be solution of the problem. I've verified that following solution works fine (also on Win7). ServerManager from Microsoft.Web.Administration namespace can be employed easily:
public static bool IsAspNetRegistered()
{
using (var mgr = new ServerManager())
{
return mgr.ApplicationPools.Any(pool => pool.ManagedRuntimeVersion == "v4.0");
}
}
In case of successful .NET registration on IIS, there is at least one application pool which runtime version is set to "v4.0" so this fact was used for the check.
Of course, if anybody deletes all application pools, this method can work incorrectly. But this is bit pathological situation I don't care. The main issue is to prevent that although everything is done according our installation recommendations, still not possible to install the application on the machine.