The Visual Studio Blog

IntelliSense Crash in VS 2010 RC when using UI Automation

Shortly before the Visual Studio 2010 Release Candidate (RC) was released, the Visual Studio team discovered a significant VS crashing bug on machines using UI Automation (UIA).  This bug will only affect a certain group of users, but for those users it renders the IDE very unstable.  We’d also like to stress that this issue has already been fixed for VS 2010 RTM.

Who is affected?

Only machines with the Visual Studio 2010 RC and an application or device actively using UI Automation 3.0 APIs are affected.  This includes but may not be limited to RC users who are using screen reader software, multi-touch drivers, or tablet PCs.  Furthermore, the issue applies most commonly to customers using UIA on Windows 7 and Windows Server 2008; impact on prior operating systems should be minimal.

What are the symptoms of this bug?

If you are experiencing this issue, you’ll see Visual Studio crashing frequently during rapid typing in the editor while IntelliSense is popping up and/or being dismissed.

How can I work around this issue?

One workaround is to not use UIA on the machine where you're using the VS 2010 RC.  This could include not running a screen reader, uninstalling multi-touch drivers, or disabling the touch features on a tablet PC.  On tablet PCs, this may mean disabling the tablet service (these instructions worked for our tablets, but please note that this link goes to a third-party site that is not supported or maintained by Microsoft).  However, we recognize that this is not an option for all users.

Another workaround involves modifying your registry.  It will alleviate the crashing, but it doesn’t completely fix the issue.  Side effects of this workaround are that:

• You’ll see an unhandled exception dialog the first time you hit the bug in a given VS session:
   
• Every subsequent time you hit the bug, VS 2010 will catch and suppress that exception instead of crashing.  However, the caret will stop blinking and the editor will not accept input until you click on it again to restore focus.

If you’d like to proceed with this workaround, create the registry value HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\General\EnableUnhandledExceptionDisplay as a DWORD and set it to 1.  The crashes should no longer occur, but you will see the side effects described above.

What is the Visual Studio team doing to fix this?

We already have a fix for this bug checked in for VS 2010 RTM.  You won’t need a workaround for the final release, and you’ll be able to use the RTM build on machines with UIA without experiencing these crashes.  We’re also continuing to investigate a more robust solution for VS 2010 RC users; please continue to watch The Visual Studio Blog for updates.

 

If you have any questions about this issue, please feel free to post in the comments below.  If you’re experiencing crashes without UIA or in scenarios without IntelliSense, the root cause is likely different, so we’d encourage you to collect a crash dump if possible and file a Connect bug so we can investigate.

Brittany Behrens
Program Manager, Visual Studio Editor Team

Visual Studio 2010 Release Candidate Now Available!

If you haven’t read the news on other notable MSDN blogs, I’m pleased to announce that the Visual Studio 2010 and .NET Framework 4 Release Candidates are now available for download!  Currently the downloads are only available to MSDN subscribers, but they will be released to the public this Wednesday, February 10th.  This release includes a “go-live” license for users who want to use VS in a production environment. 

As always, we’re really excited to hear feedback about this release – we’ve come a long way since Beta 2 in overall product performance and stability.  Please make sure to send us your feedback via Connect or post comments to this blog.  RTM is just around the corner and we want you to tell us that VS 2010 is ready!

Download and enjoy!

Weston Hutchins – Program Manager, Visual Studio Shell Team Short Bio: I started at Microsoft as an intern in 2005 and have been working in Visual Studio ever since.  I’m currently a PM on the VS Shell IDE team and work on the core IDE UI and services as well as the Extension Manager and http://www.visualstudiogallery.com integration. Prior to my current duties, I was the SKU manager for the Visual Studio Express products.

Visual Studio First Launch Sequence

With the upcoming Visual Studio 2010 Release Candidate around the corner, I would like to talk briefly about some changes we have made to the first-launch-after-installation sequence. Many of you may notice that the first time you start VS after installing, once you have selected a profile, it takes a long time for the main VS window to appear, especially when compared to the Beta2 release last October. I want to make sure users are aware of what is going on here. Let’s talk about the changes we’ve made and the benefit these will have on Visual Studio performance and memory usage.

The longer load time is due to increased caching of key resources at first launch, which we expect to improve the overall performance of Visual Studio. Many subsystems in VS extract data from the 70+ packages which ship in the box and cache critical information in the registry or on disk. Examples of this include profile import, fonts and colors information, and the toolbox. Unfortunately, these caches are often very expensive to create the first time, and involve loading a large number of binaries into memory. As such, users were exposed to unexpected slowdowns and spikes in memory while using VS. As of Beta2, the timing of these spikes has also been unpredictable, as many of the caches were created asynchronously after startup in response to timer events, or loaded on demand in response to a user action (e.g. loading the Tools->Options->Fonts and Colors page).

To solve this problem, we have consolidated all the common operations which enumerate packages into a single step, and run that step out-of-proc during first launch. Once you launch Visual Studio and select a profile from the “Choose Environment Settings” dialog, we delegate all the heavy lifting to a second process, which resolves the profile completely, and creates critical caches for fonts, colors, toolbox items, and Microsoft Extensibility Framework (MEF) types. Once the helper process completes its work, we proceed to display the main user interface.

This design has a number of benefits:

1. By loading all the packages in a separate process which we then terminate, the memory footprint for VS on first launch is reduced significantly as we no longer hold unnecessary packages in memory.

2. By consolidating all the cache-construction into a single step, we eliminate redundant loading of packages to extract data for the various caches.

3. By pre-loading all the cache data, some traditionally slow user operations have been sped up dramatically (e.g. bringing up the Tools->Options->Fonts and Colors page the first time).

However, all the extra work being done at startup, plus the overhead of an extra process, does mean a longer first boot time for VS. Still, no better time to get that cup of coffee, right?

Sasha Siddhartha – Development Lead, Visual Studio Shell Team Short Bio: I started at Microsoft in 2003 and have worked on the Visual Studio Shell since 2008. Prior to that, I have worked in a number of areas across Microsoft, including Microsoft Business Solutions, Windows, and Windows Live.

Announcement: Unpublishing Extensions from Beta 2 to RC

UPDATE 2/8: I forgot to mention a change to the VSIX file format in the Release Candidate that might impact your extensions.  The valid <Edition> values (under <SupportedProducts>) have been updated to better reflect our SKU branding.  The only valid values for RC and RTM are: IntegratedShell, Pro, Premium, Ultimate, Express_All, VBExpress, VCSExpress, VWDExpress, VCExpress.  We have removed VST_All, Pro_All, VSTT, VSTD, and VSTDB from the list of supported values.  If your extension lists any of the removed values, you will need to update your VSIX manifest and reupload your extension.  If this is not done, your extension will not show up in the Extension Manager or the New Project Dialog since SKU-filtering is applied.  Also note, that you only need to include the lowest common denominator supported SKU.  For example, if your extension works in Pro, you only need to list "Pro" under the <Edition> element, as Premium and Ultimate are supersets of Pro and will pick up Pro-supported extensions.

 

When the public Release Candidate (RC) is released later this month, we will be unpublishing all Visual Studio 2010 Beta 2 extensions that are hosted on the http://www.visualstudiogallery.com. We do this because we want to ensure that all extensions are tested and work on the latest release (RC) so that users aren’t treated to numerous errors either when installing or using the extension. This same process was used to convert Beta 1 to Beta 2 extensions. The extension author will have the responsibility of testing and republishing the extension.

FAQ

Q: Will my VS 2008 or VS 2005 extensions be unpublished?
A: No, this will only affect VS 2010 extensions.

Q: Will I need to rebuild my extension and then reupload?
A: Possibly. There have been a few breaking changes in the extensibility APIs from Beta 2 -> RC, so you’ll need to verify that your extension still behaves correctly. If bugs are found, this will require a rebuild. If everything works as expected, a rebuild is not necessary.

Q: How do I republish my extension?
A:

1. Navigate to http://www.visualstudiogallery.com and sign in
2. Click on “My Contributions” on the top navigation bar
3. You’ll see the text “(Unpublished)” next to the title of any contributions that have been unpublished
4. Simply click on the extension and select “Publish”

Q: Will I have to do this for every major VS release?
A: This will need to be done once more when VS 2010 RTM is released. We’re still examining how best to manage this from release to release (both for Service Packs and next versions). If this process is necessary to repeat, we will look to provide a tool or an automated way to move extensions over.

Q: Will my extension work in Beta 2?
A: After two weeks, we will be disabling online extension manager access for VS 2010 Beta 2. This is because extensions that have been ported to RC may not work on Beta 2 anymore.

Please let comments if you have any additional questions about this process.

Weston Hutchins – Program Manager, Visual Studio Shell Team Short Bio: I started at Microsoft as an intern in 2005 and have been working in Visual Studio ever since.  I’m currently a PM on the VS Shell IDE team and work on the core IDE UI and services as well as the Extension Manager and http://www.visualstudiogallery.com integration. Prior to my current duties, I was the SKU manager for the Visual Studio Express products.

Visual Studio “Tip of the Day”

If you like the tips and tricks we sometimes post on this blog, you might want to check out the Visual Studio Tips and Tricks blog.  It’s written by Zain Naboulsi, a Senior Developer Evangelist at Microsoft, and it’s devoted to these little productivity boosters.  We’ll continue to post the occasional tip here on the Visual Studio blog, and we’ll also be helping Zain out with tricks related to the Editor, Shell, Project, Build, Extensibility, and more.  But if you’re interested in a daily timesaver or want to see tips from more areas of Visual Studio, check out the Visual Studio tip of the day.

Brittany Behrens
Program Manager, Visual Studio Editor Team

MSBuild Interview on CodeCast

I had the distinct pleasure to meet up with Ken Levy and talk about MSBuild. Ken is responsible for the CodeCast interviews at code magazine.

The interview consists of an in-depth technical and scenario discussion on how and why to use MSBuild, both in Visual Studio 2008 and Visual Studio 2010.  We also discussed new features for VS 2010 including:

• a new Object Model
• enhanced scheduler
• support for Visual C++
• several new MSBuild language features

You can hear the full interview on the CodeCast site.  Enjoy!

Chuck England
Visual Studio Platform
Program Manager - MSBuild

Tips and Tricks: Ctrl+E to Search in New Project Dialog and Extension Manager

Here’s a quick tip of the day for anyone who wants to quickly use the new search feature of the New Project Dialog and the Extension Manager.  You can press Ctrl+E to quickly set focus to the search box.  Did you know that this same keyboard shortcut also works in Windows Explorer, IE and other applications?  Give it a shot!

Weston Hutchins – Program Manager, Visual Studio Shell Team Short Bio: I started at Microsoft as an intern in 2005 and have been working in Visual Studio ever since.  I’m currently a PM on the VS Shell Team.  No, not the “Isolated” or “Integrated” Shell, but the core VS IDE – its UI and services.  Prior to my current duties, I was the SKU manager for the Visual Studio Express products.

Using the VSIX Manifest Editor

In Visual Studio 2010, we provide a new way of packaging and deploying extensions known as a VSIX. Several project templates in Visual Studio generate VSIX files (from the most basic, VSIX Project, the MEF editor extensions and Visual Studio Packages). The VSIX itself is a simple zip file (using the Open Packaging Convention) containing some content and a manifest (extension.vsixmanifest) that declares what type of extensions are provided by the content in the VSIX. For more information about VSIX files, see Quan To's post on VSIXs. When building an extension that will be deployed via VSIX, you must specify a source manifest (source.extension.vsixmanifest) that will be transformed into the final manifest included in the VSIX. In any of the templates above, you will find a default source.extension.manifest. We provide an editor (shown below) on top of the source manifest to easily allow you to edit to your needs.

 

To start, let's go over the different fields and how they map to different properties of the VSIX and how they are used by the Extension Manager and the standalone Extension Installer (opened when a user double clicks the VSIX).

Required Fields:

ID	The unique identifier of the VSIX. This is used by the Extension Manager to manage the identity of each extension. In particular, when a new version of an extension is deployed, this allows the Extension Manager/Installer to ensure that the old version is replaced. (Maximum length is 100 characters)
Product Name	The name of the product. This is the header for the Extension Manager entry for the VSIX. This is also shown in the Extension Installer. (Maximum length is 60 characters)
Author	The author of the VSIX. (Maximum length is 50 characters)
Version	Specifies the version number of VSIX. Changing this value allows the Extension Manager to know if the VSIX has been updated. The Extension Manager will not permit installing a VSIX if there is already a VSIX with the same ID and same or older version. (Maximum length is 23 characters)
Locale	The intended locale of the VSIX extension.
Supported Framework Edition (Min/Max)	The minimum and maximum editions of the .NET framework supported by your extension(s). (Maximum length is 10 characters)
Description	The description of the VSIX. This is shown in the Extension Manager entry for the VSIX under the product name. (Maximum length is 1024 characters)
Supported VS Editions	The versions/editions supported by the extension. The Visual Studio editions are organized into a hierarchy shown below (in the diagram an edition contains its sub-editions). An edition will install an extension with it or any sub-edition supported. Isolated shell products are considered independent of Visual Studio. As such, support for these must be individually specified. For instance, in the example below, only Visual Studio Professional and an Isolated Shell (Photo Studio) are specified. The Extension Manager/Installer will not install this extension if run from an Express edition or Integrated Shell editions Visual Studio. However, for all higher editions for Professional (Premium and Ultimate in this case), the extension will install. To specify supported Isolated shell editions: Click "Visual Studio Isolated Shell" checkbox Type the name of the Isolated Shell (e.g. Photo Studio) Type a comma followed by the version number for the Isolated Shell product. Consecutive Isolated Shell product entries should be separated by a semicolon.

Optional Fields:

Getting Started Guide	An HTTP\HTTPS URL to a getting started guide for your extension(s). If specified, a Getting Started link will be provided in the Extension Manager under the detailed view of the extension which will navigate to this website.
More Info URL	An HTTP\HTTPS URL to a website containing more info for your VSIX. If specified, a More Information link will be provided in the Extension Manager under the detailed view of the extension which will navigate to this website.
Icon	This specifies which image will be displayed beside the product name for the VSIX in the Extension Manager's list of extensions.
Preview Image	This specifies which image will be displayed in the details for the VSIX in the Extension Manager's list of extensions.
License Terms	Specifies the licensing terms for the extension. This will be shown when a user attempts to install the extension.

 

Here is a screenshot of the fields of the manifest editor filled in with some test data:

In the Extension Manager and Extension Installer this data would appear as below:

The VSIX Manifest Editor goes further than just providing an easy way to edit the VSIX Manifest XML. It also integrates with Visual Studio to simplify the process of adding content to the VSIX. When the Icon, Preview Icon, or License Terms is specified through the Manifest Editor, the corresponding files are added to the project if they are not already present and the "Include In VSIX" property on the files is set to true, so they will be copied into the VSIX generated when the project is built.

The extension content of the VSIX can be viewed at the bottom of the VSIX Manifest Editor in the Content table. The content type specifies the type of extension provided by the content (VS Package, Template Wizard, Toolbox Control, MEF component, Project/Item template, or Custom extension). The path specifies either a project and output group or a relative path (from the project root) to a file. The path will be replaced at build time in the resulting extension.vsixmanifest with the actual location of the file or project output in the built VSIX.

   

The Content element in the extension.vsixmanifest file for the content specified above would be:

 

Extension content can easily be added to the VSIX by clicking Add Content above the Content table to open the Add Content dialog. When the source is a file, it is automatically copied to the project and when the source is a project, a project reference is added with the necessary output groups set on the project reference.

The References table specifies dependencies on other VSIX extensions. If an extension specified is not installed in Visual Studio, the Extension Manager/Installer will prevent the VSIX from installing.

The Add Reference dialog can be used to specify a dependency on another extension or add another VSIX as a payload to be deployed with the current VSIX. For specifying dependencies, you may choose between using the information for an installed extension in current instance of Visual Studio or manually specifying the necessary information.

 

Summary

The VSIX Manifest editor provides an easy way to edit a VSIX's Manifest and adding content to the VSIX. Because it integrates with Visual Studio project system, it ensures that content added through the Add Content dialog is added into the project and is deployed into the VSIX during build. With the Add Reference dialog, you have the option to either deploy your dependencies with your VSIX or declare them so the Extension Installer can verify their presence prior to installation.

 

Lance Collins – Developer, Visual Studio Platform Short Bio>:  Lance started at Microsoft and Visual Studio six months ago. Since starting, he has worked primarily on Visual Studio SDK with various features around VSIX editing and deployment.

How to read/write the new Visual C++ project properties

Visual C++ 2010 introduces several new project and tool properties, and deprecates some old ones.  If you’re writing a project template or Visual Studio extension that needs to programmatically read and write the new properties, you will find that these properties are not available on the standard VCConfiguration, VCCLCompilerTool, etc. set of interfaces.  These are COM interfaces and cannot be changed.  Rather than create new interfaces for the new properties, we’ve introduced a single new interface that will provide access to all project and tool properties: IVCRulePropertyStorage.

Before we dive into IVCRulePropertyStorage, you should take a few minutes to learn about Visual C++ "Rule” XAML files, as Pavan describes in his post: Platform Extensibility – Part 1.

