josh's WebLog

good grief

josh_ — Wed, 21 Sep 2005 02:11:00 GMT

i can't believe it's been over nine months since i've blogged anything. i guess i shouldn't be surprised, last time i blogged we had just finished work on beta 2 and now we're getting to that point for RTM ("release to manufacturing", otherwise known as the whole taco). i guess i shouldn't say "finished", but my part in it is pretty much wrapped up, so it's done to me.

lately i've been trying to use the VS text editor, mostly on C++ code and a little C#, and i have to say: could this thing be any more useless? i'll admit it now, i'm a vi user (vim, actually), and i find trying to use a non-vi editor extremely trying. but on top of that it seems to be missing the most basic functionality for a programmer's editor. intellisense, autocompletion, all that stuff is great, but what good is it when i can't do basic text editing chores without getting RSI?

i set about trying to write some VS macros to alleviate some of my pain. (of course writing VB code causes an entirely different kind of pain, and i'm not sure it's entirely worthwhile enduring it, but, well... time will tell anyway). some of the shortcomings of the editor that i wanted to 'fix' include:

1) no "go to next function"/"go to previous function" navigation
2) no functionality to quickly drop/goto "named" bookmarks (ala vi, brief, emacs, just about any decent programmers editor ever)
3) no "center display to cursor" function
4) no ability to cut/copy/paste to and from "named" buffers (again ala almost any decent editor ever created)
5) no functionality to go to the start or end of a function
6) 5) no functionality to go to the start or end of an #if/#ifdef block

these are operations i constantly perform while navigating through code, and the lack of them is painful to my productivity. perhaps if i could replicate them in the VS text editor then using said editor wouldn't be quite so painful...? that remains to be seen.

i wrote macros to cover these six "missing features", and found that the macro for #3 is actually not needed, as there is a command, "Edit.ScrollLineCenter" that does this, I just needed to map it to a key. in writing these macros I was unable to discover any programmatic access to the breakpoints collection or the clipboard "ring" that VS maintains. because of this I had to write the second and fourth items "from scratch" and they don't really work all that well. (the bookmarks aren't real VS bookmarks with icons etc, and after using my "paste from named buffer" macro undo/redo don't work exactly the way you'd want). c'est la vie.

i also found out that trying to figure out what keystrokes are already in use and map commands to new ones is a very frustrating and RSI-inducing experience. the dialog for doing these operations (tools->options->keyboard) is completely inadequate. it provides no way to see what keystrokes are used for what in one central list, no way to quickly unset a keystroke that is already in use and when you need to set a lot of keystrokes it just about kills you. (I had to set (26 * 5) + 7 keystrokes for my new macros and let me tell you, my wrists are killing me right now).

in all, the VS editor doesn't seem designed to actually draw customers. it seems more like it was written to be just "good enough" to pass muster. the idea being, I guess, that all the "cool" features and "integration" that VS provides would be enough to actually get people to use the product. the problem with this, from my perspective as a developer, is that the text editor itself is the most important aspect of the IDE. when actually writing code my productivity is largely gated on how efficiently I can use the text editor. now, i'm the first to admit that most of my job no longer consists of writing code (were that it wasn't so!), but nonetheless, expecting developers to use this sub-standard offering seems ludicrous.

but perhaps i'm overreacting? how do other developers find the VS text editor? am i alone in my assessment? opinions anyone?

exporting/importing Visual Studio settings

josh_ — Thu, 06 Jan 2005 22:18:00 GMT

Todd asks, in comments to my last post, whether there is any way to migrate or save your settings (window layouts et al) in VS.NET between installations/machines/etc. he also asks if how the developers at microsoft handle this.

unfortunately, the answer is that "no" there isn't any good way to save settings across machines or installations in VS.NET 2002 or 2003. there may be some special registry entries and magic files on disk and secret handshake and.. <whatever> that will get you there, but frankly, the work of finding all that out just doesn't seem worthwhile. i suppose you could also write a VS macro that would set most of these options, but honestly i've never explored this possibility.

developers here (that is, the ones that actually use VS) generally fall into two camps with regards to this:
camp one, to which i belong, find it irritating but have gotten used to reconfiguring every time they install a new version. (you think this is irritating for you, imagine how bad that is for those of us who work on VS and install a new version every week or so!)
camp two has just learned to live with the default settings. personally, i'm not sure how anyone could stand to do this, but people apparently manage... :)

whidbey does include a new feature that allows you the ability to export your settings and re-import them. while it doesn't support every possible setting available, hopefully it gets most of them. to be perfectly honest, i have not been able to use this feature successfully (due to the unstable nature of day-to-day builds) and am still resorting to setting all my options manually each time i install a new VS.

Todd, i hope that at least answers your question, even if it wasn't the answer you wanted to hear.

long time no blog: beta 2 go live

josh_ — Wed, 22 Dec 2004 00:58:00 GMT

just a quick note today. it's been half a year since i last blogged and, sad to say, not much has changed. the most notable news is that Peter (Huene) has left the team (and the company). i can honestly say he was one of the best developers that i have worked with in my career. we'll miss him (actually, we already do; he has been gone a while now). his is blog is still the best source of information about the new features that we are adding in the upcoming "whidbey" release of visual studio.

all of us here have been working hard to get the bugs ironed out so that we can ship beta 2 of whidbey. the best thing about beta 2, from a user's perspective, is that it is planned to ship it with a "go live" license, which means that you can use it to develop and ship your software. all of the significant features that we have been working on for this release should be in beta 2 and hopefully it will be quite stable.

well, that's it for now. i wanted to let everyone know that Peter has moved on to other things. also, if there are topics that you would like me to touch on regarding the VC++ IDE features, please let me know.

happy holidays

feedback: export makefile

josh_ — Wed, 19 May 2004 20:22:00 GMT

Stephane asks where the "export makfile" in VS 2002/2003, and if it is coming back in whidbey (VS 2005).
unfortunately the answer is that export makefile does not exist in any version of VS since 6.0 (98) and there aren't any plans to change that. the reasons behind losing this feature in 7.0 (2002) are varied, but most important was the lack of resources (time) to re-implement the work in the new project system (the 7.0 project system was a near-complete re-write, in order to get certain features and fit into the "all-languages-in-one-shell" VS). also figuring into the decision was the feeling that we weren't able to produce good quality makefiles (if you've ever looked at any of the exported makefiles you may agree) and that the command-line devenv /build would somewhat alleviate any pain. (vcbuild.exe may also help alleviate this even further; it has been designed specifically with use in a build lab, and we use it here to build over a million lines of code every night, so hopefully it is getting reasonable "exercise" to ensure that it is useful and stable).
Stephane also mentions msbuild and wonders if that will somehow help this situation. sadly, the only honest answer i can give is "not in whidbey": to the best of my knowledge, VC projects will not support msbuild, and msbuild will not ship official support for VC. i'm not sure how much i should really comment on this, so i'll just say that practical considerations (time/manpower) precluded doing this work in whidbey.

hope that answers your questions, Stephane.

understanding the VC project system part VII: "makefile" projects and (re-)using environments

josh_ — Wed, 19 May 2004 02:00:00 GMT

many people have codebases that they don't have the luxury of building with the VC project build system. yet they may still want to use the Visual Studio environment to get intellisense on their code etc etc. unfortunately, the intellisense editor features in VS require a project. the solution to this dilemma is what we call a "makefile project". this is really a misnomer, but we continue to call them this for historical reasons.
in a makefile project, the project system doesn't pretend to know anything about your files and how they are built. instead it allows you to set a command line of your choice to build (and rebuild, and clean) the entire project. (the typical example is to run "nmake", hence the "makefile project" appelation. a makefile project doesn't have the usual build tools (compiler, linker, midl etc.) associated with it. if you go to the property pages you won't see them. instead you get one tool, the "nmake tool" (again, misnamed). the nmake tool allows you to set the command lines to run for the build, rebuild and clean actions inside the IDE. when you perform one of these actions, the appropriate command line is run. it also lets you set the output file that is generated by the build, and the project system will do a primitive time-stamp check to see if that file is out-of-date.
using a makefile project you can now add all of your c++ files and the intellisense engine will try to parse them and provide you with intellisense, autocompletion etc. in the upcoming whidbey release, makefile projects will give you even more control by letting you specify the include paths and #defines for the makefile configurations, so that you get more accurate intellisense. [technically, there are really only makefile configurations. a makefile project is just a collection of makefile configurations; in fact, any project could contain makefile configurations. you can change a configuration's type by going to the property pages, general page with the project selected, and changing the "configuration type" property. when you apply this change you can see the available property pages change to match those that should be shown for the type you selected.]

another useful feature in the VC project system is the /useenv switch. if you launch devenv.exe with the /useenv switch, VC will pull the paths for executables, #includes, libraries and assemblies from the PATH, INCLUDE, LIB and LIBPATH environment variables respectively, instead of its internal data. this is quite useful if you normally have a command prompt open with your build environment already set via a batch file or the like. (this is exactly what we do here for using VC ourselves).

long time...

josh_ — Wed, 05 May 2004 20:14:00 GMT

it has been a while since i posted last. that's what i get for letting things get out of hand around here. we've been pushing hard towards getting the first beta of visual studio 2005 (whidbey) ready and that has been taking most of my time. that plus the sunny weather we had for a few weeks. :)
there have been a few comments that i haven't responded to; sorry about that. let's see if i can quickly go over them now:
exothermicus was trying to get custom build steps to run a tool on all the files in a project using VC 6. if i understand correctly exo is setting a custom build step on every file. IIRC, this will override the tool that normally builds the file, so the compiler etc will no longer run. it's been a long long time since i used VC 6, but i'm pretty sure that is the behavior. that's certainly what you should get in VC 2002 and onward. an alternative may be to run the custom tool in a project-level custom build step. the downside is that you'll have to craft the custom build step to explicitly run on each file; there's no support for expanding macros to multiple items (e.g. $(AllFilesInProject)) or iterating over such items.
speaking of VC 2002, John-Mark was having some trouble with it. he was using a custom build step to generate .cpp files, but the .cpp files didn't seem to be getting added to the dependency graph. without more info i can't be certain what the problem there is, but make sure that the generated .cpp files are members of the project. John-Mark, if you have a simple repro project, or more detailed information, i'd be happy to take a look.
Chris was having the unfortunately all-too-common problem of rc files always rebuilding. Chris says the #ifdefs were removed, so the usual culprit of #includes of non-existent files inside #ifdef blocks isn't the issue... unfortunately there isn't any way to grok the dependency information. (Chris, you asked about reading the .idb, but the .idb doesn't have dependency information on rc files, just cpp files). this is one feature we want very badly to get into the product and never manage to. Chris, if you have a small sample project that repros the problem i could take a look and see if i can find out what's going on.

well, i'm out of time right now. next, back to the project system...

understanding the VC project system part VI: custom build steps and build events

josh_ — Wed, 03 Mar 2004 02:30:00 GMT

it has been a little while since my last post; hectic bug fixing seems to have been overfilling the brim of my days. i have a few moments of peace before the next onslaught begins, so i thought i would talk about "custom build steps" and "build events" in the c++ project system.

i believe custom build steps were introduced in VC 4. (i could be mistaken, to be honest i never used VC 2 or 4; i briefly evaluated 1.5 for the company i worked for at the time, used VC 5 later, and have worked to some extent or another on 6+). a custom build step is really just a set of command lines that are associated with either a project configuration or a file configuration. the command lines are executed as a batch file, so any valid batch or cmd syntax can be used inside of custom build steps. this is very useful for checking error return values etc.

to set a custom build step, go to the project properties dialog with either the project or a file selected (depending on whether you want a custom build step at the project-level or file-level), select the "custom build step" node in the left-hand pane and enter the commands you want into the "command line" field. you will also need to set the "output" field to the path to a file that the build step generates. (if there is no value for this property the custom build step will never run). the time-stamp of this output file is checked to see if the custom build step needs to be executed; if the file doesn't exist, the custom build step will always execute. you can also enter "additional dependencies" which are other files that will be time-stamp checked to see if the custom build step is out-of-date and needs to execute.

the output of a custom build step is entered into the project's dependency graph, so it is possible, for instance, to set up custom build steps that generate .cpp files and have the build step executed at the correct time (before cl.exe, that is).

the one thing missing in custom build steps is that there isn't any way to set-up a build step that should automatically run on all files of a particular type (like an inference rule in a makefile). we'll be addressing this in whidbey; Peter will likely be covering this in a future entry in his blog.

so that covers custom build steps, what about "build events"? build events were introduced in VC 7. they are sets of command lines, like custom build steps, but instead of running (or not) based on dependency information, they run at a particular time in the build process. VC 7+ support three build events: pre-build (before any other build tool), pre-link (right before the linker) and post-build (after all other build tools). you can't set the output or additional dependencies for a build event, just the command line and whether to run or not ("excluded from build"). a build event, however, will only run if something is out-of-date in the build.

a key to effective use of custom build steps and build events is to use macros wherever possible. rather than hard-coding paths, use macros that point to the appropriate locations. this not only makes it easier to share projects among a team, but helps make the projects more maintainable. also remember that the command lines for these tools is executed as a batch file. anything you can do in a batch file or cmd script you can do in a custom build step or build event, and this gives you quite a bit of power.

understanding the VC project system part V: building, tools and dependencies

josh_ — Sat, 14 Feb 2004 02:39:00 GMT

okay, let's talk about building c++ projects. several things go into building a project: a list of files, the tools that are run, the switches to set on those tools and how we know when to execute those tools.

the files and the set of switches (properties) i've talked about before, see my earlier blog entries. build tools is a slightly more interesting subject. each command-line tool that is run as part of the build (cl.exe, link.exe, midl.exe et al) is wrapped internally by a COM object. (see Peter's blog for more information on our object model). this tool object knows all about its properties, how to convert them into switches, and where it runs in the build process. the overall build driver asks each tool when it should run, organizing the whole set of tools into a set of "buckets" based on their responses, and then calls the tools in each bucket, in order, to generate their command lines. it then executes those command-lines. so the overall build process looks roughly like this:
1) call each tool to find out what "bucket" it should execute in
2) sort the list of tools by "bucket"
3) for each tool:
3a) call the tool to generate its command-line
3b) start a new thread that executes that command-line

