I've always wondered if there is a difference if you build a PLC project in the Debug or Release configuration. I don't think there is since the .compileinfo file in the _CompileInfo folder is the same size and it has the same filename (some hash I guess). Also when I log in after building with the other configuration, I do not get the prompt if I want to log in with online changes.
Does anyone know if the build configuration has an influence on the compiled code?
Short answer:
No, there is no change to the built code.
Long Answer:
The Build Configuration Tools that are referred to are primarily designed for implementation with general text based languages, rather than the TwinCAT layer that Beckhoff has stacked on top of Visual Studio.
Under standard languages there are a lot of properties that can be managed at the project level, and these properties are what are being modified when you change from debug to release configuration.
Twincat projects however are made up of two separate projects (proj_a.tsproj, proj_a.plcproj), and Visual Studio only recognizes one of these as a project file that can be modified, the .tsproj.
So if you want to see what properties will be modified by swapping between debug and release, have a look at what properties are available from the .tsproj file.
If you want to test this yourself you can disable a project file (proj_a.tsproj) and swap between debug/release to see the disabled status change as a result of swapping between the two build configurations.
By default when creating a new solution, VS 2015 gives you two solution configurations: Debug and Release. I want to know if it is okay to remove these two configurations. I want to create three: Development, Testing and Production to match the nomenclature of my organization and do not want to have confusion with Debug and Release.
So any reason I should NOT remove these two?
You shouldn't delete the Debug and Release configurations.
Configurations are not just a name. The Debug configuration for example defines a preprocessor variable called DEBUG that you can use to add or skip blocks of code with the preprocessor statement #if.
The Release configuration instead contains settings used by the compiler to produce optimized code.
However you can rename DEBUG to Development and Release to Production while you could create Testing copying one of the twos and adding your own settings (like a preprocessor variable called TEST for example)
To rename a configuration use the menu Configuration Manager inside the Build menu.
Then in the Active Solutions Configuration combobox choose <Edit>
The following form contains the button that allows you to rename the configurations but preserve the orignal settings
To create a new configuration use the same menu but choose <New> instead of <Edit>
This article on MSDN seems pretty interesting
Understanding Build Configurations
I have a C++ project experiencing one of those annoying problems that show up in Release but not Debug build.
So I want to create a third build configuration that is identical to Release except that it generates the PDB files (anything else?) that are needed to support step debugging and value inspection within a VS debug session when it hits an exception.
What Compiler and Linker settings do I need to change to enable this?
Once you enable optimizations, you aren't able to inspect things that are optimized away.
When you see such an entity, switching to Assembly mode with source lines alongside and looking at the processor instructions can give you hints where it went (e.g. a variable could have been moved into a register, then you can inspect the register instead).
PDB generation is enabled by default in Release configuration in VS2008. If not, the linked question lists the relevant settings.
I have a MSVC++ project fooproj that basically comes as input to the project I'm working on. I want to use CMake to add some sanity to the work on configuration of the solution+projects. Furthermore, I will be making changes (and contributing them back) in fooproj so I'd really like to properly import it into the solution that CMake generates so I'm looking at using include_external_msproject(), but I'd like to somehow control which configuration of fooproj I use for Debug/Release:
solution-lvl Debug -> project-lvl LibDebug
solution-lvl Release -> project-lvl LibRelease
Currently I do this manually after regenerating the solution using the Configuration Manager in VS, but I'd like to make it automatic. Is there some way to do that?
I've been having this exact same issue while I port all our projects to use CMake.
A project I am importing has spaces in the configuration (Release md), and I am trying to map it to a solution config (Release_md), which is not possible I don't think.
As far as my researching has gone, there isn't any actual support for mapping the solution configurations to project configurations manually, since the CMake configurations are very nearly hardcoded to be 1:1 in Visual Studio. Different projects (that aren't imported as external ms projects) cannot have differing/less/more configs from the specified solution/CMake configuration.
I don't know about your case with fooproj specifically, but couldn't you add the Release and Debug configs to fooproj to match the solution configs from CMake?
Edit: Maybe this email thread can potentially help you? It mentions something about converting the external project to an imported target and mapping it that way.
By default, of course, Visual Studio creates separate bin folders for Debug and Release builds. We are having some minor issues dealing with those from the perspective of external dependencies, where sometimes we want release binaries and sometimes debug. It would make life slightly easier to just have a single bin folder on all projects and make that the target for both Debug and Release. We could then point our external scripts, etc. at a single location.
A co-worker questioned why we couldn't just do that--change the VS project settings to go to the same bin folder? I confess I couldn't really think of a good reason to keep them, other than easily being able to see on my local filesystem which are Debug and which are Release. But so what; what does that gain?
My question(s):
How do you leverage having distinct Debug and Release folders? What processes does this enable in your development?
What bad thing could happen if you fail to retain this distinction?
Inversely, if you have gone the "single folder" route, how has this helped you?
I am NOT asking why have separate Debug and Release builds. I understand the difference, and the place of each. My question concerns placing them in separate folders.
Dave, if you will compile Debug and Release to single folder, you may encounter the situation where some dll-s will not be recompiled after switching from Release to Debug and vice versa because dll files will be newer than source files. Yes, the "Rebuild" should help you, but if you forget this - you can have a few extra hours of debugging.
The way I see it, this is simply a convenience on the developer's machine allowing them to compile and run both Debug and Release builds simultaneously.
If you have scripts or tools running inside Visual Studio, the IDE allows you to use the ConfigurationName and other macros to obtain paths which are configuration-independent.
If you are running scripts and tools externally from the command-line (i.e. you are structuring some kind of release or deployment process around it), it is better to do this on a build server, where the distinction between Debug and Release goes away.
For example, when you invoke msbuild from the command-line (on the build server) you can specify the Configuration property for Debug or Release, and the OutputPath property to build to one location only (regardless of the Configuration).
One reason I use separate folders is that it guarantees that I only generate installers that use Release-build code. I use WiX, which allows me to specify the exact path to the files I want to include in the installer, so I end up specifying the path in the Release folder. (Of course, you can do the same using normal VS installers, so that isn't really the point.) If you forget to switch your project to Release before building, the installer doesn't build unless you have old code in the Release folder, in which case you end up with an old installer, so that's a bit of a pitfall. The way I get around that is to use post-build event on the WiX installer project that clears out the release folder after the WiX installer builds.
In a previous company we got round this problem by changing the names of the debug executable and dlls by appending a "D". So
MainProgram.exe & library.dll
become
MainProgramD.exe & libraryD.dll
This meant that they could co-exist in the same output folder and all scripts, paths etc. could just reference that. The intermediate files still need to go to separate folders as the names of these can't be changed.
Obviously you need to change all your references to point to the modified name for debug - which you will forget to do at some point.
I usually compile in Debug mode, but sometimes need to compile in Release mode. Unfortunately, they don't behave exactly the same in certain error situations. By having separate folders, I don't need to recompile everything just to change modes (and a full recompile of our stuff in Release mode will take a while).
I have an experience from somewhat bigger project. If there are few solutions using file references to other solutions, you have to point the reference to ONE directory, so obviously it has to be the "release" one for continuous/night build. Now you can imagine what happens if developer wants to work with debug versions - all the references point to release ones. If it pointed to the same directory, switching to debug would be only matter of recompiling all related stuff in debug mode and the file references would automatically point to debug versions since then.
On the other side, I don't see the point why developer would ever want to work with release versions (and switching back and forth) - the release mode is only useful for full/nighlty builds, so the solutions in VS can stay by default in debug mode, and build script (anyway) always does clean, release build.
Occasionally one may run into a particularly-nasty uninitialized memory problem that only occurs with a release build. If you are unable to maintain (as ChrisF suggests) separate names for your debug vs. release binaries it's really easy to loose track of which binary you're currently using.
Additionally, you may find yourself tweaking the compiler settings (i.e. optimization level, release-with-debug symbols for easy profiling, etc.) and it's much easier to keep these in order with separate folders.
It's all a matter of personal preference though - which is why Visual Studio makes it easy to change the options.
Visual Studio kinds of IDEs works what best for the crowd. They create the default project structure, binary folders. You could map the binaries to the single folder. Then you need to educate the other developers that Release/Debug files are stored in the same folder.
Developers would ask you, who you do like that?
In VC++, we have different libraries generated and you need to link the appropriate versions. Otherwise you will get linker error.
Being consistent in your assemblies is a good thing. You don't want to deal with issues around conditional compilation/etc. where your release and debug dlls are incompatible, but you're trying to run them against each other.
What everyone elsesaid about technical aspects are important. Another aspect is that you may run into race conditions if one build relies on the single-output-location build, but there's no synchronization between the two builds. If the first build can be re-run (especially in a different mode) after the second build starts, you won't really know if you're using a debug of release build.
And don't forget the human aspect: it's far easier to know what you're working with (and fix broken builds) if the two builds output to different locations.