One new property in Visual C++ 2010 is TargetExt, which specifies the filename extension of the primary output of a Visual C++ project.  This property isn’t available on VCConfiguration.  Let’s read and write it using IVCRulePropertyStorage assuming you’ve got a DTE object for the project.  While we’re in there, we’ll read and write a few other properties at the project and file level.  I’ve written this code as it might be seen in the IDE Macro Editor.  You can try copying and pasting this code into the Macro Editor yourself and running it while you have a new C++ console application open in the IDE.

    Public Sub RulePropertyAccess()
        Dim vsPrj As VSProject = CType(DTE.Solution.Projects.Item(1).Object, VSProject)
        Dim vcproj As VCProject = vsPrj.Project.Object
        Dim vcconfigs As IVCCollection = vcproj.Configurations
        Dim vcfiles As IVCCollection = vcproj.Files
        For Each vcconfig As VCConfiguration In vcconfigs
            ' Start by accessing a configuration-level property: TargetExt
            ' The "ConfigurationGeneral" string comes from the 
            ' %PROGRAMFILES%\msbuild\Microsoft.Cpp\v4.0\1033\general.xml
            ' file's <Rule Name="ConfigurationGeneral"> tag.
            Dim generalRule As IVCRulePropertyStorage = vcconfig.Rules.Item("ConfigurationGeneral")
            Dim oldExtension As String = generalRule.GetEvaluatedPropertyValue("TargetExt")
            generalRule.SetPropertyValue("TargetExt", ".dll")
            Debug.Print("TargetExt before: {0} and after {1}", oldExtension, generalRule.GetEvaluatedPropertyValue("TargetExt"))

            ' Now let's access a tool-specific property at the project level: WarnAsError
            ' This property isn't new, so it's available both through VCLinkerTool and IVCRulePropertyStorage
            ' Note however that its MSBuild property name does not match its name on the interface.
            Dim vctools As IVCCollection = vcconfig.Tools
            Dim cl As VCCLCompilerTool = vctools.Item("VCCLCompilerTool")
            Debug.Print("VCCLCompilerTool::WarnAsError reports {0}", cl.WarnAsError)
            Dim clRule As IVCRulePropertyStorage = cl ' we only need to QI for this interface on the same object
            clRule.SetPropertyValue("TreatWarningAsError", Not cl.WarnAsError) ' invert the value
            Debug.Print("VCCLCompilerTool::WarnAsError now reports {0}", cl.WarnAsError)

            ' Now let's set a property for a very specific .cpp file.
            Dim stdafxFile As VCFile = vcfiles.Item("stdafx.cpp")
            Dim stdafxFileConfigs As IVCCollection = stdafxFile.FileConfigurations
            Dim stdafxFileConfig As VCFileConfiguration = stdafxFileConfigs.Item(vcconfig.Name)
            Dim fileCL As VCCLCompilerTool = stdafxFileConfig.Tool
            Debug.Print("StdAfx.cpp VCCLCompilerTool::InlineFunctionExpansion reports {0}", fileCL.InlineFunctionExpansion)
            Dim fileCLRule As IVCRulePropertyStorage = fileCL
            fileCLRule.SetPropertyValue("InlineFunctionExpansion", "OnlyExplicitInline")
            Debug.Print("StdAfx.cpp VCCLCompilerTool::InlineFunctionExpansion reports {0}", fileCL.InlineFunctionExpansion)
        Next
    End Sub

So you see that IVCRulePropertyStorage provides very simple property read/write access.  And exactly where those properties are read from or written to depends on where you acquired the IVCRulePropertyStorage object.  As shown above, you can get this object from the VCConfiguration, a VC*Tool at the VCConfiguration level, or a VC*Tool at the VCFileConfiguration level.  Not shown above is that you can also get this object from the VCPropertySheet::get_Rules collection, similarly to how we show above using VCConfiguration::get_Rules.  As you might expect, IVCRulePropertyStorage objects obtained from VCPropertySheet objects will read and write to that property sheet instead of the project.

The IVCRulePropertyStorage interface can only be used to read and write properties for which a Rule XAML file exists that is imported into the project.  If your software requires custom properties that do not exist in a Rule file, you need to create a Rule file that describes those properties and then import that file into your project, as described in Pavan’s Platform Extensibility – Part 1 and Part 2.  Why do we require these steps?  Because it turns out that project properties have many attributes, such as where they should be persisted in the file, in which file (project or .user file), whether they are project properties or metadata on items or item definitions, etc. etc.  The Rule file allows you to capture all that per-property detail so that your code that invokes IVCRulePropertyStorage can be free of these implementation-specific details.

Every single property available in the Visual C++ Property Pages dialog has a Rule file associated with it already, guaranteeing you convenient programmatic access to read or write any property you find there. 

A note on debugger properties

There are a couple of interesting points to note with regard to properties that configure the debugger. 

Debugger properties are stored in the project user file (*.vcxproj.user) rather than the project itself.  This doesn’t require any special coding on your part—you just acquire the IVCRulePropertyStorage object from VCConfiguration the same as you would for other properties.  The Rule.DataSource tag in the debugger_*.xml rule files tell the IVCRulePropertyStorage to persist to the .user file instead of the project file so that you don’t have to worry about that detail.

In Visual C++ 2008 and earlier, debugger properties were accessed using VCDebugSettings.  This interface had only a small set of properties, many of which were overloaded to control several different debuggers (local, remote, web browser, etc.) so these properties could not be set for a particular debugger without risk of impacting other debuggers.  In Visual C++ 2010 we’ve isolated each debugger’s properties so they are independent of one another.  The VCDebugSettings interface is still present in Visual C++ 2010, but deprecated since it did not have the isolated set of properties per-debugger.  For this reason, we highly recommend you use IVCRulePropertyStorage for getting and setting debugger properties for your Visual C++ 2010 IDE extensions.  As with any other properties, you can discover the set of available properties for each debugger and their names and possible values by inspecting these files: %ProgramFiles%\msbuild\Microsoft.Cpp\v4.0\1033\debugger_*.xml

Searching and Navigating Code in Visual Studio 2010

Every developer knows that navigating code is vital to happy and productive coding. We’ve added several new features for code search and navigation in Visual Studio 2010, including Navigate To and an improved Call Hierarchy, to complement search staples like the Find and Replace dialog and Incremental Search. With such a wide variety of options, we thought it would help to describe many of VS 2010’s code search and navigation features, from old favorites to new additions, in one place:

Find and Replace

The Find and Replace dialog provides your basic search functionality. It comes in three flavors:

1. · Quick Find (Ctrl+F): Optimized for smaller searches, Quick Find is best for searching open documents for a string or expression. It also provides basic options for search scope, partial word matching, case sensitivity, searching up vs. down, and use of regular expressions or wildcards in searches.

· Find in Files (Ctrl+Shift+F): A more robust option, Find in Files is better for searching entire projects or solutions. Unlike Quick Find, Find in Files can list search results in the Find Results window and has additional options to specify which file extensions to search.

· Find Symbol (Alt+F12): Find Symbol allows you to search for symbols, including objects (namespaces, types, interfaces, enumerations, etc.) and members (classes, properties, methods, events, constants, variables, etc.).

Want to use the Find feature without the dialog?  Find Next (F3) will take you to the next occurrence of the text in the toolbar’s Find combo box, which is usually your most recent search term.  To start a new search, just select your desired text in the editor and use Find Next Selected (Ctrl+F3) to jump to the next occurrence of that text.

We’ve also heard feedback that the default Find highlight color, currently a pale blue, is difficult to see and makes it hard to quickly find the results of your search.  Good news:  we’ve updated that color since Beta 2, so it will be a darker blue and hopefully easier to see in the Visual Studio 2010 RC and RTM.  For Beta 2, you can change the highlight color in Tools->Options->Environment->Fonts and Colors by updating the background color for “Inactive Selected Text.”  For RC and RTM, you’ll be able to customize the Find highlight using the background color for “Selected Text.”

Incremental Search

Incremental Search (Ctrl+I) is fast, lightweight, and interactive, allowing you to search for partial words and refine your search in real time. It uses very little screen real estate, doesn’t cover up your code, and is great for quickly finding a piece of code in your current file.  To use Incremental Search, just press Ctrl+I and start typing.  Your search term will appear in the status bar at the bottom of the screen and your search will update as you type.  Press Ctrl+I again to move to the next result and Enter or Escape to end the search.

Navigate To

Navigate To (Ctrl+comma), new for Visual Studio 2010, is a powerful way to search, especially when you’re not sure exactly what you’re looking for. It helps you locate items in your code by using "fuzzy" search capabilities. For example, if you type Foo Bar instead of FooBar, Navigate To will still return useful results. It’s a smart, incremental search that refines as you type and will find any symbols (e.g. file, type, and member names) matching your search terms.

Call Hierarchy

Call Hierarchy (Ctrl+ K, Ctrl+T), or right-click and choose “View Call Hierarchy”, helps you understand the flow of code execution in more complex solutions and projects (C# only). Invoking Call Hierarchy on a method, property, indexer, or constructor in the source code shows you a tree of all the calls to and from that method, property, etc. Each method, property, and constructor in the Calls To and Calls From nodes can also be expanded into its own Calls To and Calls From sub-nodes. Call Hierarchy is great for navigating by code path or understanding relationships between functions.

Go To Definition

Go To Definition (F12) does what its name suggests: it takes you to the definition of a given symbol. It works for a variety of symbols, including methods, types, classes, members, and more. It’s great for diving into implementation details, especially when reading code.

Navigate Backward/Forward

Navigate Backward (Ctrl+minus) and Navigate Forward (Ctrl+Shift+minus) allow you to quickly move between places you’ve already been in your code. For example, say you just used Go To Definition and now you want to go back to where you came from. It’s easy – just use Navigate Backward. If you’re interested in exactly how this works or how we determine exactly where to navigate you back to, check out Sara Ford’s blog post for details.

Highlight References

Highlight References is another new feature in Visual Studio 2010 (C# and VB only). Any time you place the blinking caret on a symbol, Visual Studio will automatically highlight all instances of that symbol for you. So what does this have to do with navigation? You can actually cycle through these highlighted references – just use Ctrl+Shift+up arrow and Ctrl+Shift+down arrow to move to the previous or next highlighted symbol.

All of these are available in VS 2010 Beta 2, so I’d encourage you to try them out, especially the new-for-VS 2010 Navigate To and Call Hierarchy features. Like what you see? Have suggestions for improvements? Want to share your favorite navigation tips & tricks? Please leave a comment and let us know!

Brittany Behrens
Program Manager, Visual Studio Editor Team

Tips and Tricks: Zooming in the VS 2010 Editor

You probably know that Visual Studio has an option to change your text size, but did you know you can also zoom the editor in VS 2010?  Ctrl+mouse wheel zooming has been available since the first Visual Studio 2010 CTP, but we’ve finished it by adding a zoom control and key bindings in Beta 2.  Check out this video we’ve created to demo the new Zoom functionality (this demo has video and audio, so plug in your headphones or turn up the sound).

There are several ways to zoom in and out:

• Hold down Control and scroll your mouse wheel
• Use keyboard shortcuts Ctrl+Shift+period (zoom in) and Ctrl+Shift+comma (zoom out)
• Type a zoom level directly in the the zoom control in the bottom left corner of the editor
• Select a common zoom level from the dropdown list in the zoom control

You can do everything described in this post with Visual Studio 2010 Beta 2, so I hope you’ll try out the new zoom feature and let us know what you think!

Brittany Behrens
Program Manager, Visual Studio Editor Team

Product registration for the About Box in Visual Studio 2010 and the deprecation of IVsInstalledProduct interface

In this article I’ll talk about the information that needs to be specified by a product integrating with Visual Studio to make that product appear in the About box dialog, and the changes to these settings for Visual Studio 2010.

You are probably familiar by now with the layout of the Visual Studio’s About Box dialog.

Beside listing general information about the version of Visual Studio installed (build number, release notes, etc), the dialog displays information about the installed products that are part of or integrate with Visual Studio.

There are 4 types of the information a product can display in the About Box dialog. The product name and product identifier are displayed in a list of available products. Once a product is selected in the list, additional information about it (the Product Details) and the product icon are displayed beneath.

The product name and the identifier are mandatory for a product to be listed in the AboutBox. The details and icons are optional.

Products registration keys

Installed products that want to have information displayed in About Box dialog in Visual Studio need to write a couple of registry keys under InstalledProducts key. The keys are read by VisualStudio when the AboutBox dialog is open, and based on these values further information may be obtained from the products resources or from the product’s packages.

E.g. for VS10 and x86 architecture the registry values needs to be written under a key like:

HKLM\Software\Microsoft\VisualStudio\{versionNumber}\InstalledProducts\{yourProductName}

The {versionNumber} is the version of Visual Studio into which your product is integrating (9.0, 10.0, etc) and {yourProductName} is a registry key string under which detailed registry values will provide further details of the product.

Here is the list of the values that AboutBox reads:

Name	Type	Range	Description
(default value)	REG_SZ	String or resource ID preceded by #	Product name to be displayed to the user in the about box, as a string or as the ID of a string resource in your satellite DLL.
ProductDetails	REG_SZ	String or resource ID preceded by #	Optional product details to be displayed to the user, as a string or as a resource ID in your satellite DLL.
LogoID	REG_SZ	Resource ID preceded by #	Optional resource ID in your satellite DLL of the product icon you want to appear in the about box.
PID	REG_SZ	String or resource ID preceded by #	Product identifier — a string that can identify your product. This is usually the version of your product; Microsoft products use a GUID that identifies both the product and the edition of Visual Studio that is installed.
Package	REG_SZ	Guid of the package	Package belonging to your product, that either implements IVsInstalledProduct interface or whose satellite DLL contains the resource IDs of the product name, details and logo.
UseInterface	REG_DWORD	0, 1	When set, the information to be displayed in about box dialog will be obtained from the product’s package using the IVsInstalledProduct interface; otherwise product registration information is expected to be specified using other registry settings like ProductDetails, LogoID, etc.
UseVSProductID	REG_DWORD	0, 1	Reserved for Microsoft products that are part of Visual Studio. When set, the product will display for the PID a unique string identifying the Visual Studio edition installed. The product-specific PID (provided as resource string, resource ID or obtained from the interface) is ignored.

There are 3 ways of declaring the information to be displayed in the About Box dialog:

1)	Directly, using registry values  The products needs to write the (default) and PID values with strings describing the installed product.  Optionally, the product can write the ProductDetails value. Example: [HKEY_LOCAL_MACHINE\SOFTWARE\VisualStudio\9.0\InstalledProducts\KB945282] @="Hotfix for Microsoft Visual Studio 2008 Shell (integrated mode) - ENU (KB945282)" "PID"="KB945282" "ProductDetails"="This hotfix is for Microsoft Visual Studio 2008 Shell (integrated mode) - ENU. If you later install a more recent service pack, this hotfix will be uninstalled automatically. For more information, visit http://support.microsoft.com/kb/945282" This is the simplest way of registering a product to be listed in About Box. The dialog will display directly the strings read from the registry values. The method is used by VisualStudio patches, plug-ins or other products that don’t have an associated package integrated with Visual Studio (e.g. Crystal Reports). The disadvantage of this method is that the registration strings are not localized, and they will show the same no matter what UI language is selected for Visual Studio in Tools/Options/General/International Settings. Another disadvantage is that products registered using this method will not be able to display an icon in the About box.
2)	Using IVsInstalledProduct interface If the installed product has a package that integrates with Visual Studio, the product needs to write the Package guid and the UseInterface==1 values, then implement the IVsInstalledProduct interface.  To obtain the registration data, Visual Studio will load the package whose guid was specified and will query the IVsPacakge object for the IVsInstalledProduct interface. VS will further call the methods of this interface to obtain the product name, details, logo, etc.  Example: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\InstalledProducts\Microsoft Visual C#] "Package"="{FAE04EC1-301F-11D3-BF4B-00C04F79EFBC}" "UseInterface"=dword:00000001 This used to be in Visual Studio 2008 and previous versions the preferred registration method used by Visual Studio components that have a package (e.g. VB, C#, C++, etc). There is a second (internal) interface Microsoft packages chose to implement, IVsMicrosoftInstalledProduct. This allowed Microsoft products that were part of Visual Studio (e.g. VB, C#) to display a unique PID identifying the Visual Studio edition installed (the Visual Studio Product ID is written in registry keys under HKLM\SOFTWARE\Microsoft\VisualStudio\{version}\Registration). The advantage of this method is that the registration data is provided at runtime by the product’s package. Usually the package reads the data from resources, thus the strings can be localized by providing localized satellite resource dlls. The disadvantage of the method is that it requires the package to be loaded and initialized (more about this later).
3)	Using resource IDs If the installed product has a package that integrates with Visual Studio, it usually means the package contain embedded resources or the product has satellite dlls containing the resources. The about box registration information can come in this case from resources. The product needs to write the Package guid, and (default) value with either the name or (more common) the Id of the string resource in the package’s satellite dll. To declare the product ID, the product needs to either write the PID value (as a string or as the #-prefixed Id of resource with the product ID), or if it’s a Microsoft product that is part of Visual Studio it needs to write instead UseVsProductID==1. Optionally the product can write the ProductDetails and LogoID values. Example: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\InstalledProducts\Microsoft SharePoint Development Tools] "Package"="{262BA188-21A9-4811-940C-7BE458539388}" "ProductDetails"="#3001" "LogoID"="#4000" "PID"="10.0.21019" @="#3000" In this example, the Microsoft.VisualStudio.SharePoint.Project.dll assembly that implements the 262BA188-21A9-4811-940C-7BE458539388 package contains 2 string resources named “3000” and “3001” and an icon resource named “4000”. They match the product name and details (declared as “#3000” and “#3001” values) and the logo resource id (registered as “#4000”). For the PID, the product chose in this case to provide a string directly in registry. This is the registration method preferred in Visual Studio 2010 and later by Visual Studio components (VB, C#, TFS, etc). It it also the usual method of registering 3rd party packages written using Managed Package Framework classes – the sample projects templates using the InstalledProductRegistration attribute with resource values. The advantage of this method is that registration data comes from resources, thus it can be localized. Another advantage is that the package doesn’t have to be loaded and initialized (only the assembly or the satellite dll will be loaded). The disadvantage is that more data has to be declared in registry.

 

Deprecation of IVsInstalledProduct interface

As I mentioned before, using the IVsInstalledProduct interface is a convenient way to provide the product information for the about box dialog.

However, this has a big disadvantage: it requires the product’s package to be loaded, instantiated and sited. During the IVsPackage.SetSite() call a package usually performs initialization (like creating toolwindows, allocating memory and initializing global objects, etc), and may trigger additional packages being loaded by querying their services, which in their turn will require time for initialization and may trigger loading of other packages, etc.  All this takes time that’s not necessary for obtaining the about box registration information. It also has an impact on the memory used by Visual Studio (working set), because packages that are loaded are not unloaded until Visual Studio is closed.

In Visual Studio 2010 timeframe there were more packages added to VS and more products used the IVsInstalledProducts interface for declaring their AboutBox data. As result, on debug builds the time to open the dialog skyrocketed to 30-40 seconds(!). Something had to be done…

To fix the problem, the IVsInstalledProduct interface has been logically deprecated. All Visual Studio components had to change their about box registration data from using the interface (method 2) to declaring and using resource IDs (method 3).

If your product uses the interface, it will continue to work in VS10, but the recommendation is to change the product registration to declare resource IDs in registry instead.

The InstalledProductRegistration attribute in MPF classes has also been changed. As described in MSDN, InstalledProductRegistration's constructor had a “bool useInterface” as first argument.

public InstalledProductRegistrationAttribute (bool useInterface, string productName, string productDetails, string productId)

This constructor allowed developers to use the IVsInstalledProduct interface for providing About Box registration data. However, Visual Studio packages generated with MPF Wizard passed a “false” value to the first argument and instead used explicit resource IDs; the necessary strings and product icon were also generated.

This constructor has been deprecated. If you retarget and compile and old SDK sample project against the newer Microsoft.VisualStudio.Shell.10.0.dll which defines the updated version of the class you’ll get a build warning or error (if warnings are treated as errors). To fix the error simply remove the first argument to InstalledProductRegistration's constructor.

The current constructor of this class looks like this:

public InstalledProductRegistrationAttribute (string productName, string productDetails, string productId)

One other change to the class is that productDetails argument now accepts a (null) value, if you don’t want to provide additional details about your product.

Alin Constantin – Developer, Visual Studio Platform Team
Short Bio: Alin has been at Microsoft for 10 years working on SourceSafe and source control integration in Visual Studio. For Visual Studio 2010, Alin helped writing the code that enabled Visual Studio to move from Windows 32 user interface to a modern UI based on Windows Presentation Framework, worked on localization, About Box dialog improvements, toolbars/menus Customization dialog, etc.

Changing Visual Studio’s Color Palette

Many users have requested different color themes for Visual Studio, or for the ability to change color themes to suit their preferences.  I have just released an extension for Visual Studio 2010 Beta 2 that allows users to customize colors used by our shell color service.

What colors are in the shell color service?

Colors used by the command and window management system can be customized using this extension.  These are colors that can be read programmatically by anyone via the IVsUIShell.GetVSSysColorEx method.  There are a number of specific tool windows (like the Toolbox and the Start Page) that use colors from this color service, so their colors can also be customized.  However, other tool windows (such as the Solution Explorer) use native Win32 controls, which are rendered based on the current Win32 theme and are not inherently color-aware inside of Visual Studio.  The text editor and tool windows based on it (such as the Output window) already use a different user-customizable color service (in Tools\Options\Environment\Fonts and Colors), and are not affected by this extension.

You’ll notice that the color service exposes hundreds of colors, accumulated over many releases of Visual Studio.  It can be difficult to determine where colors are used in Visual Studio (I’m working on making it easier to determine where colors are used for a future version of the extension), and it may seem daunting to consider editing the values of hundreds of colors.  However, there are a few ways to quickly create a new theme without spending hours—some helpful tips are included below.

You can learn more about the color service and other UI guidelines in the Visual Studio UX Guidelines document.

Walkthrough: Creating a new “Expression” gray theme

A frequent request for Visual Studio is an Expression-style theme, so let’s use that as a scenario for the walkthrough.

1.  Install the extension.  You can use the Extension Manager dialog inside Visual Studio (Tools\Extension Manager) and search for “visual studio color theme editor”, or you can download the VSIX file from here.

2.  Create a new theme.  After you install the extension and launch Visual Studio, you should see a new top-level menu called Theme.  The two themes that ship with Visual Studio 2010 are available by default.  The Default theme is the Visual Studio 2010 blue theme, and the High Contrast theme is the theme used when a Windows high-contrast theme is selected.  The High Contrast theme is built entirely of Windows system theme colors, and as such has a limited palette.  There are also three custom themes created as examples—feel free to use them as starting points for your own themes.

 

Choosing “Customize Colors…” brings up the dialog that will let you create a new theme.  The built-in themes are not editable, but you can create a new theme using the hyperlink in the information bar or the toolbar button on the far left.

3.  Change colors to gray.  The Modify Hue/Saturation/Lightness option lets you saturate/desaturate or lighten/darken each color, or rotate the hues of each color.  Hue, saturation, and lightness refer to aspects of the HSL color model; if you’re interested in more information about the HSL model and how it relates to RGB, Wikipedia has a great article.  Using this dialog, we can desaturate all of the colors to gray by moving the S slider to –100.

4.  Apply the theme.  After applying the Modify Hue/Saturation/Lightness dialog, choose OK on the Customize Colors dialog.  The new Gray theme will be applied and should now show up as checked in the Theme menu!

Editing individual colors

Bulk-editing operation will only get you so far, and you will soon want to change the value of a few individual colors.  You can easily do this using the color picker popup.  This popup lets you change the HSL or RGB values of the color directly, or modify the raw hexadecimal RGB value.  You can also specify that the color should come from one of the Windows system colors.  Pressing Enter or clicking Apply will save the value; pressing Escape or clicking away will cancel editing.

Other useful features

• Importing and exporting.  By default, your current set of custom themes is saved in the registry, and restored each time you start Visual Studio.  However, you can export colors into a VSTHEME file for backup purposes, or to share across multiple machines or with friends.  Be careful: importing a theme that you already have will overwrite the in-memory copy; look for improvements in this area in future versions.
• Copy and paste.  By selecting one or more colors in the Customize Colors dialog, you can copy the color’s values.  In the clipboard, these values are stored as as hex RGB values in a comma-delimited string.  You can then paste the values into multiple other color “cells”.  I call them “cells” because copying and pasting behaves the same way that Excel behaves when copying and pasting cell values.  You can even copy a single color, select multiple cells, and paste that single value into all selected cells with one operation.
• Undo and redo.  Any of the operations you take while the Customize Colors dialog is open can be undone and redone while the dialog is open.
• Search filtering.  The Search box above the color list can currently be used to filter the color list by name, which can help you quickly identify all colors containing some keyword (for example, finding all of the “StartPage”-related colors).
• Colorization. The Colorize option lets you apply a single hue to all of the selected colors.  Note that colorizing hues is not the same as the “rotate” feature of Modify Hue/Saturation/Lightness.  When rotating, colors with different hues will still have different hues after rotating their values, whereas colorizing changes every color’s hue to the same value.

Uninstall

Hopefully everyone will happily use this extension forever, but some may decide to uninstall the extension.  If you had any non-Default theme applied before uninstalling, you will find that the colors are still used after restarting Visual Studio (even though the extension is no longer installed).

The reason this happens is that the extension writes registry data to a value that Visual Studio always reads upon startup—even if the extension is not installed.  This is a user-specific value (written to the HKCU Visual Studio registry hive), so every user can have their own theme.  However, extensions in general are machine-wide.  When uninstalling the extension, there isn’t a way to remove the custom theme data from each user’s registry hive, and so each user will have the last-applied theme still applied even after the extension is uninstalled.  To avoid this problem, apply the Default theme before uninstalling the extension—applying the Default theme deletes this registry value instead of writing a custom color theme to it, so it will leave Visual Studio in a theme-free state (at least for your user account).

If you need to clean up these registry keys after uninstalling, you can run the following from a command prompt (replace 10.0 with 10.0Exp if you were using the experimental hive):

reg delete HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\UseDebugColorScheme /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\ThemeColorCache /f

Matthew Johnson – Developer, Visual Studio Platform Short Bio:  Matthew has been at Microsoft for three years and on the Visual Studio Platform for two years.  He works on WPF-related features of the Visual Studio window layout system.

Codecast interviews about the Editor and Extensibility

 

Happy holidays everyone! 

Chris Granger and I met up with Ken Levy the other day to talk about the new Editor and VS Extensibility.

Ken is responsible for the code cast interviews at code magazine.  Chris and I sat down with Ken to discuss the Editor, the SDK, the Extension Manager, VSIX and some of the cool new things we’re shipping in Visual Studio 2010.

The code cast links are below… Enjoy! :)

