Known Issues for Microsoft Visual Studio 2008 SDK 1.0

  • Article

Updated: Section 1.15 added on April 8th, 2008.
Here are many of the known issues in the Microsoft Visual Studio 2008 SDK 1.0.

1. Known Issues

1.1 Run as Normal User is not supported for Visual Studio Shell development

If you are developing a Visual Studio Shell (isolated mode) project, you must log on as an administrator or, if you are running Windows Vista, you must run Visual Studio as an administrator. Running as normal user currently does not work correctly if you are developing a Visual Studio Shell (isolated mode) project.

1.2 Windows Installers (MSIs) that are produced by domain-specific language (DSL) Setup projects must be run from an elevated process in Windows Vista

A Windows Installer program that is produced by a DSL Setup project must be run from an administrator-elevated command prompt under Windows Vista, or as an administrator under Windows XP. If it is not, the installer will display a warning message and then terminate. Under Windows Vista, it is not possible to run the installer by double-clicking the installer and then elevating the installer program permissions. You can work around this by wrapping the installer program in your own setup program. The DSL will then be installed correctly when you run the setup as an administrator.

1.3 Issue with path editor in DSL Designer when editing Element Merge Directives

It is not possible to use the new path editor to edit link creation paths in element merge directives. If you do use the path editor, then you’ll get a validation error on the path. The workaround is to enter a correct path directly as text, which is still supported.

1.4 Microsoft.VisualStudio.Shell.Interop.8.0.dll and Microsoft.VisualStudio.Shell.8.0.dll from the Visual Studio 2005 SDK requires needs to be updated

If you are installing the Visual Studio 2008 SDK on a computer that has the Visual Studio 2005 SDK installed, you should update the Microsoft.VisualStudio.Shell.Interop.8.0.dll and Microsoft.VisualStudio.Shell.8.0.dll in the VS2005 SDK. Some changes were made to this file during the Visual Studio 2008 time frame and to benefit from these changes, you will have to manually update this file. To do so, copy the Microsoft.VisualStudio.Shell.Interop.8.0.dll and Microsoft.VisualStudio.Shell.8.0.dll from:

\Program Files\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Common\Assemblies\
and overwrite the copy under
\Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioIntegration\Common\Assemblies\

If these assemblies are not updated, some warnings may be displayed when building packages that reference this dll. They would look like:

Reference to type 'Microsoft.VisualStudio.Shell.IOleMenuCommand' claims it is defined in ‘\Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioIntegration\Common\Assemblies\Microsoft.VisualStudio.Shell.Interop.8.0.dll', but it could not be found

1.5 Event handling generation in the IronPython Sample

Because IronPython is a dynamic language, event handling generation is not implemented like it is in static languages such as C#. The primary problem is that the IronPython compiler does not produce strongly typed assemblies. Therefore, for WPF, static-language-like event handling creation cannot be illustrated at compile time. Instead, custom event handling is implemented by wiring the event handling code to the compiled XAML.

For the WPF designer to instantiate a custom EventBindingProvider, the type (for example, PythonEventBindingProvider) must be on a path in the registered .NET AssemblyFolders. As a post-build step, PythonProject.csproj registers its output folder as an AssemblyFolder to meet this requirement.

1.6 IronPython/WPF CodeDom registration issue

When you build an IronPython WPF application, you may receive the following error message: “Unknown build error, 'Object reference not set to an instance of an object'”. For XAML compilation to succeed, a valid CodeDomProvider for the language being compiled must be registered on the computer. Because this is a global machine configuration setting, the IronPython sample does not try to register the IronPython CodeDomProvider automatically. To register the IronPython CodeDomProvider manually and build IronPython/WPF projects by using Visual Studio or MSBuild, do the following things:

  • Open %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config in a text editor (such as Notepad).
  • To register the IronPython CodeDomProvider, under the root <configuration> node add the following items:
    <system.codedom>
    <compilers>
    <compiler language="py;IronPython" extension=".py" type="IronPython.CodeDom.PythonProvider, IronPython, Version=1.1.0.0, Culture=neutral, PublicKeyToken=4afbdc4d950a9602" />
    </compilers>
    </system.codedom>
  • Close and save machine.config

1.7 Use of DSL Tools may require experimental hive reset

If you are not the user who installed the Visual Studio SDK, you will not have an experimental hive under HKCU and you will not be able to use the DSL Tools successfully until you create one. The designer creation wizard warns you about this when it unfolds a new solution. The workaround is to reset the experimental hive by using the command that is installed on the Start menu.

1.8 C# Example.VSIDEHostAdapter unit test does not work

The C# Example.VSIDEHostAdapter sample unit test project is not yet functional.

1.9 Some unit tests fail

The following samples have some failing unit tests:

  • C# Reference.ComboBox
  • C# Example.NestedProject
  • C# Example.SccProvider

1.10 The DSL diagram layout is incorrect after undoing the "Bring Tree Here" command

While creating a new Task Flow designer, clicking on "Bring Tree Here", and then selecting Undo results in the diagram layout displaying overlapping elements. The workaround is to collapse and expand inheritance and relationships twice for Flow element shapes.

1.10 TypeConverters and TypeDescriptors are not picked up during the build process or during toolbox initialization.

When adding a custom TypeConverter or TypeDescriptor and then building the DSL, the TypeConvertor or TypeDescriptor is not picked up. The workaround is to rebuild the solution with a clean build.

1.11 Error when new project names exceed 28 characters

When creating a new project using a name that exceeds 28 characters, the project works properly until "devenv.exe /setup" or "devenv.exe /remove" is called during installation, repair, or uninstalling the package. To prevent an error from occurring, all project names should contain 28 characters or less.

1.12 Error when new creating a new VS Shell project without Visual C++ installed

When creating a new VS Shell project, Visual C++ must be installed. Without it on the machine, you will get an error at project creation. To workaround this, launch Visual Studio from Add/Remove programs and add the Visual C++ feature.

1.13 Overriding the Invoke member of OleMenuCommand causes a crash

When inheriting from OleMenuCommand, overriding the wrong Invoke method will cause a crash. If Invoke(object, IntPtr) is overridden, the crash will occur. To work around this, override the Invoke(object, IntPtr, OLECMDEXECOPT) function since that is the one called by the current implementation of OleMenuCommandService.

1.14 Error in the Task List does not navigate to the right line of code.

When creating a custom CodeDom parser, double clicking on an error in the task list brings the customer one line too high in the code file. This is a bug in the TaskProvider.Navigate function. To work around this, you need to prevent the VSDesignSurface from accessing its TaskProvider. Follow these steps to fix this issue:

  1. Call GetService(typeof(IDesignerHost)) on the designer loader

  2. Call GetService(typeof(DesignSurface)) on the designer host

Once you have the design surface, follow the steps below and subscribe to the DesignSurface.Loaded event. You will need to do tis once for each design surface that is created.

  1. Call the design surface's GetService method with typeof(IServiceContainer)

  2. On the service container that gets returned, call RemoveService(typeof(TaskProvider))

If you are converting from a Visual Studio 2005 extension to a Visual Studio 2008 extension, you may also need to use the fully qualified type name for the 9.0 TaskProvider.

The fully qualified name is

Microsoft.VisualStudio.Shell.TaskProvider, Microsoft.VisualStudio.Shell.9.0, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

The code will look like:

System.Type providerTypeV9 = System.Type.GetType("Microsoft.VisualStudio.Shell.TaskProvider, Microsoft.VisualStudio.Shell.9.0, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");

if (providerTypeV9 != null)

{

RemoveService(providerTypeV9);

}

1.15 The DesignTimeRun switch documentation does not appear when devenv.exe /? is invoked

When invoking devenv.exe /?, the help documentation for the DesignTimeRun switch is missing. This switch should be used as a startup argument to all experimental hive instances of the DSL designer that invoke the target designer.

When the DesignTimeRun switch is provided to devenv.exe at startup, it deletes the toolbox cache and recreates it. This takes less time than using devenv /setup to reset the toolbox of the experimental hive.

Using this switch is highly recommended. Without it, the experimental hive toolbox may not be registered or updated correctly during design time, which can lead to corrupt entries.

This switch is not required during deployment of the target designer since a full deployment will run devenv.exe /setup at installation time, which correctly creates the toolbox cache.

2. Product Support

2.1 Latest How-To Information

For the latest documentation and how-to information about new features, including Visual Studio Shell development, visit the VSX team blog at https://blogs.msdn.com/vsxteam/ and the VSXUE team blog at https://blogs.msdn.com/vsxue/.

2.2 Getting Help

To get technical assistance from the community or the VSX product development team, use the following MSDN forums: