I know that others have posted this problem, but none of the solutions I've seen appear in my case. I have an ASP.NET WebAPI application. I've been able to publish it to two different development servers, via Visual Studio Publish. On both target servers, I set the ASPNETCORE_ENVIRONMENT environment variable to Development via the Windows GUI and the app picks this up, uses my appSettings.Development.json settings, and works as expected.
Now I'm deploying it to my Test server. On that server I set ASPNETCORE_ENVIRONMENT environment variable to Test via the Windows GUI, but when the application runs, it always says Hosting Environment: Production. I've checked my launchSettings.json file as one post suggested, but nothing in there sets the environment variable to Production. Since Production is the default, I don't have code that sets that value anywhere.
My successful deployment to my Dev server and my failed deployment to my Test server were both done via dotnet publish executed from Bamboo.
I don't know why the application running on my Test server is not picking up the ASPNETCORE_ENVIRONMENT Test setting.
A few other details that I thought of over the weekend, which may or may not be relevant.
VS Publish to Windows Server 2008 R2, debug build, works as expected. Target server has ASPNETCORE_ENVIRONMENT set to Development, application log reports Hosting environment: Development, and appSettings.Development.json settings are in effect.
Both VS Publish and Bamboo deploy (via dotnet publish) to Windows Server 2016, debug build, works as expected. I have two instances of the site on this server. One relies on the ASPNETCORE_ENVIRONMENT variable, which is set to Development, and works as expected. The other overrides the environment variable for its app pool via a setting in applicationHost.config. In both cases, the applications correctly pick up the environment variable and reflect the correct hosting environment.
Bamboo deploy via dotnet publish to Windows Server 2012, release build, does not work as expected. Application reports the hosting environment as Production (the default), suggesting that it failed to pick up the environment variable I set. The application fails because it is missing the app settings from appSettings.Development.json.
So the failing scenario is a different server O/S, but since it works on both 2008 and 2016, I would think it would work on 2012. And the failing scenario is a release build vs. a debug build, but I wouldn't think that would impact the runtime behavior re configuration.
I don't think it's a launchSettings.json issue, because that would presumably affect all of my target deployments, not just my Test server. I have confirmed via command line that the environment variable is correctly set. I don't really want a web.config-based solution, which I don't think I should need and which will require environment-specific transforms.
Some more things I've tried that haven't helped:
Changed the build type from Release to Debug (since it is Debug in the environments that are working). Still doesn't work.
Tried logging other environment variables, but application dies before it gets to my logging code. Still working on this...
Tried setting the environment variable in applicationHost.config as I'd done on my Development server, but Test server is Windows Server 2012 and IIS 8 and does not support the element in applicationHost.config. (Dev server is Windows Server 2016 and IIS 10, which does support the element in applicationHost.config.)
Tried VS Publish vs. Bamboo deploy. Still doesn't work.
I compared .NET Core installations on the Dev and Test servers. Both have host version 2.2.3, same commit. Dev server has SDKs installed; Test server does not. Dev server has multiple runtime versions installed, latest being 2.2.3. Test server has only 2.2.3 runtime installed. The main difference seems to be the SDKs and I assume I shouldn't need the SDK installed in order to read the environment variables.
I think I've hit this and solved it before. I had to set LoadUserProfile to True in my IIS app pool advanced settings. I'm not sure why this is true because things I've read have said that you need this to read user environment variables and my app is failing to read system environment variables. But, whatever the case, when I set LoadUserProfile to true on my IIS app pool, the app correctly reads the ASPNETCORE_ENVIRONMENT system envrionment variable and the app works as expected.
Have you tried setting this value in the web config?
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
I am trying to debug a webservice remote on Microsoft Azure. The service is running in a web role.
I have configured remote debugging in the publish settings an can attach the debugger to the web role. Also, when I have selected the correct process, the debug symbols are loaded correctly and breakpoint's tool tips say that the breakpoint is hosted in "WallSHost.exe" which is the remote process.
What I would like to do, is to run a local client software which I am developing and step into the server code from there. When I step into the according service client call (F11), I get the above error message, saying (for the sake of Google in plain text here):
Unable to automatically step into server. Connecting to the server
machine 'xyz.cloudapp.net' failed. The Microsoft Visual Studio Remote
Debugging Monitor (MSVSMON.EXE) does not appear to be running on the
remote computer. This may be because a firewall is preventing
communication to the remote computer.
I have tried to disable the firewall on my (the client) machine with no effect. Has anybody seen that before or can tell me how fix this problem?
A quick checklist
deployed cloud service is a debug build
a debug build is selected from Build Configuration list (in publish wizard)
'Enable Remote Debugger For All Roles' is checked
no changes to code since deployment
My application runs fine on my machine (Windows laptop) but not on production machine (Windows Server 2012). I don't have administrator rights on production machine, so installing Visual Studio remote tools is not possible. Prod machine does not have Visual Studio installed. What is the best way to debug the application running on remote machine in this case?
To get some idea of what is breaking, I looked at EventViewer on prod machine and I see Exception and got to know which function is causing issue. However, as I am new to C#, I need to be able to set breakpoints and step through the code to understand better and fix the issue.
Without remote debugging configured you will not be able tp step trough your code.
Please look at another options like log4Net - when enabled in your application can be very useful to pinpoint a production issue
(very easy to use and configure) installs from VS package manager
I have a Windows 8 Application that has a dozen of WCF Services that runs in the Cloud (Deployment) and on my Dev machine (Development). I switch a lot between development and deployment and I always have to change the service endpoints everytime I switch. Is there any automated way of doing this? Create a debug and the release version of the project?
Windows Server 2008 / IIS 7...
I am trying to setup and CI environment using TeamCity 4. So far so good, VisualSVN Server / Subversion repository is all set, TeamCity is monitoring it, and firing off the build. I can use the TeamCity Webapp via http:localhost:8080 with no problem. My issue is that I can't access the TeamCity webapp remotely from my development machine. I feel like this is problem with the Apache / Tomcat configs, but don't even know where to begin. Anyone have any thoughts?
I installed TeamCity 3.2.x on a Windows 2008 server and didn't run into any problems hitting it remotely, but you may want to check the firewall to see if it's open on port 8080. Windows Firewall > Inbound Rules > sort by port, and see if you have a rule defined for local port of 8080. If not, add it.
IIS Manager might be worth looking into too... (Start > type IIS Manager) And look at the site settings for TeamCity
It's also possible that if IIS is running properly, you'll be able to hit the machine locally on port 80, just to confirm general connectivity.