New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DefaultEnvironmentName should be development #712

Closed
luisrudge opened this Issue Jul 1, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@luisrudge

luisrudge commented Jul 1, 2015

@davidfowl asked me to complain here, so here I am :)

I get the "safe by default" mindset, but you have to consider that you can have 1000's of dev machines and jsut one production machine. It makes more sense to default to "Development " like node (and beta4, for that matter) and override or change that in production. If that's not possible, it should be possible to override that with a config file or something.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl
Member

davidfowl commented Jul 1, 2015

/cc @blowdart

@blowdart

This comment has been minimized.

Show comment
Hide comment
@blowdart

blowdart Jul 1, 2015

Member

Gee, thanks @davidfowl!

David agreed to this and accepted the need 6 months ago, we only now got around to implementing it. As we make security decisions based on environment we won't change this, as we are always going to be safe by default. It's harder to set a "release" environment, especially when we're using environment variables which can be harder to set in hosting environments due to limited admin rights.

I've yet to see a good argument to change this other than "It would make my life easier" - you can override it to development for your dev machines (and a VS install should do this)

Member

blowdart commented Jul 1, 2015

Gee, thanks @davidfowl!

David agreed to this and accepted the need 6 months ago, we only now got around to implementing it. As we make security decisions based on environment we won't change this, as we are always going to be safe by default. It's harder to set a "release" environment, especially when we're using environment variables which can be harder to set in hosting environments due to limited admin rights.

I've yet to see a good argument to change this other than "It would make my life easier" - you can override it to development for your dev machines (and a VS install should do this)

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge Jul 1, 2015

What about other options like a config file or even a txt file somewhere in the project?

luisrudge commented Jul 1, 2015

What about other options like a config file or even a txt file somewhere in the project?

@blowdart

This comment has been minimized.

Show comment
Hide comment
@blowdart

blowdart Jul 1, 2015

Member

The problem with files is people deploy them. So if we have dev.json that will make its way up onto the server and lo, we now have a server configured for dev, which is what we're trying to avoid.

Member

blowdart commented Jul 1, 2015

The problem with files is people deploy them. So if we have dev.json that will make its way up onto the server and lo, we now have a server configured for dev, which is what we're trying to avoid.

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge Jul 1, 2015

it's all about defaults, right? just like the file > new project > mvc 5 project has web.debug.config and web.release.config. You can't avoid someone from building everything in debug mode, getting the bin folder and publishing to production. But you can always use release config when using the publish button.

luisrudge commented Jul 1, 2015

it's all about defaults, right? just like the file > new project > mvc 5 project has web.debug.config and web.release.config. You can't avoid someone from building everything in debug mode, getting the bin folder and publishing to production. But you can always use release config when using the publish button.

@blowdart

This comment has been minimized.

Show comment
Hide comment
@blowdart

blowdart Jul 1, 2015

Member

Yes, but your example of web.config is precisely why files don't work. People didn't build in release and publish because it wasn't the default. The amount of debug web sites, with detailed error messages out there is awful.

Member

blowdart commented Jul 1, 2015

Yes, but your example of web.config is precisely why files don't work. People didn't build in release and publish because it wasn't the default. The amount of debug web sites, with detailed error messages out there is awful.

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge Jul 1, 2015

Fair enough. Thanks for the explanation!

luisrudge commented Jul 1, 2015

Fair enough. Thanks for the explanation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment