Home/ Questions/Q 328887
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T09:32:13+00:00

I’ve been programming in Linux/UNIX for several years now, but recently I needed to

  • 0

I’ve been programming in Linux/UNIX for several years now, but recently I needed to do some stuff in VS2008. I had difficulties with understanding how VS organizes work. Do you know any resources (free web pages preferred, but books also acceptable) which would show me a general picture and explain at least some details? Examples welcome, comparison with typical UNIX stack very welcome.

I don’t need a language (C#/C++/VB/…) reference/guide; I’ve seen some of them and none of them seem to suggest how to work with VS efficiently.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You might be interested in introductions to MSBuild, the project format of Visual Studio. Whereas in UNIX you have a autoconfig script, and Makefiles, VS2008 allows most configuration through right clicks and menu options.

    A second area of interest will likely be build configurations. Instead of re-running the configure script on different targets, or for different stacks, you specify targets with the configuration manager. Once you select a new configuration (“x86”, or “Release”, or custom ones like “Production”), VS churns for a while, as it updates the Intellisense of your new preprocessor definitions, for example, and Resource files. Your “Debug” configuration will likely define the macro “DEBUG”, so you can use regions surrounded with #ifdef DEBUG, for example.

    Visual Studio organizes common groups of source files into “Projects”, which can be referenced by one or more “Solutions”. Projects establish interdependency on one another, and external libraries. If you look at the structure of the projects in the Microsoft Enterprise Library, you will notice that there are several different Solution files (*.sln) which encompass different groups of common project files. You might have a different solution file, for example, if you want to reduce load/compile time, by not loading the unit test projects with every build.

    So, analogies:

    UNIX way:
    # ./configure
    # make
    # nano Makefile
    # make

    VS2008 way:
    # (Set up “Project Properties”, Conditional Compilation Symbols, Build Paths, all from GUI application)
    # (Click Build)
    # (Change Configuration)
    # (Click Build)

    • 0