consolidating all libraries (user and VS C++ infrastructure ones)

[S_M_A]

OK. I looked through the sln and vcxproj files (3 of them?) and no C: hardcoded anywhere. I can only come to the conclusion that VS C++ isn't designed to coherently move files around.

That's not a correct conclusion though. It's perfectly alright to move the code around or rename the folder or whatever. You have done something bad to the setup but that doesn't mean that MSVC is flawed.

Have you tried creating a brand new project letting everything be as it is as default and move that around?

Regarding what should be in a solution and not is up to you. In many of my projects I have a solution that when it's built outputs several binaries. For instance the load file for an embedded system (using another compiler/linker), the PC executable that is used for unit testing and possibly a PC executable used to communicate with the embedded system when running it on the bench.

[krmed]

krmed, so you're saying that I should have ONE solution per "solution" (project)?

Since I currently have "test" as my top-level "solution" of which BOTH system image and test are underneath that, what should I do to move stuff around and create a coherent view of my projects?

Exactly what you put in a solution is up to you...there are several (almost infinite) approaches to this. For starters, let's get the terms correct. You asked if you should have one solution per soltuion.... In Visual Studio you open A soltuion (only one) and it contains the "Projects". That's why you see .sln files (solutions) and .vcxproj files (solutions).

In my job, we have 39 separate applications (.exe files) that we distribute, and these apps depend on some of the 19+ DLLs that we also create and distribute. Therefore we have chosen to have ONE solution for each application, but each solution also contains all of the supporting DLLs and LIBs needed to build it, so it's all easily accesible from within the solution. In this scenario, each application solution contains the .exe project (a vcxproj) and also the projects for all DLLs and LIBs that it uses (also vcxproj files). We simply add these projects to the solution by right-clicking on the solution (in solution explorer) and choose "Add Existing Item", then browse to the .vcxproj file we want to add. Next we set up the dependencies so the build in the correct order.

When it comes to distribution, we use InstallShield and package all 39 apps, the 19+ DLLs, and other misc stuff into a single installation package.

Another method is to put everything into a solution that will be delivered in a single installation package. In our case, that would mean all 39 executables (with the 39 .vcxproj files) plus all the supporting DLLs and LIBs (with their 19+ .vcxproj files) and then set up the dependencies as needed. This can be useful if you use Visual Studio to create the installation package (instead of using something like InstallShield).

Hopefully this will give you some food for thought.

Good luck.

[jlewand61]

That's not a correct conclusion though. It's perfectly alright to move the code around or rename the folder or whatever. You have done something bad to the setup but that doesn't mean that MSVC is flawed.

Have you tried creating a brand new project letting everything be as it is as default and move that around?

Regarding what should be in a solution and not is up to you. In many of my projects I have a solution that when it's built outputs several binaries. For instance the load file for an embedded system (using another compiler/linker), the PC executable that is used for unit testing and possibly a PC executable used to communicate with the embedded system when running it on the bench.

To reiterate: I did NOTHING other than a vanilla install of VS C++.

So, after original installation and using the "test" project, and completing the code, letting everything default to C:\Users\Jim\Documents\Visual Studio\test, I decided to create:

D:\Libraries\Documents\Visual Studio\System Image

I changed the Projects and 2 Template locations from the C: to D: path. per the OPTIONS panel. I then cut/pasted the old test.cpp to "system image.cpp". Things are getting placed in the D: path correctly except for executables (and who knows what else).

I still need FULL advice on how to set up Solution Explorer:

Currently:

Solution 'test' (2 projects)
- system image
- test


Let's say I'll have System Image (console project) and Strobe (GUI app). How do I rename the top-level "solution" folder Test to something else? I'd like to delete test as it has been migrated to "system image".

I need examples and the pros and cons of each choice. I have zero idea what this should be and don't with to have to redo everything some time down the road......



It seems you can only RENAME the "primary Solution name" in the solution explorer pane. How did mine ever become named "test" in the first place?

I can ADD projects, but how can I add MULTIPLE "solution names"?

[krmed]

