I created a simple webapi project with dotnet core.
I'm trying to set the running environment using the ASPNETCORE_ENVIRONMENT system variable.
C:\devel\apps\webapi>set ASPNETCORE_ENVIRONMENT=Production
C:\devel\apps\webapi>echo %ASPNETCORE_ENVIRONMENT%
Production
C:\devel\apps\webapi>dotnet run
Using launch settings from C:\devel\apps\webapi\Properties\launchSettings.json...
info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
User profile is available. Using 'C:\Users\SSCARANO\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest.
Hosting environment: Development
Content root path: C:\devel\apps\webapi
Now listening on: https://localhost:5001
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
I tried opening a different console, and also setting it logged in as administrator, but the app is always running on Development mode.
I saw this (https://stackoverflow.com/a/40102470/47633) related question, but I'm not using IIS
I suspect that the issue you're encountering is that the ASPNETCORE_ENVIRONMENT variable is defined in the C:\devel\apps\webapi\Properties\launchSettings.json file.
The way dotnet run works is it loads this file and finds the first profile which commandName is project, and uses it to run the application. There's a high chance, if you haven't made any changes to that file, that the environmentVariables section of that profile contains the ASPNETCORE_ENVIRONMENT variable set to Development.
You have 2 options if you want to run the app in Production mode:
change the existing profile and set the variable to Production, meaning every time you execute dotnet run, it's going to run the app in production mode; or
add a new profile where the ASPNETCORE_ENVIRONMENT variable is set to Production. You can then use it if you execute dotnet run --launch-profile <name-of-your-new-profile>
The problem is how you have set the environment variable. On the command line you don't need the quotes, so you should instead have this:
C:\> set ASPNETCORE_ENVIRONMENT=Production
C:\> echo %ASPNETCORE_ENVIRONMENT%
Production
Related
Unable to publish the artifact for .NET Core, I can able to build but can't publish on Azure Devops.
Frontend: Angular
Backend: .NET Core 6
SQl : MSSQL server
Front code : Angular,
Back end : dotnet 6,
Sql : MSsql Server
Given that your project could be restored correctly, I suppose that you could add a --no-restore to your dotnet publish argument and test again.
Updated on 1/2
======================================================
I suppose there are multiple possible caused for your current issue of https 500.30. You could visit this doc to troubleshoot.
Additionally,
1.Check your hosting model. Confirm that whether it's IN Of Process or Out of Process. You can check the configuration in you csproj file. if you using In of Process, try to change it to
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
2.If you are deploying win-x64 app and try to have it published using an Application Pool that supports 32-bit apps, you will need to make them match-up.
3.Check in portal.azure.com for your web-app whether it is running correctly.
4.Go to portal.azure.com check you app console, and try to manually start your project with dotnet ServerApp.dll.
==========================================================
Updated on 1/9
Hi devendar
Check this doc Bad Gateway errors in Application Gateway for further troubleshoot.
I've a .Net Core 3.1 web application published on IIS.
I want to force enviroment type to development in order to run api that are not allowed in production.
I run the command :
setx ASPNETCORE_ENVIRONMENT "Development"
and then I run:
iisreset
as specified in this article How to set ASPNETCORE_ENVIRONMENT to be considered for publishing an ASP.NET Core application but the enviroment type seems to always remain production.
I try to run the API via a ngrok tunnel.
Any suggestion?
Thanks.
Simone
You need to pass /M flag to setx command:
setx ASPNETCORE_ENVIRONMENT Development /M
The /M switch sets the environment variable at the system level. If the /M switch isn't used, the environment variable is set for the user account.
You can read more about it here
I have a number of tests in my project which are run as part of the build. Some of those tests are integration tests which need a username/password set of credentials in order to run the tests.
I want to keep these credentials out of the source code so on my local machine I have set them up as user secrets and on the server they are environment variables. The deployments are working just fine with this arrangement.
My problem is running the tests as part of the build. The tests are not being fed with any login credentials and therefore are failing with authentication issues. How do I supply these values without adding them to the appsettings.json files?
I am running a dotnet core project and have a standard Azure DevOps build template.
Thanks!
Non-secret variables declared in the build are automatically turned into environment variables on the build agent.
Secret variables are intentionally not turned into environment variables, but you can add a Command Line or Script task that's appropriate for your platform (Bash, Powershell, whatever) and set an environment variable by passing your secret in as a parameter to the script.
I have a problem with hosting an ASP.NET RC1 application inside IIS.
I've read through similar issues here on the site, aswell as went through official Microsoft documentation, but to no avail. I simply cannot make the app start inside IIS8 which is a must in this scenario, as I need to use it with an SSL certificate, and no relevant logs are shown unfortunately.
App is packaged under dnx-clr-win-x86.1.0.0-rc1-update2
If I try to start it inside my local VS2015, it works flawlessly. If i run the Web.cmd on the server machine from command line, app starts without any problems. However, when I try to run it through IIS, event log catches the following.
Faulting application name: dnx.exe, version: 1.0.0.20309, time stamp: 0x56e05cbb
Faulting module name: ntdll.dll, version: 6.2.9200.21815, time stamp: 0x56eaff87
Exception code: 0xc0000374
Fault offset: 0x000db583
Faulting process id: 0xae4
Faulting application start time: 0x01d1aba4b38c38e7
Faulting application path: C:\inetpub\wwwroot\approot\runtimes\dnx-clr-win-x86.1.0.0-rc1-update2\bin\dnx.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: f1f534cd-1797-11e6-9404-000d3ab185aa
Faulting package full name:
Faulting package-relative application ID:
It seems to me like it is using a wrong dnx version, but this shouldn't be possible as i published the app with:
dnu publish --runtime active --no-source
First of all thanks Clint for pushing me in the right direction.
Unfortunately I ended up spinning up a new Windows Server 2012 instance, and installing everything from the grounds up, which seems to work great at this moment. I have probably messed something when initially setting up the server, but it was a test one so no harm is done. I have a few observations for DNX to IIS publishing, which could help others with similar problems or at least mitigate at least some of the problems.
Very important steps:
If publishing from command line, publish with dnu publish --runtime active. Add --no-source when you are sure you don't need to make any quick changes to make the app work so it compiles into NuGet packages.
Try to run the app manually by running web.cmd from the publishing folder from command line. If this doesn't work, IIS is least of your problems, and you need to resolve the app startup first.
Install IIS locally on your development machine, and try to make it first work with that one, which will help you understand which issues are happening to you and how to resolve them on the real web server.
Use Event Viewer -> Windows Logs -> Application to catch .NET and HttpPlatformHandler errors during startup
Enable stdout inside wwwroot/web.config for your solution.
Battling different issues:
1. Various http 4xx and 5xx errors.
Ensure that Http Handler 1.2 is installed. If you are not sure, check the add / remove programs section in control panel, where version is clearly visible. If using a x64 system, you need to install x64 runtime
Check that you have unlocked handlers in IIS
Check that Application pool is set to No Managed code (32 bit app support was not required in my case)
2. I'm not sure I published to a good folder
Create a folder for your web app inside your wwwroot folder e.g. C:\inetpub\wwwroot\myApplicationName
Copy publishing files to that folder. Structure should be as follows:
C:\inetpub\wwwroot\myApplicationName
approot
logs
wwwroot
Create a new website in IIS and attach it to your application pool that is set to no managed code
Set the application folder to be C:\inetpub\wwwroot\myApplicationName\wwwroot
3. Event Viewer - DNX Could not write to logs folder
This is an issue with IIS permissions on the logs folder from your publishing artefacts. Right click -> Properties -> Security on the logs folder and Add permissions for the following user.
IIS_IUSRS (permissions: read and execute, list, write)
Once you do this, restart the website, and check if this issue is gone. If Event Viewer is not logging anything, check if there is a file generated in the logs folder where you should get the next troubleshooting hint.
NOTE: If you publish an app update, and you overwrite the logs folder accidentally, you will kill its permissions and this issue will return. After the initial publish, just copy approot and wwwroot, and leave the logs intact to avoid this.
4. Unable to load application or execute command 'Microsoft.AspNet.Server.Kestrel'. Available commands: web
Try to run a dnu restore before publishing manually
Ensure that you have published with --runtime active
First make sure you have httpPlatformHandler v1.2 installed. Then follow the steps and issue resolutions here. If it still is not working, I've heard some people have resolved their issues by adding a Configure1() method in Startup.cs. See the details here.
I got one of my projects working with IIS but it was a struggle. So I decided to wait until the next release. I personally don't think it's worth bothering with right now. Because it relies on dnx which is being replaced in the next release. So whatever you do to get it working, probably won't be relevant after the next release.
I recently created a droplet on Digital Ocean, and then just used Meteor Up to deploy my site to it.
As awesome as it was to not have to mess with all of the details, I'm feeling a little worried and out of the loop about what's happening with my server.
For example, I was using the console management that Digital Ocean provides, and I tried to use the meteor mongo command to investigate what was happening with my database. It just errored, with command not found: meteor.
I know my database works, since records are persistent across accesses, but it seems like Meteor Up accomplished this without retaining any of the testing and development interfaces I grew used to on my own machine.
What does it do??? And how can I get a closer look at things going on behind the scenes?
Meteor Up installs your application to the remote server, but does not install the global meteor command-line utilities.
For those, simply run curl https://install.meteor.com | /bin/sh.
MUP does a few things. Note that this MUP is currently under active development and some of this process will likely change soon. The new version will manage deployment via Docker, add support for meteor build options, and other cool stuff. Notes on the development version (mupx) can be found here: https://github.com/arunoda/meteor-up/tree/mupx.
mup setup installs (depending on your mup.json file) Node, PhantomJS, MongoDB, and stud (for SSL support). It also installs the shell script to setup your environment variables, as well as your upstart configuration file.
mup deploy runs meteor build on your local machine to package your meteor app as a bundled and zipped node app for deployment. It then copies the packaged app to the remote server, unbundles it, installs npm modules, and runs as a node app.
Note that meteor build packages your app in production mode rather than the debug mode that runs by default on localhost when you call meteor or meteor run. The next version of MUP will have a buildOptions property in mup.json that you can use to set the debug and mobileSettings options when you deploy.
Also, since your app is running directly via Node (rather than Meteor), meteor mongo won't work. Instead, you need to ssh into the remote server and call mongo appName.
From there, #SLaks is right about how it sets things up on the server (from https://github.com/arunoda/meteor-up#server-setup-details):
This is how Meteor Up will configure the server for you based on the given appName or using "meteor" as default appName. This information will help you customize the server for your needs.
your app lives at /opt/<appName>/app
mup uses upstart with a config file at /etc/init/<appName>.conf
you can start and stop the app with upstart: start <appName> and stop <appName>
logs are located at: /var/log/upstart/<appName>.log
MongoDB installed and bound to the local interface (cannot access from the outside)
the database is named <appName>