3

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.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
liori
  • 40,917
  • 13
  • 78
  • 105
  • You mentioned that you use CMake. Why not stick to that? Cmake will gladly create VS project files for you. – sbi Aug 17 '09 at 19:24
  • Because the projects/solutions are already handcrafted by my coworkers. Also I tried to use CMake in Windows, only to get this: http://stackoverflow.com/questions/1269221/ – liori Aug 17 '09 at 20:58
  • @liori: I know at least one open source project that successfully uses CMake on Windows. I have tried it and it worked. However, since you already have solutions, this is moot. – sbi Aug 18 '09 at 08:45

4 Answers4

6

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)

maxwellb
  • 13,366
  • 2
  • 25
  • 35
  • 2
    UNIX solution, nano? No self respecting Unix guy uses anything called "nano." Plus, after ./configure, you rarely need to edit the generated Makefile. If you do, your configure script was badly set up. – xcramps Aug 17 '09 at 17:43
  • These days I'd rather use CMake, but that's a matter of preference. Thank you for links. – liori Aug 17 '09 at 17:48
  • 1
    It was an example. Personally, I use vim. And, true. You don't need to edit the Makefile usually. But the analogy to VS is somewhere in the Project Properties or Build Configuration. – maxwellb Aug 17 '09 at 17:58
  • BTW, take the vims vs. emacsen debate outside. – maxwellb Aug 17 '09 at 17:59
3

I don't have any links for you, but:

  • Visual Studio can open one and only one Solution at a time
  • A Solution may have zero (not very useful) or more Projects
  • Code (in whatever language) goes into projects
  • Projects can have any number of files and/or directories
  • Projects can reference files anywhere, not just within their own directory structure (though few do)
ConsultUtah
  • 6,639
  • 3
  • 32
  • 51
1

Visual Studio is a very flexible and powerful IDE. I think the best way to get the big picture is to build that big picture yourself in your own terms by using the heck out of it.

Build configurations and project properties are definitely two areas you will want to focus on.

You should explore the various options and configuration switches for generating assemblies and how they are managed in general. Learning the various build options and how assemblies are managed can save you headaches down the road.

The VS debugger is a thing of beauty and I recommend investing some time in exploring its capabilities. I recommend you familiarize yourself with:

  • Breakpoint management (especially the breakpoint window) and also conditional breakpoints
  • The Watch and Locals windows
  • Thread and Memory windows and tools
  • Immediate window (often overlooked and underrated if you ask me)

Finally, you should take a look at some tried and tested tools and plugins and get familiar with them. I would personally recommend ReSharper, Dependancy Walker, and .NET Reflector. ReSharper is an excellent productivity tool and Dependancy Walker and .NET Reflector are excellent analysis and debugging aids

Here's a couple of handy stackoverflow threads:

Do you have any recommended add-ons/plugins for Microsoft Visual Studio?

Favourite Visual Studio keyboard shortcuts

Community
  • 1
  • 1
jscharf
  • 5,829
  • 3
  • 24
  • 16
0

Have you considered installing cygwin and gcc? If you're looking to write a console app, it might just do the trick.

user47559
  • 1,201
  • 8
  • 9
  • I have to do C++/CLI and C#. And I have to work on my coworkers code. And I'd like to at least try to understand what do people see in VS. – liori Aug 17 '09 at 17:46