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

I decided to get adventurous and move my 3 project and template directories from C to D.

D . Libraries . Documents . Visual Studio . Projects. Templates....etc.


However, when I compile, it still puts the obj and exe files in the original location on the C drive. How can I make VS C++ put everything related to my project "System Image" into the same directory structure on my D drive as shown above??


My OLD "test" project shows under solution explorer still. I assume I can delete that (I saved the cpp source elsewhere).

While we're there, I see I have:

Solution "test" - 2 projects ................................................with System Image and test being the 2 projects. Can I control what the solution "test" is called? Should it be named something particular?

System Image

test

Check your project properties. It sounds like you have setup a hardcoded path instead of a relative one.

Quote:

---

Originally Posted by S_M_A

Check your project properties. It sounds like you have setup a hardcoded path instead of a relative one.

---

I looked through every options and project properties screen I could find. Nowhere is C: specified or anything even resembling a full path....

I simply installed VS C++ vanilla.

That shouldn't be neccessary. I've moved projects to other locations as well as other computers with completely other path's and never had that issue.

The C: part of the path might origin from a VS macro or an environment variable.

Since the output tab/window says:

System Image.vcxproj -> C:\Users\Jim\Documents\Visual Studio 2010\Projects\test\Release\System Image.exe

It seems maybe this setting resides inside a .vcxproj file or something?

I somehow found a way to pull up an applet of macros. In there:

$(Outputdir) - both point to the old C:\Users\Jim\documents\visual studio 2010\Projects
$(Outputpath)

I created a test project, built it, moved it, and rebuilt it without anything odd happening. The $(OutputDir) was automatically changed to reflect the new path (as it should).

In my test no absolute paths show up in neither the sln nor the vcxproj. Maybe you have hardcoded some project property at some point and that now overrides the normal behaviour?

I never did a thing other than a vanilla install UNTIL I moved the 3 primary libraries (projects and 2 templates) that are movable via the standard option panels.

I guess I have go through every single macro and see which ones point to C:.

Aha. It seems you can NOT change what the macro points to? IOW, there's no way to overtype the right-hand column that shows the definition of the macro.

Have you tried viewing the sln & vcxproj files with a text editor & searching for hard coded paths?

I haven't done that yet. Good point. I've read that there are paths inside those files.

To reiterate: I haven't hardcoded any paths anywhere other then the Project and 2 template paths that one is allowed to change.

Yeah, all of the projects settings are stuck inside those sln/vcproj files. It's easier to search through those text files than searching through all the settings in the IDE.

Also, there are settings for each individual file. You can see them by (IIRC) right clicking a .cpp file & choosing properties.

The macros that you see can be changed, but not in the macro window.

The $(OutDir) macro is changed in the project settings in the Project Properties. As shown here, changing the "Output Directory" will change $(OutDir); changing the "Intermediate Directory" changes $(IntDir), etc.

Hope this helps.

Thanks krmed, I think I get how this macro/panel interaction works now.

Can anyone answer my other question re: Solution explorer?

What makes the most sense? Having a CONSOLE and GUI "tree" in the main Solution Explorer panel? In my case, I think my main initial tree branch is called "test". Can I modify that? Is the intent to always have "all" ones projects showing in the Solution Explorer pane?

You can think of the "solution" as everything needed to build ONE complete application. For instance, if you are building an app called MyApp, and MyApp uses three DLLs and one library that you also created, your solution would contain fiveProjects:
MyApp
Dll1
Dll2
Dll3
Lib

You also then set the Project Dependencies so they are build in the correct order. For instance, if DLL3 requires something from the Lib, and DLL2 requires DLL3, and MyApp requires all of them, you would set the dependencies to indicate that. This guarantees that if you change something in the lib, the lib would be built first, then DLL3 would be re-built as needed, then DLL2, then MyApp.

As for "extra" projects that show in the solution explorer, you can simply delete them from the solution explorer - that removes them from the solution but does not delete the files on your disk.

Hope that helps.

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.

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?

Quote:

---

Originally Posted by jlewand61

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.

Quote:

---

Originally Posted by jlewand61

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.

Quote:

---

Originally Posted by S_M_A

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"?

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.

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.

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.

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).

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.

Quote:

---

Originally Posted by 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.

---

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