an important piece is still missing from this picture, however. we may know that the linker (link.exe) always has to run after the c++ compiler (cl.exe), but how do we know if the compiler needs to run at all? in order to know this we need to know if anything that the compiler tool depends on is out-of-date. to determine if this is the case we need to know the set of inputs to the compiler tool (i.e. the files that are going to be fed into it) and what its outputs are going to be. if an input file is newer than the corresponding output file, then clearly it is out-of-date and the compiler needs to be called on it. tools that don't have any out-of-date inputs don't run. the project system keeps a dependency graph of inputs and outputs which it walks to generate up the list of actual actions that need to be taken at build time.

all tools have these basic input dependencies, or what we call "source dependencies", but there is another kind of dependency that can make a file out-of-date. again, take the c++ compiler as an example. a c++ source file can include another file into itself using the c preprocessor's "#include" directive. if foo.cpp #include's foo.h, and foo.h is out-of-date with respect to the output (foo.obj, in this case) then foo.cpp needs to build. in the VC project system, determining these so-called "scanned dependencies" is up to the tool object, but they are kept track of by the engine's dependency graph, just like source dependencies.

the c++ compiler provides scanned dependency information in a database (stored in the .idb file) that the project system uses to create its list of scanned dependencies. because this information comes from the compiler itself, it is hardly ever wrong (i've only seen one bug in it in the 6+ years that i have worked on the project system). the idl and rc compilers do not however, and the project system calculates their scanned dependencies via a somewhat crude text-scan of the source files. it doesn't understand #define's at all, which causes a bug that often bites developers and causes their projects to always rebuild: if you #include a file which doesn't exist on disk, we mark the file out-of-date. because the file never exists, the #include'ing file is always out-of-date. normally this wouldn't be a problem because the file wouldn't build successfully anyway, but if the #include is inside a #define block that shouldn't be scanned, it might. this bug seems to account for 95% of the cases where a project always builds.

feedback loop

josh_ — Thu, 12 Feb 2004 02:55:00 GMT

Stephane makes some more good points in his last feedback. i have only one comment, which is that while everything he says is true, it ignores my point that these are simply not things we have designed for. we don't have the resources to do everything, and so far we've had more important areas to focus on. you can't try and build an automated build framework or a deployment and install framework when you don't yet have a robust project/build system, for instance. in any case, while features like these may make their way into some future release, they are really beyond my team's scope and i'm not really the most qualified person to comment on them.

feedback on Stephane's comments: activex controls, references, deployment

josh_ — Wed, 11 Feb 2004 01:33:00 GMT

Stephane has responded with some cogent observations and questions, see the feedback to my response yesterday. let's see if i can (briefly) cover the issues he brings up one at a time:

first off, the handling of managed references to activex controls and the differences between how they are handled in c# and vc project systems. to be clear, managed projects referencing activex all treat them the same way, it is native c++ projects that function differently. in managed projects the CLSID for the control is stored in the project file, while in native projects it is not. this is due entirely to the fact that managed projects need the guid in order to build the project and native ones do not. neither project system attempts to use the project file as a repository for deployment information. in fact, deployment is not handled in VS by the language project systems at all, but rather by setting up separate deployment projects. (i won't comment on deployment projects, since i have nothing nice to say).

project file formats really has nothing to do with any of the above. there was never an intention to provide deployment information in the project file itself.

progid, clsids and versioning: there is no correct answer to the COM versioning question(s) and the project system doesn't even try to provide one; if it did, it would always be wrong for some set of customers. some apps would prefer to pick up any version of a control, for instance, while others are tied to a very specific version. COM versioning is a very complex issue, this is one of the prime motivations behind .NET (not that it really solves the issues, if you ask me). what we try to do in the vc project system is to give the developer the flexibility to do what they think is best. if there are ways we can get closer to that goal, we'd love to hear about them.

finally, regarding reference paths and sharing. yes, Stephane, i think you have picked up on exactly what i was saying about references: they aren't designed to be shareable in a flexible manner. hence my recommendation against using them in 2003 unless absolutely necessary. we in VC are certainly trying to improve the situation in whidbey. i can't speak for the c#/vb/j# project system.

understanding the VC project system part IV: properties and property inheritance

josh_ — Tue, 10 Feb 2004 02:25:00 GMT

picking up from where we left off, there are a couple of "special" macros: $(Inherit) and $(NoInherit). to understand what they are and how they work, you first need to understand how inheritance works with properties.

earlier we looked at the property pages dialog for a project. i said one thing in that post that isn't quite true: "if the property value is not bold, the property is in its default state and has not been set". the whole truth is that it means it hasn't been set at that level in the inheritance chain. the inheritance chain for properties, starting with "most-derived" looks like this:
file (file configuration)
project (configuration)
property sheets
defaults
what this means is that when the project system needs to find the value of a property it first checks with the file configuration in question (e.g. foo.cpp, debug configuration), then with the project-level configuration, then with the property sheets and finally, since it wasn't explicitly set anywhere, it falls back to whatever the ultimate "default" value should be. hopefully what the file configuration and project configuration levels are is apparent, and you can view them easily in the property pages dialog by selecting either a file node or a project node in solution explorer when you have the dialog open.

the term "property sheets" is probably new to you, however. property sheets are a mechanism for setting a collection of property values in one place. the items that you see on the "general" property page, under the "project defaults" category actually control which property sheets your configuration inherits from. for instance, if you have "Use of ATL" set to "Dynamic link to ATL", what that actually means is that your configuration inherits from the ATLDynamic.vcstyle property sheet (found in the vc7\VCProjectDefaults directory in your VS installation). if you opened this file you would see that it is an XML file that looks remarkably similar to a project file. in VS 2002/2003 property sheets are only an internal mechanism; in the upcoming version of VS they are exposed to the user so that projects can be configured in quite complex ways. more on this in a future post.

as far as the properties themselves, there are five types: booleans, enumerations, integral values, text strings and multi-strings. booleans, integral values and strings are fairly self-explanatory; enumerations are those properties which have a set number of choices; multi-strings are collections of single strings that are separated by a delimiting character (generally a comma or semi-colon). a good example of a multi-string is the include paths for the compiler to search.

now, getting back to our two special macros, $(Inherit) and $(NoInherit). these two macros allow you to exercise some additional control over how string properties are evaluated. $(NoInherit) means that the normal course of inheritance described above should not be followed, and the property value should be taken from the current level and its "children" only. $(Inherit) is only useful in multi-string properties; it indicates that the values that were inherited from the "parents" should be inserted at the point where the macro is. for instance, let's say the value for the "preprocessor definitions" property on a file configuration is "FOO; $(Inherit); BAR", and the value of the same property on the project configuration is "TOSTADA; $(NoInherit)". now the fully evaluated property value will be "FOO; TOSTADA; BAR", because the $(NoInherit) macro at the project level tells it to not pick up anything from the levels below it, and the $(Inherit) value at the file level tells it to put the inherited values (TOSTADA) between FOO and BAR.

that about covers properties and wraps up the basics of the project system. next i'll be moving on to cover how projects are built.

feedback: assembly references and paths

josh_ — Mon, 09 Feb 2004 21:14:00 GMT

in feedback on my last post, Stephane asks about assembly references and shareable paths in csproj and vcproj files.

c# projects in VS 2002 and 2003 store in the project file a path that is relativized to the project directory. this is called the 'hint path', if memory serves. also, in the .user file for the project (a file intended only for the particular user, not to be shared or checked into source code control) the directory of the reference is stored. as long as all references can be relativized to a shareable location this works. the path cannot be edited in VS and macros cannot be used.

in VC projects in VS 2003 assembly references work slightly differently and have many shortcomings. IIRC a relative path is stored, as in C#, and you cannot control the paths or set them to use macros. my recommendation is to use the project system support for /FU and /AI rather than adding "references". the one time when this is not possible is when you need to use the "designer" (visual form editor). because of the internal workings of the designer it requires you to use references. the support for references will be much improved in the upcoming release of VS.

i'm not quite certain about the last part of Stephane's question, regarding CLSIDs and PROGIDs of assemblies. assemblies are managed entities that don't require CLSIDs or PROGIDs unless they are registered for COM interop. I believe the designer loads the assemblies via a managed call to Assembly::LoadFrom, while at runtime the .NET loader does something similar to Assembly::Load.

understanding the VC project system part III: macros, environment variables and sharing

josh_ — Fri, 06 Feb 2004 01:59:00 GMT

"macros", in the context of the project system, refer to "$(name)" formatted variables that can be used in the project's properties. in VC 5 and 6 there was support for using these kind of macros in some properties. in VS.NET 2002 we extended the support to virtually every property in the project system.

there are two kinds of macros in VS 2002 and 2003: a set of macros that are provided by the project system, such as "$(ProjectDir)" and "$(ConfigurationName)", and macros that are actually environment variables. when the project system evaluates (expands) the value of a macro, it first checks its list of built-in macros, and if it doesn't find it there, then looks in the environment. you can find a list of the built-in macros, and see what they evaluate to, by going to the property pages dialog, selecting any property that is a string-value (e.g. the #defines for the compiler) and clicking either the "..." button or the entry in the drop-down, depending on the property. this will bring up an edit control that has a button named "macros>>". clicking this button will expand the control so that it contains a list of the macros and their expanded values.

using environment variables as macros lets you create paths that are share-able and "source-code-control-able". for instance, if i add "c:\my_includes" to my include path property (C/C++ compiler, general page, additional include directories) then that project is not share-able by another developer who has my_includes installed at "c:\bobs_includes" or "d:\my_includes". but if i use "$(MyIncludes)" then it is. of course, i need to let all the other developers know that they need to set the "MyIncludes" environment variable, or provide them with a batch file that does it for them.

all this is pretty elementary so far, but a surprising number of people don't take full advantage of macros.

i should note one thing: some of the built-in macros are dependent on other built-in macros or properties. for instance, the "$(TargetName)" macro uses the linker's "output file" property, so if you set the "output file" prop to "$(TargetName)" you've clearly created a bad situation. the project system will stop the recursion at 32 evaluations, and print an error message (in the output window) when you build, but this is still something to be aware of.

feedback

josh_ — Thu, 05 Feb 2004 20:37:00 GMT

it's great to see that i've already gotten some feedback! i'll go ahead an provide some brief comments now:

Jerry and Jamie asked about msbuild support for VC in whidbey (the upcoming version of VS). i'll talk about this more in an upcoming entry, when i get to upcoming features, but the short version of the story is that, in whidbey, msbuild will not include first-class support for VC projects. we will be shipping a separate command-line builder "vcbuild" which can build VC projects and spawn out to msbuild to build other projects and mixed-language solutions. in fact, you can download a VS.NET 2003 version of vcbuild.exe now, from www.gotdot.com/teams/cplusplus. again, i'll discuss this further later.

Gareth asked about some his pet peeves in VS. while i don't work on any of the areas he mentions, i must say i couldn't agree more with his comment about the so-called full-screen mode in VS. VC6's full-screen mode was great and really was "full-screen". it didn't make it into VS.NET and instead we got a version that is nowhere near as good. unfortunately there aren't any plans to get this feature back, AFAIK.

as to Stephane's question about why we don't provide a forwards compatibility "export project" feature, it is more about resources than a marketing or technical reason. we have limited time and developers and lots of feature/fix requests. this feature has been a low priority in the past because there were not many requests for it, and it is difficult (if not impossible) to do it such that it works correctly all the time. lately forwards compatibility has been a bigger request, but to be honest i don't think we'll be addressing it in whidbey.

lastly, Chris is wondering why the XML VC project format in VS isn't "real" XML. actually, it's not the XML that is bad (although there is one serious flaw where the newlines in multi-line commands are not stored correctly), but the XML reader that we use. when the XML reader code was written msxml provided two parsers: a DOM-based parser that was rich in functionality but slow and a high-speed bare-bones parser that leaves how the XML is interpreted up to the developer, but is MUCH faster. the way in which the VC loader code works requires certain attributes (in particular, the "name" attribute) to appear in a certain order. (the "name" attribute is used to create the object on which the other attributes are set, so it is needed "up-front"). so i guess the answer is that this is mostly the side-effect of trying to optimize the loader for very large projects. hope that answers your question, Chris.

understanding the VC project system part II: configurations and the project property pages dialog

josh_ — Thu, 05 Feb 2004 01:33:00 GMT

my last entry talked about the files that are contained in a project. this entry is going to discuss the next important collection of items in the project: the configurations.

a configuration is really nothing more than a collection of property values. for instance, in a "debug" configuration the "optimization" property on the C++ compiler tool is usually set to "disabled" (/Od), while in a "release" configuration it is usually set to something like "maximize speed" (/O2). because they control what is built, and how, they are often likened to a "target" in a makefile, although they are not exactly the same.

when you bring up the project properties dialog, the configuration that you are actually manipulating is shown in the upper left in a combo-box control. you can change the configuration and see that the property values below change. you can also select "all configurations" to set properties on all of the configurations simultaneously, but this has one potential danger: any property that is different in different configurations will show as blank. it is easy to accidentally enter a value in a blank property and overwrite that value on all the configurations. (this is particularly insidious with things like the c++ compiler's "preprocessor definitions" property, which consists of a list of strings that is quite often different across configurations. if you type into the blank field and apply the change you have not added new preprocessor definitions to all the configs, like you might think, but have instead replaced all of them with what you just typed).

when browsing through the pages in the property pages dialog one thing you might notice is that some properties are shown in a bold font while others are not. the bold font indicates that the property in question has overridden the value of the property. in other words, if the property value is not bold, the property is in its default state and has not been set.

a project can contain any number of configurations. the VC application wizards generate only two by default, debug and release, but you can add any number of them. for maintainabilities' sake I recommend only creating as many as you actually need. many things that you might be tempted to create a new configuration for can actually be better handled by using project system macros. which is exactly what i'll be discussing in my next entry...