search

rnwood / smtp4dev

smtp4dev - the fake smtp email server for development and testing
BSD 3-Clause "New" or "Revised" License
3.07k stars 344 forks source link

CSS styling not being loaded if ASPNETCORE_ENVIRONMENT env var=Development for released builds #147

Closed sicknote closed 5 years ago

sicknote commented 5 years ago

Updated to version 3.1.0-ci0628 windows x64.

404 for http://localhost:5000/dist/vendor.css which results in garbled UI. Can still see the emails and open attachments.

sicknote commented 5 years ago

I completely removed the old version so as not to have file conflicts, so this was a new "install"

rnwood commented 5 years ago

Thanks for reporting this. This is actually occuring (at least the way I can find reproduce it) if the ASPNETCORE_ENVIRONMENT environment variable is set to Development. This causes the site layout to not load /dist/site.css (because it's loaded via HMR to enable quick iteration). So a workaround until fixed is to set that env var to Production in the parent process before launching smtp4dev as per below examples - this won't affect other processes as long as you don't launch them from the same shell:

PowerShell:

$env:ASPNETCORE_ENVIRONMENT="Production";
& pathto/Rnwood.Smtp4dev.exe

Cmd:

set ASPNETCORE_ENVIRONMENT=Production
pathto\Rnwood.Smtp4dev.exe

Bash (etc)

export ASPNETCORE_ENVIRONMENT=Production
pathto/Rnwood.Smtp4dev

We need to make the release builds ignore this env variable as it's a common scenario that we will be running on a machine where this is set to Development. I'm kind of suprised there's nothing built into the framework/runtime to deal with this during publish or allowing it to be overridden in appsettings.json. There is something for when IIS hosting is used but not any equivalent for when self-hosting AFAICS, so will need to invent something. See #99 for a previous related bug.

/dist/vendor.css being referenced but a 404 is not the cause of this issue, but will also fix this for completeness.

rnwood commented 5 years ago

I've added a commit which should resolve this.

ASPNETCORE_ENVIRONMENT will now be ignored except during development (i.e. when running after building from source before publish).

This is achieved by adding code to set IHostingEnvironment.EnviromentName from configuration setting 'Configuration' and setting the default value to Production in appsettings.json. For development only VS/VSCode set ASPNET_ENVIRONMENT to Development which loads appsettings.Development.environment on top of this overriding the effective value to 'Development'. This file is not present in the published output which means that this does not happen outside of the actual development process.

I've also reversed the workaround I did for #99, since env is now set correctly the out of the box logic will now work.

rnwood commented 5 years ago

OK in build 3.1.0-ci0633 onwards.