When you create a new project, you should right-click on that project and choose the Properties. In their, you can set all of the needed properties (as I depicted in an earlier post. By doing this, you can have several projects in the same solution, and the output executables can go to different locations. When you set up these paths in the properties, the use of relative instead of absolute paths will allow you go move the projects at will. The apps I work with are normally stored on the D: drive, but my laptop doesn't have a D: drive, so I simply place it on the C: drive (with no other changes) and it works properly.

If your solution contains several projects, just look at the properties of each to see where the binaries go.

Hope this helps.

[jlewand61]

Just as I expected. Totally unintuitive.

This is WHY I'm asking specific questions.

I decided to delete my old test "project" from my solution "test". Good.

I then RENAMED the solution "test" to System Image in which System Image is a project withIN it.

I then wanted to create a NEW solution called Strobe. This worked and I now have a Win32 GUI skeleton project built under strobe called strobe. Worked fine.

However, I can NOT figure out how to REOPEN System Image. You are brought to an untuitive screen that has the folder path with:

Add to solution
Close solution

I don't want to do EITHER. I simply want to open my old System Image "solution"/project. Is the close option to close the currently open "Strobe" that shows in the Solution Explorer pane?

If I click on OPEN on any folders on this applet, nothing happens and it simply drills deeper and keeps showing different folder depths.

How do I "close" the current Strobe solution and REOPEN an older "System Image" solution? This ought to be a common thing to do: revisit old code to make changes.

OK. I figured out how to CLOSE the currently open solution. FILE -> CLOSE SOLUTION.

I see now that to open a solution, you have to open the .sln file. Well, guess what. For System Image that .sln file is probably buried on the C drive somewhere. I think I have to find it to reopen System Image.

Since my .sln file for System Image did NOT get moved to the D: drive when I moved the project and template folders, that implies VS C++ is not designed to consolidate anything on its own. It seems the solution to this problem is to point the project/templates to where you want and from SCRATCH, create a new solution/project.

[S_M_A]

I can't agree that the MSVC gui is unintuitive. As krmed already has explained every single project has it's own vcxproj file that contains all that is needed to build that project (static library, a dll or whatever). The sln file is just a collection of projects but it also offers you the possibility to set up dependencies so things you need are built automatically. You don't have to use that functionality. If you don't like the collection thought you can have a single vcxproj per solution and manually build what your project depends on.

The file system doesn't automatically add stuff that it thinks you might want there whenever you create a folder, neither does MSVC.

[jlewand61]

If the MVSC gui was intuitive, I wouldn't be asking these questions.

One more time and then on to another board if no one will answer:

what are OPTIONS for solution folders/projects?

For example, I think it is best to have 2 "garbage" projects:

one console
one GUI

Each is used to test code snippets.

Going back to the fact that MSVC will NOT rearrange macros and other paths to match changing the project and template paths for an already-existing project/solution.

I think my best bet is to delete everything I have. The Project and Templates will remain pointed to D:\Libraries\Documents\Visual Studio\Projects. On one project, I added the project name to the final directory node per a webpage that showed how to match the VS logical folders to the underlying physical disk folder structure. But, on the last one, I did NOT do this, yet it seems to have created a folder for the project anyway.

I assume then that I will/should have one solution per project (program).

[S_M_A]

I think you mix things up a bit. What you set in options are global settings just as the ordinary environment variables. What you set in project properties is specific for that particular project.

Try to calm down and rethink this a bit and you will most likely come to the conclusion that MSVC offers you a quite wide range of possibilities on how to arrange/setup your coding environment. It might be that it's not 100% perfect in all situations but that's the price you pay for not having to struggle with maintaining a bunch of makefiles yourself.

[jlewand61]

I think you mix things up a bit. What you set in options are global settings just as the ordinary environment variables. What you set in project properties is specific for that particular project.

Try to calm down and rethink this a bit and you will most likely come to the conclusion that MSVC offers you a quite wide range of possibilities on how to arrange/setup your coding environment. It might be that it's not 100% perfect in all situations but that's the price you pay for not having to struggle with maintaining a bunch of makefiles yourself.

I'm aware of global vs. project-specific settings.

It would help if a pop-up box would occur when you attempt to change the global settings:

These global VS setting changes will only affect FUTURE project/solution creations. Already-existing ones will remain where they are (especially since the .sln doesn't get moved).

I have no delusions that MSVC doesn't offer every possible option that can help customize any build. However, my note above stands