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:

• IVsHierarchyImpl
• IVsUIHierarchyImpl
• IVsHierarchyEventsDelegate
• VsHierarchyRootItemBase
• VsHierarchyItemBase
• VsUIHierarchyItemBase
• VsHierarchyRootItemBase
• HierarchyNode

 

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.

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.

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 ...(read more)

The Visual Studio Library is a C++ source code library whose purpose is to simplify creating a Visual Studio Integration Package....(read more)

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.

The Visual Studio SDK 2005 September (2005-09) Community Tech Preview is compatible* with the Visual Studio 2005 Release Candidate.

The VS SDK 2005-09 CTP can be downloaded from http://www.vsipdev.com/downloads/vsseptemberctp.aspx.

* - Note that we did not do as an exhaustive test pass with that combination as we did with the VS SDK 2005-09 CTP and the Visual Studio 2005 August CTP, so there could be some minor issues that we are not aware of.

The C++ Services Reference Sample is nearly complete, with scenario testing, adhoc testing, a few unit tests, and some additional comments still being needed.

I'm going to swap back to the C++ Tool Window Reference Sample and see about getting the persisted tool window portion of the sample straightened out so that the list view properly supports accessibility and in turn scenario automation.

I also just met with UE about getting VSL documented.  Apparently the creation of our reference docs is all automated now; however, that automation relies on reflection, which obviously doesn't work for a C++ template library with no typelib to generate an interop-assembly from.  The hope is that the tool used to automate the the creation of the 'new' (5 years ago) reference topics for the Standard C++ Library are still around, but if it's not there may be some manual topic creation, or it may not get done until one of our absent UE folks with relevant automation experience get's back.

I just sent them following list of VSL classes I felt critically needed to be documented by whatever means necessary:

• CommandId
• CommandHandlerBase
• IOleCommandTargetImpl
• VsSiteCache
• IVsPackageImpl

Please, leave feedback if you feel that a particular class not on that list is critical need immediate documenting, based on your review of VSL and the C++ Reference Samples in one of our recent CTP releases.