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.
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.
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.
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.
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
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.
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:
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.
The C# Example.VSIDEHostAdapter sample unit test project is not yet functional.
The following samples have some failing unit tests:
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.
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.
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.
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.
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.
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:
Call GetService(typeof(IDesignerHost)) on the designer loader
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.
Call the design surface's GetService method with typeof(IServiceContainer)
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");
The code will look like:
if (providerTypeV9 != null)
{
RemoveService(providerTypeV9);
}
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.
For the latest documentation and how-to information about new features, including Visual Studio Shell development, visit the VSX team blog at http://blogs.msdn.com/vsxteam/ and the VSXUE team blog at http://blogs.msdn.com/vsxue/.
To get technical assistance from the community or the VSX product development team, use the following MSDN forums: