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.
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)
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)
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
Have you considered installing cygwin and gcc? If you're looking to write a console app, it might just do the trick.
Related
I use Xorax IncrediBuild to build Visual Studio 2013 (or later) solutions and projects, they're mostly .vcxproj with a bunch of .csproj ones.
It took me a little bit of digging, but I've learned that:
When IncrediBuild is used with the regular Visual Studio, it uses the Devenv.exe by default.
Since version 5.0, BuildConsole.exe supports a new switch: /UseMSBuild to specifically instruct IncrediBuild to use MSBuild's build engine instead of the default Visual Studio's DevEnv.
So, in case of Visual Studio projects, there are two modes available:
BuildConsole.exe MyProj.vcxproj which uses DevEnv.exe
BuildConsole.exe MyProj.vcxproj /usemsbuild which uses MSBuild.exe
I'd like to learn if there are any differences between using the two engines.
I have made some tests and observed that:
IncrediBuild "Initializing..." phase takes slightly longer in case of DevEnv.exe.
BuildConsole.exe generates different output, obviously.
No (or insignificant) difference in build performance.
In case of building individual C/C++ native projects (.vcxproj) as well as whole solutions (.sln), what are advantages and disadvantages of using DevEnv.exe versus MSBuild.exe?
** disclaimer: I work at IncrediBuild **
We've determined together with Microsoft that in order to get builds that behave in the same manner as building from within Visual Studio (without IncrediBuild), DevEnv should be used. MSBuild executes builds in a slightly different manner than VS both in the build output it produces and in the way it behaves when executing custom steps and some other minor things. If a user wants IncrediBuild builds to behave in the same manner as he is used to when building from Visual Studio, the default way should be used (IncrediBuild executing DevEnv). If a user is used to execute his builds using MSBuild, whether from the command line or through TFS, the UseMSBuild switch should be used. We wanted to allow users to choose the way they would like IncrediBuild to work depending on the way they are used to do that, same as Microsoft supporting both DevEnv and MSBuild.
Additional comments:
The initialization stage is indeed longer when using Devenv, since devenv loads and parses the solution and .vcxproj files in a different manner than msbuild. The more Projects a solution has – the longer this phase should take. The increase of time it takes this phase to complete usually greatly offset by the speed increase in the actual build time – when building several projects at the same time.
Devenv is highly recommended for our Predicted Execution feature which can provide up to 20% of additional build acceleration due to the above way of work which would be not possible using MSBuild.
Microsoft is pretty explicit about it:
For build-related tasks, it is now recommended that you use MSBuild instead of devenv. For more information, see MSBuild Command Line Reference.
A note in the Devenv documentation since VS2010, the first version of VS that started supporting building C++ projects with MSBuild and also changed the default project file extension from .vcproj to vcxproj.
The wisdom of this kind of advice can only be inferred when they are not explicit about it. One you ready saw, Devenv.exe is a pretty heavy process with many DLL dependencies, it takes a while to get going. Another you could fret about with the way you are doing it now, original guidance was to use Devenv.com instead of Devenv.exe. Those dependencies are also troublemakers, the kind that tend to get in the way or just plain fall over when Devenv.exe runs in an unusual runtime environment like a service. Sample story-from-hell is this Q+A, three answers and none look correct. There are others.
Plain advice is to use the recommended way.
I've been writing C/C++ for years using Xcode and am very comfortable with *nix systems. Now I'm working with people who only understand Windows; I've decided to try to learn that environment too.
I was thinking that google would be my best friend, but even the terminology for VS is sufficiently orthogonal to that of Xcode that I can't make any headway. (E.g., what's the equivalent of "Add new Target to project" for VS?)
Can anyone point me to a guide to VS for Xcode practitioners? I've seen lots of translators going the other direction.
Thanks!
I do not know of any XCode to VS Guide, but according to XCode Documentation:
A target specifies a product to build and contains the instructions for building the product from a set of files in a project or workspace.
The analogous concept in Visual Studio would be a project. In Visual Studio, a project contains code files, assets and settings which compile into an output of some sort. (Could be an executable, a DLL, a website, or a few other options...) Projects can reference other projects or other external libraries (System or user libraries) which are all delivered together at compile time.
A solution contains multiple projects which can be related (referenced) and compiled and linked together.
When you first start VS, it will ask you to Open or Create a project. It usually will automatically create a solution and automatically add the project to it. To add additional projects, you can right click the solution in the "Solution Explorer" and add another project.
Hope this helps
I believe what you're looking for is the Build Configuration Manager in Visual Studio. (It's been a while since I've used XCode). As I recall a "Target" in Xcode is how you want the project built. In VS you get a Debug and Release configuration by default but you can use the Build menu and choose "Configuration..." to create more.
I don't know of a tutorial for XCode users but Kate Gregory has some nice beginner screencasts on pluralsight for using Visual Studio 2010. Those may get you over some learning curve hurdles. I think they have a 30 day free trial. If you move on to .NET development they have a lot more that can really help you get up to speed quickly.
Quick Terminology
In Visual Studio you typically create a Solution. A solution can consist of any number of Projects. You can add projects for .DLLs (libraries), services, applications (gui and console based). You can have multiple applications but can only designate one as the Startup Project.
In my typical project I start with the GUI and Add a project of the type I want. Then I often add a library project for new code that I think I can use across multiple applications. Existing code in both supplied libraries and ones you've built are added as References. You can right-click on References in the Solution Explorer and select Add References.
In XCode (when I used it) your IDE consisted of two pieces, XCode and Interface Builder. In Visual Studio you can build interface elements directly in Visual Studio ( but there is also a tool called Blend that allows for UI creation and modification). There are THREE major types of interfaces web (usually an ASP.NET application), WinForms and WPF. I think of WinForms as the equivalent of what you build in IB. WPF is the most recent addition and has lots of advantages but a somewhat steep learning curve.
This is probably oversimplified because VS does so much and I'm mostly familiar with the C# and C++/CLI capabilties. However it also supports Visual F#, Iron Python, Iron Ruby, Visual Basic, Sharepoint, Office Integration,Silverlight, XNA, etc.
Visual Studio is very extensible. There are lots of extensions to make it integrate with other tools. There are also a couple of extremely useful extensions that make refactoring and writing code easier, my personal favorite is ReSharper from JetBrains.
In short: is there a way to compile and run single file in NetBeans or Visual Studio without having to setup and tinker with projects?
I'm currently using code::blocks as my IDE. It's fast and very simple: perfect for my needs as a begginner.
I wanted to dive a little deeper and try out a more advanced IDE such as NetBeans or Visual Studio. It appears I have to mess with projects and have a setup that seems overkill for having to compile and run one very simple .c/.cpp source file that contains less than 50-100 lines of code etc.
Is there a way around this?
You always have to setup a project - this is where information about libraries etc is found by the IDE, so it cannot do without. If you just have one file, and not a lot of dependencies you could just stick with a plain editor. Once you want auto completion of functions, refactoring, etc... you have to store the information about what is relevant somewhere, and the some sort of 'project' will become necessary.
Is there any tool that can convert a large and complex* Visual Studio 2005 (or 2008) Solution into a SCons project?
* Lots of projects and multiple configurations on multiple platforms/compilers
Probably not, and even if there were, SCons gives you significantly more transparency and flexibility about managing your build than visual studio does. As a starting point, it's best to do each one in turn.
Create a new makefile project
Clone the source from one project to another
Invoke scons from the makefile command.
Replace the dependancies on the old project with the scons version.
Test
Repeat from 1. with each project.
Once you've done a few projects, it's pretty easy to refactor the major differences between build types (shared libs, static libs and programs) and platforms into a module of common scons helpers that can be imported. On windows, consider groups of flags for things like debug and release builds, standard library linkage and exception handling.
Also, things to look out for include:
If you're doing cross platform builds, consider the differences between the linking models with respect to the effects of missing symbols.
What you'll do to deal with manifest files and invoking the visual studio tools.
Variant build directories (debug/release) can be tricky at the start. Start simple, and enhance your build once you're sure it's necessary.
The following script looks promising. I may give it a whirl: the reason the by hand solution isn't completely practical due to the sheer scale of the solution in question: it has hundreds of projects. This is why I was thinking a script that would generate SCons modules would give me a starting point.
Unfortunately porting the solution in question to SCons by hand would be a project in itself!, although I do admit it would be the 'correct' way to do it.
I'm curious about your thoughts on moving to a new IDE (specifically Eclipse). I have been hearing wonderful things about it from this community and I'm always on the lookout to try new things.
Currently I'm running Visual Studio 2005, with a bunch of external commands loaded (for compiling down to a binary, running lint, etc). We're developing C code for microcontrollers.
I've read over some of the other threads on here about the advantages and disadvantages to Eclipse and Visual Studio (specifically SO - best IDE thread and SO - best C IDE thread), but I'd like to hear your thoughts on using it for programming an embedded environment. I'd imagine that there is a simple way to use the external tools that Visual Studio currently uses (it simply calls various batch files that we've created).
Is it worth it to specifically switch over to Eclipse?
Answer to you question about way to call external tools: no problem - from eclispe you can anything: external program, batch file etc. Moreover, if you use custom build generator - you could use it transparent with eclipse.
I don't think I would switch from Visual Studio to Eclipse in hopes of getting a better IDE. Typically an embedded manufacturer makes plugins and toolchains that work specificially with Eclispe, that's what makes it worth using in the Embedded world. For example with the NetBurner plug-ins, when creating a new project you can just select New NetBurner Device Excecutable, or New NetBurner Library, all the default includes and libraries get set up for you and the proper cross platform tool chain is set up for you automatically. In the NetBurner case it also uses the Eclipse managed build process (as opposed to make files) which I find nice. There is also support for using make files if you prefer that option.
While I have a couple of tools set up to run as external tools (lint, an auto version updater, DOS prompt etc) most steps can be triggered from pre-build or post-build steps or there are many many add-ons for common needs like source code management, bug tracking, etc. There is great support for SVN, Trac and Mylyn for example. I use both VS2010 and Eclipse. I like them both but VS2010 is the better IDE. It's a little hard to compare because I do C# (and a little C++/CLI )in VS and C++ in Eclipse. That said, I wouldn't relish the though of trying set up VS to do my embedded tasks.