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
Related
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.
I'm building a library in debug mode and it builds fine, but the built version of this library doesn't indicate in any way that it is built in debug mode. What I mean is that if the library is called mylib and after building it in debug mode I'm getting mylib.dll I don't really know in what mode did I built it. I'd prefer that I would have my output called mylibd.dll or mylib_d_.dll, but is this possible to specify something like it in Visual Studio 2015?
In Visual Studio you can have settings that differ per build configuration. Therefore, to achieve what you want, you would change the library names only for the Debug configuration.
In Solution Explorer, right click on the library in question, and go to Properties. Make sure the Configuration combo is set to Debug. Then, in Configuration Properties select the General group and change the Target Name setting as you like.
There are also several individual settings for the output files generated:
Linker/General/Output File
Linker/Manifest File/Manifest File
Linker/Debugging/Generate Program Database File
Linker/Advanced/Import Library
You can double check the full command line in Linker/Command Line to make sure all the filenames match your expectations.
Similarly, this can be done for static libraries as well. The appropriate configuration properties group in this case is called Librarian.
I am a Visual Studio noob. My background is more Unix-related and mostly used to building things via scons or make. I don't even have much Eclipse experience.
Anyway, I am frustrated how it seems very difficult to move files between projects in VS. (I am running Visual Studio 2013). For example, suppose I have a ProjectXRel (release) and I want a ProjectXDev (development). I want them both to be runnable, and the dev version might have just a few editing changes that differ it from the rel version.
The intuitive thought is to just copy the files from ProjectXRel to create ProjectXDev, but VS seems to fight me on that (it wants to rename all the namespaces to the title of the project).
Also, some of the files, like .cs files derived from .dbml via OR designer, seem uncopyable, and rely on one replicating the process of using the utility to having valid files. I'm used to a project being defined by its files, but that's not really the case in VS. Instead it seems defined by process steps used to create and organize the files.
Also, do serious developers just use command line calls and powershell? That's seems harder, but at least you know what the %#$$# is going on.....
So, the basic question is, how does one replicate an existing project to produce a similar one for development purposes? (I know source control such as git could help with that, but that's not an option for this situation.)
Thanks!
You should be using the same project for both Development and Release.
The things that are different between Development and Release should be stored in a config file (web.config or app.config, depending on what type of project).
You should then be using Configuration Transformations to transform that .config file into Development or Release.
In Visual Studio, right click on the project and click Add New Item, select "Application Configuration File".
In this file you can put connection strings or key/value pair settings in the AppSettings element (MSDN Link).
Once you have your basic settings defined, you can then right click on the config file and click Add Transformation. This will add transformations for each of the Project Configurations you have. (by default Debug and Release).
It will look like this:
Now you can build deployment packages.
Or install Slowchetah and then when you press F5 to debug it will run the selected project configuration with the configuration transformation applied.
I'm a little unsure about what the purpose of the configuration manaeger is. To avoid confusion this is what I mean
In particular I'm interested to know what the point of the point of the Configuration column is. Why can I set a Debug Configuration, against DataAccess, to Debug when at the top, for the Active solution configuration I have set UAT? What does all this mean anyway? What is an active solution configuration and what is a configuration?
The "Solution Configuration" is a set of overall settings for compiling the projects. Basically, you can have different project settings for different configurations with the most common combination being Release and Debug with, e.g, Release having optimization turned on and Debug having no optimization and having debug symbols exported.
The reason that you can set different Configurations for different platforms is that sometimes you want to break things down more granularly. Let's say that you're testing a release build and everything works fine except the [REDACTED]Domain project. You could set that project into Debug, with the associated symbols and lack of optimization, and then set breakpoints while the rest runs optimzed code.
Clearer?
We have a VS solution with 99 projects. I'd like to extract XML documentation for them.
So far, the only procedure I've found involves several hundred mouse clicks; e.g. open each project properties page, one by one, find the "Generate documentation" check box, and click it. The default filename is fine.
Worse: I have to do that twice per project, once for "Release" and once for "Debug".
Is there a magic button that says "enable documentation for all projects in this solution"?
This is a general problem with project-level configuration. For example, I'd like to also set the output build directory for all projects to the same place: $SolutionRoot/bin rather than each going into 99 different $ProjectRoot/bin directories.
What is the recommended strategy for dealing with this? In makefile-land, I'd have a master makefile that defined a bunch variables that each sub-makefile would use. What's the equivalent for Visual Studio? (I'm using VS 2008)
Project files are XML, I wrote a program to open each project file as an XDocument, add the required Elements and save it again. Next time I opened visual studio, the properties were set.
For something like this, you'll want to use Visual Studio's property sheets.
Though it will be a PITA to assign the same property sheet to all 99 projects, making changes that apply to all projects in the future will be much easier - 1 change versus the original 99.
You may also want to consider creating a hierarchy of property sheets that apply to different types of projects (executables, libraries) or configurations (debug, release) to allow even more fine-grained control without requiring massive duplication.
EDIT: I guess property sheets are not available for languages other than C++. For other languages (like C#) you could refer to this answer.