views:

302

answers:

5

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.

+3  A: 

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
You can have multiple instances of one Visual Studio.
Dykam
A: 

Visual Studio is just like Glade and Xcode but much, much more cumbersome.

mcandre
-1 for trolling. This isn't the point of the question.
Bob King
+5  A: 

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
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
These days I'd rather use CMake, but that's a matter of preference. Thank you for links.
liori
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
BTW, take the vims vs. emacsen debate outside.
maxwellb
A: 

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

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
+1  A: 

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

jscharf