Visual Studio Extensibility (SDK, Extension Manager)

Visual Studio Editor

What's A PkgDef? And Why?

A .pkgdef file is way to encapsulate application configuration information in an easily editable, distributable, and deployable form. It was introduced in Visual Studio 2008 SP1 to support the configuration of Isolated Shell applications. In Visual Studio 2010, .pkgdef files take on a more expanded role and are much more integrated into both the IDE and the Shell (Integrated and Isolated). This article will briefly describe the .pkgdef format and introduce the scenarios where it is used in VS 2010. Future posts will go into more detail about particular scenarios.

Here is a portion of a .pkgdef file that registers the Extension Manager (which is written as a VS Package) with the IDE:

It looks a lot like a .reg file as exported from the Registry Editor. There is one key difference: the root of the registry key (e.g., "HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0") has been abstracted into the token "$RootKey$". This, and several other tokenized values for registry keys and paths, allows a given .pkgdef file to be reusable for multiple applications and portable to any machine.

This example also demonstrates why this format was originally called a "pkgdef". A .pkgdef file can be used to define the registration of a package. Now that this format is used for many other registration and configuration tasks, there was some talk of changing the name and extension to something more generic. We decided that the pkgdef appellation was just as good as anything else. Like most computer terminology, the first name seems to have stuck.

