You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 1, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 1, 2018. It is now read-only.
AspNetCoreModule – setting environment variables in web.config causes double entries with the same key (instead of overwriting existing ones) #235
Windows 10, IIS with AspNetCoreModule hosting an Asp.NET Core application on top of full framework.
Steps to reproduce
Let’s say there are some existing environment variables already set on the system. In our case these were COR_ENABLE_PROFILING and COR_PROFILER. See screenshot.
In web.config we wanted to overwrite these settings like this:
I looked into the environment variables for the process with Process Explorer and as you see both values are added to the process.
Expected behavior
The environment variables set in the web.config should overwrite the existing ones.
Current workaround
I created a runWebapplication.bat file, with the following content and in the web.config I replaced processPath=".\WebApplication4.exe" by processPath=".\ runWebapplication.bat".
@echo off
SET COR_ENABLE_PROFILING=0x01
SET COR_PROFILER={B7038F67-52FC-4DA2-AB02-969B3C1EDA03}
WebApplication4.exe
changed the title [-]AspNetCoreModule – settings environment variables in web.config causes double entries with the same key (instead of overwriting existing ones) [/-][+]AspNetCoreModule – setting environment variables in web.config causes double entries with the same key (instead of overwriting existing ones)[/+]on Jul 18, 2016
The one from web.config should mask the system one, right?
Yes, that is what I would expect, but in my case the system wide setting wins. And btw. when I use my own bat file Process Explorer shows only 1 entry (so in that case it is really overwritten).
And another question: I guess all this is done by the aspnetcore module. Is that also opensource? I would look into that...
as scanning the variables are quite expensive, I changed the order of importing the environment variables, i.e., import user defined one first and then system ones. This will allow user to overwrite the system ones. The fix was checked in. It will be available at next release.
Activity
[-]AspNetCoreModule – settings environment variables in web.config causes double entries with the same key (instead of overwriting existing ones) [/-][+]AspNetCoreModule – setting environment variables in web.config causes double entries with the same key (instead of overwriting existing ones)[/+]Tratcher commentedon Jul 18, 2016
Which one do you see in effect inside the process? The one from web.config should mask the system one, right?
gregkalapos commentedon Jul 18, 2016
Yes, that is what I would expect, but in my case the system wide setting wins. And btw. when I use my own bat file Process Explorer shows only 1 entry (so in that case it is really overwritten).
And another question: I guess all this is done by the aspnetcore module. Is that also opensource? I would look into that...
muratg commentedon Aug 10, 2016
@pan-wang Any updates on this?
shirhatti commentedon Aug 16, 2016
@muratg We will fix this in 1.1.0
An environment variable defined in
web.configwill take precedence over the system environment variablegregkalapos commentedon Aug 25, 2016
But why isn’t this part open source? Or I just did not find it?
muratg commentedon Aug 25, 2016
@gregkalapos ANCM will be open source soon.
pan-wang commentedon Oct 11, 2016
as scanning the variables are quite expensive, I changed the order of importing the environment variables, i.e., import user defined one first and then system ones. This will allow user to overwrite the system ones. The fix was checked in. It will be available at next release.
muratg commentedon Nov 7, 2016
@pan-wang @shirhatti is this good to close?
shirhatti commentedon Nov 7, 2016
Yes. This was fixed in v1.0.1969