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.
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 working on a large, inherited C++ (really, mostly C) project developed and maintained under Visual Studio 2008. Technically, in Visual Studio terms, it is a "solution" consisting of eight "projects", and therein appears to be the rub.
As I'm sure most of you know, Visual Studio grays out the code that it believes to be #ifdef'd out. What I'm finding, though, is that it doesn't seem to do this correctly for the different projects. To keep matters simple, let's just call them Proj1, Proj2, ... Proj8. When I'm working on the Win32 Debug configuration of Proj5, I'd expect that the macros defined in the C/C++ Preprocessor properties configuration of Proj5 would determine what is grayed (or at least that there would be some straightforward way to make it so). Instead, I seem to be seeing views based on properties of Proj1. That is, if Proj1 defines some preprocessor macros that eliminate part of the code, I'm seeing that part grayed even when I'm working on Proj5. And the macros for Proj5 have no effect at all on what I see.
Yes, I did a complete clean and build (several, actually, and even saved everything off to SVN and started in a new top-level folder), and so I'm pretty sure this is not because of some vestigial files produced by an old build. And I'm pretty sure that in other respects Visual Sourcesafe "understands" the context correctly, because (1) the Build menu contains options related to Proj5, not Proj1; (b) at the bottom of the Project menu is "Proj5 properties..." not "Proj1 properties..."; and (c) there is no question that the #ifdef's are working in the program that is built: there are major feature differences, and they are as I'd expect them to be.
ADDED 27 Sept 2010 I still don't have an answer, so let me try this a different way: Assuming I've already run successful builds (which I have) is there anything other than the preprocessor properties and configuration of the currently selected project (and, as noted below, those of individual files, but that is moot in this case) that should influence what code is grayed?
Please see if these preprocessor directives might be set for the individual files. You can do this by right-clicking on a source file and selecting "Properties" from the context menu. It's somewhat counterintuitive to think that the directives can be set for individual files, not just for projects.
If that doesn't help, your best bet might be to use a text editor to look for the problem preprocessor definitions in each of the project files to try to get a better idea of what might be happening.
VS2010 is supposed to help with this. In VS2008, the no-compile browse cache is done after preprocessing, so it can accommodate only one set of macro definitions.
I don't believe that "Build Clean" or "Rebuild" will delete the .ncb files, since they are not part of the build process at all. I do know that deleting these files by hand fixes all kinds of weird behavior, but I'm afraid that in your case it's not going to be a lasting solution (the .ncb files will still get filled in based on a single configuration.)
Make the project the Startup Project and Remove and Re-add the offending Preprocessor Definition
Details:
I found a process that that fixes my MFC projects when this happens (at least temporarily). First I set the project I am working on as the startup project. Do that by right-clicking the project in the solution explorer and selecting Set as Startup Project. Then I go into the preprocessor definitions for the project and deleting the one that is not triggering and clicking OK. You will see a little progress bar a few seconds later appear in the lower right. Once it finishes, go back into preprocessor definitions for the project and add it back in again and click OK. After the little progress bar finishes again, you should see the correct code active again.
Being new to VS, how may I think of these two concepts, what is the difference?
I find some missing information in the other answers (at least for people who come from other IDEs like, say, Eclipse) . To say that a solution is a container for projects is only part of the thing. The conceptual feature of a VS project (what determines its 'granularity') is that one project produces one output: typically an executable or a library (dll). So, if you are going to code three executables that uses related code, you'll create one solution and at least three projects - probably more.
A solution is a container for projects, and tracks dependencies between projects.
Just to come up with a metaphor..
A solution is like a house, a project like a room. Each room provides a piece of functionality whereas the house, a container of rooms, provides the means to link the rooms together and organize them appropriately.
Kind of corny but I made it up on the fly, so bear with me :)
It doesn't help that Visual Studio seems to make things more confusing. "New Project" actually creates a new SOLUTION containing a project. "Open Project" actually opens a solution containing one (or many) project. (The file menu says "Open Project/Solution" but it really is opening solutions. There is no "Close Project" only "Close Solution" which is accurate.
So, in VS you are always working within a solution. Many solutions contain only one project and newer developers are likely to think of them as the same thing. However you can add other projects into a solution.
In case anyone decides to scroll down this far... I thought the MS docs did a pretty good job at describing the differences. I've copy pasted (and rephrased) the relevant bits here:
When you create an app, application, website, Web App, script, plug-in, etc in Visual Studio, you start with a project. In a logical sense, a project contains of all the source code files, icons, images, data files and anything else that will be compiled into an executable program or web site, or else is needed in order to perform the compilation. A project also contains all the compiler settings and other configuration files that might be needed by various services or components that your program will communicate with.
You don't have to use solutions or projects if you don't want to. You can simply open the files in Visual Studio and start editing your code.
In a literal sense, a project is an XML file (.vbproj, .csproj, .vcxproj) that defines a virtual folder hierarchy along with paths to all the items it "contains" and all the build settings.
In Visual Studio, the project file is used by Solution Explorer to display the project contents and settings. When you compile your project, the MSBuild engine consumes the project file to create the executable. You can also customize projects to product other kinds of output.
A project is contained, in a logical sense and in the file system, within a solution, which may contain one or more projects, along with build information, Visual Studio window settings, and any miscellaneous files that aren't associated with any project. In a literal sense, the solution is a text file with its own unique format; it is generally not intended to be edited by hand.
A solution has an associated .suo file that stores settings, preferences and configuration information for each user that has worked on the project.
A Solution can have many Projects.
The Solution can also handle managing the dependencies between its different Projects...making sure that each Project gets Built in the appropriate order for the final Solution to work.
A project contains executable and library files that make up an application or component of an application.
A solution is a placeholder for logically related projects that make up an application. For example, you could have separate projects for your application's GUI, database access layer, and so on. The projects would be specific divisions for your program's functionality, and the solution would be the umbrella unifying all of them under one application.
A solution is a readable text file whose extension is .sln and having a structured content that describes the projects that it contains. A project is a readable XML formatted text file whose extension is .vcxproj and having a structured content according to its XML schema, and whose primary purpose is to contain the listing of source codes filenames and their dependencies or references to other project's source codes as well.
Solutions are containers for projects - you can also use them to organize items that are used across different related project (shared dll's and such).
Solutions are containers used by Visual Studio to organize one or more related projects. When you open a solution in Visual Studio, it will automatically load all the projects it contains.
When you create a new project in Visual Studio, it automatically creates a solution to house the project if there's not a solution already open.
You can set dependencies of projects on other projects in the solution. The dependent project is build after the project it is depending on is built.
For more details refer - https://learn.microsoft.com/en-us/visualstudio/ide/quickstart-projects-solutions
If you are from an Eclipse background you would probably go to build path of a project and add a dependency on other project or add an external jar. In VS you can do that in a single container called solution where all related projects are grouped together.
Eg. Let's say you are build and android and iOS app in xamrin, there would be some common code and resources that could go in a separate project and then your android and iOS projects can depend on this common code project. Also you could have projects to test these projects etc.
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.
Basically, what I want to achieve, is to be able to have 2 separate solutions containing the same set of projects, but 1st solution needs to be bound to source control, 2nd - not.
So whenever you want source control integration in Visual Studio, you can open 1st solution, but if you don’t want it, you can open the 2nd one.
The problem is, that VS stores some binding info in the project files, and while it is there, no matter what solution the project is part of, it will have source control integration when opened in VS.
Is it possible to have all the binding info in the .sln file only?
Or maybe there is another solution form my problem?
Edit: the reason I want to do that is because some of the team members prefer to have source control integration in Visual Studio, the others don't. Having 2 solutions would give them a choice.
No.
It couldn't be the same set of projects - the files in a project are either source controlled or not, but you could have a non-source-controlled copy of a version retrieved from source control.
You could probably automate the process of removing source control bindings. So you would get a solution from source control, make a copy, and remove the source control bindings from the copy.
I've needed this in the past in the following situation: a source-controlled solution with a shared class library and a sample application that uses the shared library. I wanted to be able to ship a ZIP file containing the sample application without source control bindings.
This is technically possible. Open the File -> Source Control -> Change Source Control dialog and you can adjust the bindings for each individual project, including the root solution. However, it probably won't do what you want. If you remove the bindings from the projects but keep the solution binding, you'll end up in a state where changes to the solution itself (e.g. stuff you do in Configuration Manager) are automatically checked in & out, but changes to files that are "owned" by the individual project systems won't be.
The best answer IMO is to have the developers who don't like SCC integration adjust the settings in Tools -> Options -> Source Control -> Environment to their liking. Here you can turn off most (all?) of the SCC features that act "behind your back." And they are all strictly per-user, stored in the HKCU registry rather than your makefiles.