12,064,855 members (43,044 online)
New versions of Fast Solution Build may be found on http://workspacewhiz.com/ in the Other Add-ins section.
When making the transition from Visual C++ 6 to Visual Studio .NET, it became evident multi-project solution builds were quite a bit slower than their Visual C++ 6 counterpart workspaces. For people working in a single project environment, the difference is negligible. For multi-project solutions, the pain of using the Build Solution command quickly becomes obvious, while waiting for all the "dependency checking" for every project of the solution.
Fast Solution Build emulates the Visual C++ 6 build style. It builds on
the concepts from the original Fast Project Build VBScript macro, while
providing more ease of use and error checking. In
Debug command is now available.
Build Solutioncommand, no slow per project full solution dependency checks are performed.
Debug.Startis available through the Run Active Project command. Unlike
Debug.Start, a slow full solution dependency check is not performed.
The installer offers much more ease of use, including an uninstall feature, and should be used where possible.
The bold project in the Solution Explorer is the top-level
project built by the Fast Solution Build macro. To make a different project
the "startup" project, right click on the desired project and choose
Set as StartUp Project.
Run Fast Solution Build's BuildActiveProject or RunActiveProject commands from the Tools menu or press the keyboard key assigned to the add-in commands.
Fast Solution Build is a C++/ATL enhanced version of the VBScript Fast Project Build macro. It demonstrates many add-in concepts learned while developing the Workspace Whiz add-in for Visual Studio .NET. Most importantly, it illustrates the steps I have discovered to solidly run an add-in.
First, Fast Solution Build is fully capable of installing and uninstalling
itself through just a
regsvr32 call. It is far more
convenient, especially when debugging, not to run an installer for add-in
installations and uninstallations. In AddIn.cpp,
DllRegisterServer() handles registering the server and hooking up the
add-in's registry entries. The critical registry keys are at
The PreloadAddinState key tells Visual Studio .NET to force
creation of the add-in commands. Usually, VS.NET caches the add-in
commands and toolbar entries. Unfortunately, it doesn't do a very good job
of it and often loses the settings for them.
DllUnregisterServer() illustrates a couple of important functions.
First, the add-in registry keys are removed, including GUIDs, typelibs, etc.
Finally, Fast Solution Build actually connects with the VS.NET COM object and
removes its registered commands. If the add-in created a toolbar (Fast
Solution Build just adds commands to the Tools menu), this is an appropriate
place to remove the toolbar, too.
CConnect::OnConnection() code is quite a bit different from
the boilerplate AppWizard generated code. It performs the following steps:
m_pAddInInstanceare set to
NULL. While developing Workspace Whiz, VS.NET called the
OnConnection()function more than once without calling
OnDisconnection(). Setting these values to
OnConnection()calls don't crash.
CommandBarsobject, for instance, results in Visual Studio throwing an exception, instead of returning a proper error code. A similar thing happens when trying to add a named command to the
Commandsobject. Even though you can successfully retrieve the
AddNamedCommand()also causes Visual Studio to throw an exception.
OnConnection()again with a
5(which causes recreation of the toolbar items and add-in commands). This check force recreates the commands, making the assumption they aren't there.
OnDisconnection()not being called. Whole VS.NET crashes would result. Fast Solution Build unregisters the event handlers before it registers them.
Fast Solution Build implements two commands,
identifies the proper command and routes accordingly.
BuildActiveProject works by performing the following steps:
GetOutputWindowPane(). It is cleared and some text is displayed.
EnvDTEobjects can't be retrieved,
BuildActiveProjectexits with an error.
CComSafeArray. If you attach a
CComSafeArrayand don't intend it to be destroyed, be sure to detach it or
CComSafeArraywill destroy it!
VCConfiguration.UpToDateproperty is obtained. This is truly where all the magic happens. It seems as if the
Build Solutioncommand ignores the
UpToDateproperty and calls
Buildall the time. In fact, without the check for
UpToDatein Fast Solution Build, the macro behaves no different than
RunActiveProject expands on
doing the following extra items:
Debug.Startis fired, to simulate the
Continuebehavior when stepping or at a breakpoint.
Finally, Fast Solution Build wedges itself into a couple of BuildEvents.
OnBuildProjConfigDone is triggered, Fast Solution Build checks
for any errors during the current project's build. If it finds any, it
aborts the rest of the build through the
OnBuildDone is triggered and no build errors occurred,
Debug.Start is called, causing the debugger to become active.
Please report any comments, bugs, or fixes to email@example.com - thanks.
4 Dec 2002 - Initial Edit
5 Dec 2002 - Version 2.01