This is a bit late in coming, but at the beginning of August I moved from the Ecosystem VS SDK team to the Code Essentials team. The Code Essentials team is the name for the combined Project and Solution, Editor and Navigation, and Source Control Integration teams. The decision to make this move was motivated by the changing direction of the VS SDK team that would have resulted less opportunity for me to write new C++ code future. I should still hopefully continue to make some contributions to the VS SDK in the form of additions to VSL resulting from the refactoring of code owned by the Code Essentials team, but the VS SDK is no longer my primary focus.
For the last three months, I have spent most of my time working with other folks here in the Developer Division to determine how to account for the impact Windows Vista's addition of User Access Control on deveoloper scenarios provided by Visual Studio and implementation of the Visual Studio product itself. More on that later...
The VS SDK 2006-08 CTP will include a new Powertoy called the Extensibility Explorer. The Extensiblity Explorer displays that Visual Studio 2005 registry hives (i.e. 8.0 for the regular hive and 8.0Exp for the experimental hive) and all of the packages registered under each hive. Additionally, under each package are displayed the global services, tool windows, editors, projects registered to that package. The properties displayed in the properties window for the selected package indicate whether the package is loaded or not. The properties for the tool windows indicate whether the tool window is active and whether it is visible.
The VS SDK 2006-08 CTP will also include the source for the Extensibility Explorer as the C++ Extensibility Explorer Reference Sample demonstracting the use of VSL's new VS hierarchy classes.
The new VSL classes are:
The Visual Studio Package wizard that is part of the VS SDK has been updated for the VS SDK 2006-06 CTP. The update includes:
- The generated editors now match up to the new Single View Editor reference samples for both C++ and C#.
- The code generated for C++ has been cleaned up so that it matches the standards of the reference samples.
Enjoy!
The VS SDK 2006-06 CTP will include a new sample that demonstrates integrating a SDK into VS (i.e. it's a sample SDK). Thw sample SDK will:
Show how to use a property sheet provide to configure a VC project to be aware of a SDK.
Show the use of the Help Integration Wizard to create a MSM from a .HSX produced by Help Studio Lite.
Show how to register an assembly so that is list in that they are listed in the “.Net” tab of the “Add Reference” dialog
Show an example of how to organize the file structure of a SDK.
Show how to generate a .Net Primary Interop Assembly for a COM Dll.
Show how to generate a COM type library for a .Net Assembly.
Attached to this post is the slidedeck from the VSL Deep Dive presentation I did last Monday at the April VSIP Dev Lab here in Redmond.
Attachment(s): VSLDeepDive.ppt
Sample Code Size Comparison (part 2): C++ vs. C#
Follows is the data I previously posted here, with the addition of the new Single View Editor Reference samples:
|
|
Code Lines |
Comment Lines |
Characters |
Semi-colons |
Functions |
|
Feature equivalent |
|
|
|
|
|
|
C++ Tool Window |
828 |
508 |
53,858 |
228 |
34 |
|
C# Tool Window |
844 |
724 |
63,686 |
433 |
49 |
|
C++ Menus & Commands |
178 |
222 |
18,996 |
38 |
11 |
|
C# Menus & Commands |
227 |
201 |
20,498 |
90 |
10 |
|
C++ Services |
315 |
320 |
28,230 |
78 |
15 |
|
C# Services |
270 |
289 |
26,773 |
101 |
13 |
|
C++ Single View Editor |
2,653 |
1,203 |
130,689 |
879 |
142 |
|
C# Single View Editor |
3,253 |
1,620 |
251,990 |
1,147 |
276 |
|
Not feature equivalent |
|
|
|
|
|
|
C++ Package |
81 |
201 |
13,648 |
7 |
3 |
|
C# Package |
204 |
261 |
22,284 |
72 |
17 |
Again the flexibility that VSL offers by being distributed as C++ header files, allows it to be added to and changed as needed, where as the MPF binaries are frozen along with the Visual Studio Platform binaries. Another factor is the ability to use multiple inheritance to inherit the implementation for many of the necessary editor interfaces (22 interfaces excluding IUknown, IDispatch, and IConnectionPointContainer).
Follows is data I just pulled from the completed reference samples in the VS SDK:
|
Code Lines |
Comment Lines |
Characters |
Semi-colons |
Functions |
| Feature equivalent |
|
|
|
|
|
| C++ Tool Window |
828 |
508 |
53,858 |
228 |
34 |
| C# Tool Window |
844 |
724 |
63,686 |
433 |
49 |
| C++ Menus and Commands |
178 |
222 |
18,996 |
38 |
11 |
| C# Menus and Commands |
227 |
201 |
20,498 |
90 |
10 |
| C++ Services |
315 |
320 |
28,230 |
78 |
15 |
| C# Services |
270 |
289 |
26,773 |
101 |
13 |
| Not feature equivalent |
|
|
|
|
|
| C++ Package |
81 |
201 |
13,648 |
7 |
3 |
| C# Package |
204 |
261 |
22,284 |
72 |
17 |
The C++ and C# Package samples are included just for completeness as they not feature equivalent, because the C# Package sample has multiple implementations of packages, where as the C++ Package sample only has one that has all features of the different C# examples.
The likely reason why the C++ Tool Window and C++ Menus and Commands samples are smaller then the C# equivalents are due to the guiding principles of VSL, which allows for VSL e added to and changed as needed to faciliate re-use. Thus, anything that looked re-useable in the C++ samples was pushed up into VSL, where as in the C# samples there is code that could possibly be pushed into an assembly for re-use.
That said, personally I think that C++ templates, multiple inheritance, and the C pre-processor provide an advantage over C# when it comes to re-using code, and that much of the purported productivity gain of C# (and Java) over C++ has more to do with the available APIs rather then language differences, in that the .Net Framework is simply a cleaner API to code to then the raw Win32 API's; however, that difference lessens when comparing the C++ libararies (ATL, WTL, C++ Standard Library, and MFC) to the .Net Framework. I think the same is also true when comparing VSL to the MPF although their feature sets are somewhat divergent currently since VSL has no project support and MPF has no editor support. To that end I may look into writing a C++/CLI project sample that utilizes MPF support where it exists for projects now, rather then providing direct support in VSL (which will be some number of months worth of work), but I'm not sure how well that will work out since C++/CLI doesn't support multiple inheritance, so the class inheriting from the MPF Project class will only be able to inherit from that one class.
This the second post in my VSL blog series that began with this post.
The design of VSL is guided by the following principles:
- Minimize coupling
- Avoid feature creep
- Exploit the C++ language and the Visual C++ compiler
- Facilitate unit testing
- Re-use without obstruction
- Responsive to requests
Minimize coupling
Coupling is minimized in several ways by narrowly scoping the functionality of classes and through the use of C++ templates to reduce hard dependencies between classes.
Avoid feature creep
To avoid investing resources in features that may not be needed, only the functionality required for the task at hand is implemented. For example the RichEditWin32Control and ListViewWin32Control classes could provide a complete wrapping of all of the features of the rich edit and list view controls; however, the former only provides those methods needed by the Single View Editor reference sample and the later only provides those methods needed by the Tool Window sample. This is true of most classes in VSL as well. We’re waiting for you to ask for features before we develop them so that we don’t waste resources on feature we think are needed but are not actually needed.
Exploit the C++ language and the Visual C++ compiler
The C++ language and the Visual C++ compiler are exploited in several ways:
- Fail at compile time rather then runtime when possible
- Make use of C++ exceptions
- Use C++ templates and when necessary C pre-processor macros to minimize code redundancy and maximize reuse
- Use of an extended version of the Resource Allocation Is Initialization paradigm
The Resource Allocation Is Initialization (RAII) paradigm is simply that when a resource is allocated it is immediately and directly used to initialize an object that will ensure that the allocation is balanced with a de-allocation. RIAA can also be further extended to any action that needs to be balanced by a counter action, which I’ll call XRIAA (eXtendened Resource Allocation Is Initialization) for want of a better name. Code that consistently uses XRIAA correctly is exception safe*, in that nothing will be left unbalanced in the event that an exception is thrown.
Facilitate unit testing
As integrating into VS requires calling into a lot COM interfaces and some Win32 APIs, it is impossible to unit test an VS Package without mocking up a lot of COM interfaces and Win32 APIs. To that end VSL includes mocks for nearly all VS Platform interfaces and nearly all Windows Platform APIs. VSL also provides wrapper classes around some sets of Win32 APIs, and equivalent mocks for those classes. Other VSL classes that make use of the wrapper classes in turn take them as template parameters so that the mocks can be substituted for unit testing (this also facilitates minimizing coupling, as you can also provide your own wrapper class if you so desire).
Re-use without obstruction
We don’t want to box you in. There are lot of macros that can be overridden to make them do whatever you want (that’s compatible of course). Many classes take template parameters to allow you to provide your own custom implementation for a dependency of that class, and there a couple of policy based classes (a smart pointer and a smart resource although the latter will only be first available with the v2 release next month). Many classes also provide optional, statically bound (using __if_exists and __if_notexists) call backs into a derived class (and we are willing to add whatever additional optional, statically bound callbacks you desire to base clssses). That said there are two things we don’t do 1) Make every class suitable for derivation and 2) make all members protected, in order to leave us some room to refactor without causing breaking changes. However, since all of the source is provided in header files even those limitations can be worked around.
Responsive to requests
It’s been our experience that designs are never perfect the first time, and so a principle of VSL development, is a willingness to make breaking changes (i.e. changes that will require VSL consumers to modify their code), as the need arises. In part this both necessitated and enabled by the short cycle time on VS SDK releases (a CTP every month, and an official release every few months). It is necessitated as we can not afford to sit around making the VSL design “perfect” for months on end without actually producing anything consumable. It is enabled, as taking three years worth of breaking changes in one fell swoop is quite unreasonable, but taking a few every few months, is much more reasonable.
* - note that such code is only synchronous exception safe. C++ exceptions are synchronous, but Win32 structured exceptions like access violations, stack overflows, etc. are asynchronous.
Next up: Visual Studio Library (aka VSL): Simple Unit Test Example
The Visual Studio Library, which I will hereafter refer to as VSL, is a C++ source code library whose purpose is to simplify creating a Visual Studio Integration Package (VS Package) that ships in the Visual Studio SDK, which I will hereafter refer to as the VS SDK. Like WTL, VSL is distributed solely in header files without any binary libraries that need to be linked to. Like STL, the broader C++ Standard Library, ATL, and WTL, VSL makes use of C++ templates and C pre-processor macros extensively. Unlike MFC, the Managed Package Framework (MPF), or the .Net Framework, VSL is not a framework, but is a collection of loosely coupled classes. As such, VSL’s structure doesn’t offer much implicit guidance on how to create common VS integrations like a VS Tool Window or a VS Document \ VS Editor; however, samples are included in the VS SDK that show one possible usage of VSL to create those VS component patterns.
VSL currently provides aid with the following:
- Error and exception handling
- Unit testing
- Functors and delegates
- Comparing various things
- Managing resources
- Command handling
- The basics necessary to create a VS Package
- VS Service consumption
- Creating a VS Window that hosts a dialog or Win32 control
- Creating a VS Document / VS Editor
- Automation and VS Macro recording
Next up: Visual Studio Library (aka VSL): Guiding Principles
As I sit here repeatedly waiting for the unit test for the C++ Single View Editor (the new scrubbed version of BscEdt) to build, I looked back through my blog posts after I joined the VS SDK team last July, and noticed that I've that I haven’t really blogged about Visual Studio Library (aka VSL) very much. My blog posts including mention of VSL can be summarized as follows:
- 12/5/2005 – breaking changes primarily to the unit testing infrastructure.
- 11/2/2005 – link to the official VSL feedback and suggestions thread on the VS Extensibility forum.
- 9/13/2005 – note about VSL documentation status.
- 8/12/2005 – one sentence about three classes VSL provides.
That is not a very impressive amount of content. Looking at the official VSL feedback and suggestions thread I posted on the VS Extensibility forum, I see all I said about what VSL is useful for is:
“VSL is a C++ source library, primarily targeting the Visual Studio Platform, which extends the Active Template Library (ATL).”
Not very descriptive at all.
The official help docs on VSL are also pretty light on content, and the work item to add more comments to VSL keeps getting postponed.
Net result: communication from us regarding VSL is crap.
I’ll start what will hopefully become a long series of blog posts on VSL today.
The
Visual Studio Platform SDK 2005-12 Community Technical Preview is now available here. Wit this release VSL has been expanded to include
mock interfaces for nearly all Visual Studio Platform interfaces. Numerous improvements have been made to the VSL infrastructure for mock objects as well. For more details on the new VSL mock interfaces see
my blog post on it yesterday.
The December CTP of the VS SDK, which has not yet available for downloading as of this posting, includes mock interfaces for nearly all Visual Studio Platform interfaces, as well as numerous changes to the VSL infrastructure for mock objects. The changes to the VSL infrastructure where necessitated in part by the development of the mock interfaces, and in part to make ease the utilization of the mock interfaces in unit tests. If you have any comments or suggestions regarding VSL , please post them on the official VSL feedback thread.
The breaking changes are:
-
The class MockBase is no longer a template class.
-
The static method MockBase::SetUnitTestBase(const UnitTestBase& rUnitTestBase) was removed. The static method UnitTestBase::SetUnitTestBase(const UnitTestBase& rUnitTestBase) should be utilized instead.
-
The static method MockBase::GetCurrentUnitTestBase() was removed. The static method UnitTestBase::GetCurrentUnitTestBase() should be utilized instead.
-
The static method MockBase::CheckValidString(const wchar_t * const pszValid, const wchar_t * const pszParam) was renamed to CheckValidStringW (and CheckValidStringA was added as well).
-
The static method MockBase::CheckValidPointer now has two template arguments instead of one. This is only breaking if the argument is explicitly specified, which is unnecessary, as the compiler can infer the template argument from what is passed into the method.
-
The macro VSL_DECLARE_VALIDVALUES(type) was removed. The macros VSL_DEFINE_MOCK_METHOD_NOARGS_NORETURN(methodName), VSL_DEFINE_MOCK_METHOD(methodName), and VSL_DEFINE_MOCK_METHOD_NOARGS(methodName) should be utilized instead.
-
The macro VSL_CHECK_VALIDSTRING was renamed VSL_CHECK_VALIDVALUE_STRING.
-
The macro VSL_CHECK_VALIDPOINTER was renamed VSL_CHECK_VALIDPOINTER.
-
The macro VSL_RETURN_VALIDVALUES_HR() was removed. The macro VSL_RETURN_VALIDVALUES() should be utilized instead.
-
The class IVsShellFixedVSPropertySet was removed. IVsShellMockImpl should be utilized instead.
The samples VisualStudioIntegration\Samples\IDE\CPP\Reference.MenuAndCommands and VisualStudioIntegration\Samples\IDE\CPP\Reference.Services provide examples of unit tests, which are complete, and make use of the new mock interfaces and the new macros that ease the use of the new mock interfaces.
The sample VisualStudioIntegration\Samples\IDE\CPP\Reference.ToolWindow\UnitTest has more complex unit testing needs then other two samples, and some of this illustrated currently, but the unit test is not yet complete.
Visual Studio SDK 2005-10 RTM is now available for download at http://affiliate.vsipmembers.com/affiliate/downloadFiles.aspx. This the correct version of the VS SDK to utilize with Visual Studio 2005 RTM.
I have also posted a forum topic Official VSL feedback and suggestions thread on the Visual Studio Extensibility forum. I would encourage any C++ developer's targeting the Visual Studio Platform to make use of this thread.
In my last
post, I said a we should be releasing the VS SDK 2005-10 CTP shortly.
We will not be releasing the VS SDK 2005-10 CTP externally, as we just realized that recent changes in files that we pick-up from Visual Studio 2005, have changed such that they will not be compatible with the last RC of VS, so the VS SDK 2005-10 CTP will only worth with the RTM of Visual Studio 2005, and since we are planning to sim ship the SDK with that, there is no value in a VS SDK 2005-10 CTP.
We have nearly completed our September sprint (yes, it's October and we are not done yet, we started out extermely overbooked for the month sprint, and even after extensive cutting, never got caught up). Once complete we will release the VS SDK 2005-10 CTP, which will effectively be the RC for the first official release of the new VS SDK (as opposed to the VSIP SDK), which should be released later this month. If we don't find any ship stopper after the CTP is released and none are reported by you, the community, the content in the official release will be the same as the content in the CTP.
The unit tests for the C++ Tool Window reference sample were not finished in entirety, and a number of new things added to VSL were also not unit tested. We also did not do the architecture diagrams done for the C++ reference samples. Nor did we get strings for extended error information added to VSL (although they have been added to the reference samples). All of these things were cut (and we are still late). The C++ Tool Window sample proved to far more costly then anticipated. The C++ Services and Tool Window reference samples are only trivially documented, and only a fraction of VSL is documented. Adding more verbose comments to VSL was also cut for this sprint.