Let's go back and look at that first application of the .pkgdef file to configure Isolated Shell applications in VS 2008 and see what it involved. An Isolated Shell application reads its configuration data from at least four .pkgdef files.

file	description	location
MyVSShellStub.pkgdef	created by the New Project Wizard when the Isolated Shell application project is created. The master pkgdef configuring the application’s pkgdef environment.	next to MyVSShellStub.exe
MyVSShellStubApplication.pkgdef	created by the New Project Wizard when the Isolated Shell application project is created. Contains basic values for configuring and branding the Isolated Shell application	in Extensions below MyVSShellStub.exe
MyVsShellStub.pkgundef	also created by the wizard. Used to remove (or undefine) packages that are configured as part of the Isolated Shell redistributable installation (see BaseConfig.pkgdef)	next to MyVSShellStub.exe
BaseConfig.pkgdef	part of the Isolated Shell redistributable installation. Contains configuration information for the core features of the Shell, such as the Editor and Designers and the other parts of the IDE	in ShellExtensions\Platform beneath C:\Program Files\ Microsoft Visual Studio X.0\ Common7\ IDE
MyPackage*.pkgdef	created for any VS Package projects that are created as part of the Isolated Shell application	in Extensions below MyVSShellStub.exe (and elsewhere as defined by PkgDefSearchPath)

