5 ms·

I know this is going to get some jeering, but that's one nice thing about .Net's machine.config <deployment retail="true" />, you designate the machine itself a

I know this is going to get some jeering, but that's one nice thing about .Net's machine.config <deployment retail="true" />, you designate the machine itself as a non-development environment and tracing, debug output, and so on are disabled for all .Net/ASP.Net applications. That might not work for all edge cases, but broadly there's a lot of machines which are only for non-development/production code, and a system-wide setting makes you a lot safer.

bpicolo 8y ago
You can use env vars to do similarly for all the big frameworks (django, rails, etc)
gandreani 8y ago
Just a thought. This might actually be trivial to implement in a unix environment from the administration side of things. I'm not 100% sure but all child processes inherit the env vars from the parent correct? So setting `environment=production` high up in the process tree should make it available to all processes. There's still chances of this getting overridden down the line and all apps have to conform to one style but at least it's possible?
- Someone1234 8y ago
  Absolutely. But none of the major players are looking for it, and they all have unique ways of designating the machine that way. There's no specific technological challenges, this is entirely political, getting half a dozen or more different projects with different priorities to check the same variable for the same purpose.
- phinnaeus 8y ago
  Plenty of production apps in my line of work are executed with `env -i` for consistency.
kawsper 8y ago
Funnily enough, it is mostly .NET applications running in production that I see stack-traces from these days.
- Someone1234 8y ago
  If you even know something is a .Net app then the developer is likely terrible, so it is a self-selecting sample. You don't know most of the .Net MVC apps you interact with because there's no reason to know that.
  - shawn 8y ago
    This is really discriminatory and arrogant. I used to feel the same way. It’s worth changing.
    - alexbecker 8y ago
      I think they mean if you can tell that it's a .NET app (e.g. because they left the X-Powered-By header on), not if it's a .NET app in general.
      - shawn 8y ago
        Facepalm. I've filled my dumb comment quota for the week. Well, at least it was clarified. It got a couple upvotes, so I guess others misinterpreted it too. Sorry.
  - detaro 8y ago
    That's true for basically every stack
  - tomazio 8y ago
    Ever heard of Jon Skeet?
  - tedunangst 8y ago
    Boy, getting hammered for poor phrasing. What's meant is if the stack (whatever it is) bleeds into the user experience, the dev has done a poor job.
wereHamster 8y ago
I don't know what the standard way is to deploy django or .net apps, but nodejs apps are often packaged into a docker container, or cloud function, that run independently, not on any particular machine that you designate as 'production'. So 'system-wide' settings don't really exist because there is no concept of a machine. With nodejs in a docker contianer for example you specify whether the server is designated for production or not during build time, not when you run it.
- panopticon 8y ago
  I think you're a little over-confident in the Node community; I've seen a lot of Node apps deployed the same as any other (just tar'ed up and deployed via some kind of script or other deployment tool).
  - tluyben2 8y ago
    Seems a bit of the HN echo chamber; people here seem to think, because of the high quality stories and comments, that the entire world uses best practices for everything; containers, code reviews, versioning, test coverage, CI, automated deployments, etc. While in reality I think most places are not doing that. This is anecdotal ofcourse but most (large and small) companies I have worked with (as clients or partners) are in fact doing none of these things.
    - pjmlp 8y ago
      Quite true. I hardly see any of the best practices that keep being discussed here. Small to middle size companies whose main business is totally unrelated to selling software just care that their stuff works somehow. And everything that IT does is a cost center.
GordonS 8y ago
I guess that's .NET Framework only - is there something similar for .NET Core?

bpicolo 8y ago

You can use env vars to do similarly for all the big frameworks (django, rails, etc)

gandreani 8y ago

Just a thought. This might actually be trivial to implement in a unix environment from the administration side of things. I'm not 100% sure but all child processes inherit the env vars from the parent correct? So setting `environment=production` high up in the process tree should make it available to all processes. There's still chances of this getting overridden down the line and all apps have to conform to one style but at least it's possible?

Someone1234 8y ago
Absolutely. But none of the major players are looking for it, and they all have unique ways of designating the machine that way. There's no specific technological challenges, this is entirely political, getting half a dozen or more different projects with different priorities to check the same variable for the same purpose.
phinnaeus 8y ago
Plenty of production apps in my line of work are executed with `env -i` for consistency.

kawsper 8y ago

Funnily enough, it is mostly .NET applications running in production that I see stack-traces from these days.

Someone1234 8y ago
If you even know something is a .Net app then the developer is likely terrible, so it is a self-selecting sample. You don't know most of the .Net MVC apps you interact with because there's no reason to know that.
- shawn 8y ago
  This is really discriminatory and arrogant. I used to feel the same way. It’s worth changing.
  - alexbecker 8y ago
    I think they mean if you can tell that it's a .NET app (e.g. because they left the X-Powered-By header on), not if it's a .NET app in general.
    - shawn 8y ago
      Facepalm. I've filled my dumb comment quota for the week. Well, at least it was clarified. It got a couple upvotes, so I guess others misinterpreted it too. Sorry.
- detaro 8y ago
  That's true for basically every stack
- tomazio 8y ago
  Ever heard of Jon Skeet?
- tedunangst 8y ago
  Boy, getting hammered for poor phrasing. What's meant is if the stack (whatever it is) bleeds into the user experience, the dev has done a poor job.

wereHamster 8y ago

I don't know what the standard way is to deploy django or .net apps, but nodejs apps are often packaged into a docker container, or cloud function, that run independently, not on any particular machine that you designate as 'production'. So 'system-wide' settings don't really exist because there is no concept of a machine. With nodejs in a docker contianer for example you specify whether the server is designated for production or not during build time, not when you run it.

panopticon 8y ago
I think you're a little over-confident in the Node community; I've seen a lot of Node apps deployed the same as any other (just tar'ed up and deployed via some kind of script or other deployment tool).
- tluyben2 8y ago
  Seems a bit of the HN echo chamber; people here seem to think, because of the high quality stories and comments, that the entire world uses best practices for everything; containers, code reviews, versioning, test coverage, CI, automated deployments, etc. While in reality I think most places are not doing that. This is anecdotal ofcourse but most (large and small) companies I have worked with (as clients or partners) are in fact doing none of these things.
  - pjmlp 8y ago
    Quite true. I hardly see any of the best practices that keep being discussed here. Small to middle size companies whose main business is totally unrelated to selling software just care that their stuff works somehow. And everything that IT does is a cost center.

GordonS 8y ago

I guess that's .NET Framework only - is there something similar for .NET Core?