solution config & build/debug

[CWITT]

with VS 2017, regardless if you are debugging or building, the file location is dependent on the current solution configuration. My issue is this, How do I change it back so the "current" solution doesn't matter??

I'm positive in previous versions that the SC was always set to debug, and that when ever I told it to build VS used the build config without me having to select it (I've never had to change it before??).

This making sense to anyone?

[Sitten Spynne]

In some previous versions of Visual Studio, particularly Express editions, Microsoft decided build configurations were "too complicated" and hid them away in dark corners if they were configurable at all.

But "Express Editions" were considered for "beginners" or "students", and now it's sort of morphed into a "Community Edition" that is "Well, we'll let SOME professional developers use this for free if...", so they can't be so "motherly" and hide things from everyone.

You can ignore it, it won't ever change on its own. You can hide it from the toolbar, but then it gets harder to change it when you DO want to make a release configuration, so there's not much reason to hide it.

So TL;DR:

It's always been part of how your project is built, but sometimes MS hides the UI that makes it obvious it's there. You can hide it if you want, but it won't change anything about your project.

[CWITT]

I don't want the settings to go away. I want it to react/behave the way I have come to expect it to.

If you debug, it saves the files to the debug folder.
If you Build, it saves to the Release folder.

I just don't want to have to switch profiles/configurations every time I want to do one of them?

[PlausiblyDamp]

I don't want the settings to go away. I want it to react/behave the way I have come to expect it to.

If you debug, it saves the files to the debug folder.
If you Build, it saves to the Release folder.

I just don't want to have to switch profiles/configurations every time I want to do one of them?

I honestly don't remember VS working this way, when you debug your app it just builds the configuration you have selected and launches it under the debugger. When you build your app it just builds the configuration you have selected and doesn't launch it.

[CWITT]

You don't see it as odd that if you have debug config selected and click build, the release files are saved to the debug directory??

[PlausiblyDamp]

You don't see it as odd that if you have debug config selected and click build, the release files are saved to the debug directory??

If you have the Debug configuration selected and click build then you are building the debug configuration, therefore the debug files are saved to the debug directory. Build is not the same as "build the release configuration", build just means build the selected configuration.

[CWITT]

Perhaps I'm just looking at it wrong.. but "build" is not "debug" why would anyone want to build a debug version??

regardless of that.. it seems the change in behavior is permanent. i never had to switch with prior version, it worked as i described above.

oh well.

[Shaggy Hiker]

I, too, think that the behavior changed in this area, but I can't say that I have paid enough attention to it to notice what changed. I just feel like I'm interacting with 2017 differently than I do with 2010, in this regard.

[Sitten Spynne]

I have a feeling in an attempt to be "helpful" to "poor newbies" some manager somewhere designed the Express Editions like this:

"We should make it so that when you try to start a debug instance, the Debug configuration is built. But if you just choose "Build all", the Release configuration should be built. This should be done transparently without indicating to users there is a "Release" or "Debug" configuration, because I drink a can of lead paint every morning and I don't like knowing what my tools are doing."

I swear I used EE for a while and ran into something like this and it confused the heck out of me.

[PlausiblyDamp]

Perhaps I'm just looking at it wrong.. but "build" is not "debug" why would anyone want to build a debug version??

In most programming languages the idea of building different versions is pretty common, I certainly remember it from the good old days of C / C++ development...

Even these days though the ability to build a debug version you can deploy can really help if you are experiencing problems in a live environment that don't occur in a development environment as you can still log debug messages attach a debugger of some fashion without installing all the associated development tools. Not something I normally want to do admittedly as it means there is a really hard to track down bug...

[Sitten Spynne]

Sometimes you want to deploy a debug instance. Sometimes you want to start it without a debugger attached. Also: "Debug" and "Release" are not the only two configurations you can make. There are dozens if not hundreds of compiler options. The difference between "Debug" and "Release" is only a handful of them, maybe six total. For my projects, I have to worry about "Is this for a simulator, or hardware, or deployment?" and our project has a total of maybe 30 configurations.

"Debug" really just means "Build, then start the output, then attach a debugger" in one convenient step.

[jmcilhinney]

but "build" is not "debug"

No, and "build" is not "release" either, so what you're saying should be the case is no more valid than what is the case in that regard. Build basically just means compile (not exactly, but that's the main operation in a build), so that says nothing about the parameters that the compiler should use. That's what the Build Configuration is for. The fact that you expect it to work a particular does not mean that it should work that way.

why would anyone want to build a debug version??

Because they want to debug. There are a number of differences between a Debug build and a Release build. Most notably, those are that there aren't any optimisations applied and the DEBUG constant is defined. I have often deployed a Debug build because I want to use it to track down a bug is an environment other than Development. It's not rare at all. VS supports remote debugging for a reason.