Notice that that configuration and registration information originates from both the application developer and Microsoft. All of these values have to be merged into a common location specific to the application so that the Shell and the Packages in the application can retrieve them. In VS 2008, this was done during installation of the Isolated Shell application by running the application executable with the "/setup" switch (as a setup Custom Action). This caused the Shell to read all of the .pkgdef files and build a new configuration hive for the application in the registry under HKEY_LOCAL_MACHINE. During the development and test cycle of an Isolated Shell application, the "/ranu" ("run as normal user") switch was used to create a test hive under HKEY_CURRENT_USER, in order to avoid issues with having Administrator access to the registry.

Visual Studio 2010 makes the .pkgdef load and merge operation a normal part of initialization sequence for both the Shell and the IDE. It also locates the target of the merge, known as the config (or configuration) cache, under HKEY_CURRENT_USER (next to the user settings for the application, but with a "_Config" suffix). This eliminates the need to run the merge as part of setup and eliminates the need for the "/ranu" switch during testing. It also enables an additional scenario: the Extension Manager.

The Extension Manager feature allows users to download extensions to the Visual Studio IDE and integrate them without having to run setup. Extensions that are written as VS Packages that must register with the IDE do so using a .pkgdef file. Simply restarting the IDE after the extension is installed (by unzipping its VSIX file) and enabled causes the IDE to build a merged registry hive out of the values that were written to HKEY_LOCAL_MACHINE during Visual Studio setup and the values in .pkgdef files found on disk. The user is not required to take any extra steps or have Administrator privileges.

You may notice that in the case of the Isolated Shell application all of the configuration values come from .pkgdef files. But in the case of the Visual Studio IDE some of the values come from HKEY_LOCAL_MACHINE. In the latter case, VS continues to use the HKLM hive in order to support some compatibility and servicing scenarios. But we plan to continue moving more configuration values out of the registry as we are able.

The .pkgdef file was introduced in VS 2008 to allow a more modular way to deploy configuration values for the Visual Studio Shells. Improvements in .pkgdef file loading and merging in VS 2010 have made the use of .pkgdef files more automatic and enabled the setup-less installation of Visual Studio extensions.

In future posts, I plan to describe in more detail how and when VS decides to refresh the config cache, why a .pkgdef file might not be loaded and how to debug that, and the purposes of the various .pkgdef files. In the meantime, Aaron Marten and Dmitry Goncharenko have already written several excellent related posts, some of which I have already referenced above:

• Pkgdef and the Experimental Instance in VS 2010
• All Your RegKeys Are Belong To Us
• Bootstrapping of VS packages and VSIX extensions in VS2010

You may also want to read an Introduction to the Visual Studio Shell or view a recent Presentation about the Shell in VS 2010.

Bill Weinberger: Developer, Visual Studio Platform

Bill is a relative newcomer to Microsoft, but has many years of software industry experience working on IDEs and vertical applications. For Visual Studio 2010, he was a key contributor to PkgDef Management.