Troubleshooting

Introduction

This troubleshooting guide contains explanations and solutions to common problems that you may encounter when using Labs Framework. When experiencing issues, please look through this guide first to see if you can identify and fix the problem yourself.
Additional Help
If you'd like to discuss or report an issue that you cannot fix yourself, then please search first to see if your issue has already been reported or fixed.

When reporting new issues, please include information about your system, such as the versions and editions of Visual Studio that are installed (if any), your OS version and bitness (e.g., Windows 7 x64) and whether you've customized the Labs Framework installation in any way. If you're not using the official installation without any modifications, then please include a description of the changes that you've made - even if you don't think that your changes could be related to your particular issue.

You may be asked to provide a small example that reproduces your issue or to reproduce the issue yourself with logging enabled. Instructions will be provided.

Installation Issues

Visual Studio templates are not installed

Visual Studio must be installed before installing the Labs Framework if you want the Labs Framework Visual Studio templates to be installed. If you've installed Visual Studio after installing the Labs Framework, then uninstall and reinstall the Labs Framework so that it will detect Visual Studio and install the templates.
Note: All editions of Visual Studio are supported except for the Express editions.

Lab projects do not open in Visual Studio or they report errors such as missing DaveSexton.Labs.dll

Visual Studio should be closed during installation of the Labs Framework. The installer creates a system environment variable, which is only resolved at startup. If Visual Studio was open during the installation, then restart Visual Studio after the installation completes so that it reads the new environment variable.
Note: If restarting Visual Studio doesn't fix the problem, then try rebooting your computer.

Linked Lab Issues

Build fails with errors related to missing types or assemblies in linked source code files.

Projects containing linked files and projects containing actual files, including labs, base labs and Catalog files, must have the same default namespace.
  1. Right-mouse click the project in Solution Explorer and click Properties.
  2. Select the Silverlight tab for a Silverlight project and the Application tab for all other kinds of projects.
  3. The following field must have the same value between projects to successfully link lab files:
    1. Root Namespace: Available only in Visual Basic projects for Silverlight.
    2. Default Namespace: Available for all C# projects. Available for all Visual Basic projects except Silverlight.
    3. <RootNamespace>: Available only in F# project files (.fsproj). An F# project's properties page does not provide a field to edit this value so you must unload the project, update the value in XML and then reload the project.
  4. For Visual Basic projects, you can simply change the namespace in the appropriate field (see previous list).
  5. For C# projects, you must change the namespace in the Default Namespace field and then refactor the existing namespace in every file in the project to match.
  6. See the Build Issues section for issues related to changing the default namespace in Silverlight and Windows Phone projects.

Build Issues

Silverlight or Windows Phone applications close or crash immediately on startup

The Startup object in Silverlight and Windows Phone projects must be correct. When changing the default namespace in these kinds of projects you must change the Startup object setting; otherwise, you may get build-time or runtime errors that seem unrelated. Windows Phone applications might seem to not start at all, when in fact they are starting and ending immediately because they haven't been given a startup object.
  1. Right-mouse click the project in Solution Explorer and click Properties.
  2. Select the Silverlight tab for a Silverlight project and the Application tab for a Windows Phone project.
  3. In the Startup object field, select the project's Application or App type.

Build or runtime errors related to XAML files

The Build Action of .xaml files must be set to Page in C# and Visual Basic projects. It must be set to Resource in F# projects.
Note: Visual Studio may change the Build Action when copying linked files. This seems to happen more often in Windows Phone projects, where the Build Action is incorrectly set to CodeAnalysisDictionary.
  1. Right-mouse click the file in Solution Explorer and click Properties.
  2. Change Build Action to the correct value based on the language of the project.

Labs application does not display source code for any lab

Make sure that the project can resolve the Labs.targets file and that it's being used when the project is built. This file is required to embed source code into the labs application for all platforms and languages. If you've created a lab project without using a project template that is installed by Labs Framework, then add <Import Project="$(MSBuildExtensionsPath)\Labs Framework\2.0\Labs.targets" /> near the other Import elements in your project file.

Labs application does not display source code for particular labs

This may be caused by using an unsupported organization of code in a source code file for a lab. The current implementation for parsing source files to match their type names with runtime labs depends upon a weak pattern-matching algorithm in all supported languages (C#, Visual Basic and F#).
  1. Use standard whitespace and line breaks within namespace and class definitions.
  2. Do not nest Lab classes in a lab file. This may be supported to some extent, but if you're having problems then try removing the nesting.
  3. Do not include more than one Lab per file. This may be supported to some extent, but if you're having problems then try moving labs into separate files.
  4. Do not use sequential namespaces in a single file. For example, in C# do not define: namespace First { class Helper { } } namespace Second { class Lab1 : BaseLab { } }
  5. Do not place ambiguous language keywords and symbols within comments or strings that precede actual namespace or class definitions. For example, do not add the following comment in C#: // class FirstAttempt : BaseLab - No longer being used

XAML Designer Issues

Labs report one or more errors when opened in the designer for WPF, Silverlight or Windows Phone

It seems that Visual Studio gets confused as to which assemblies are in the current UI context when XAML files are linked between projects targeting different platforms. This may result in one or more of the following errors:
  • Cannot find type local:BaseLab
  • Type universe cannot resolve assembly: DaveSexton.Labs
  • Could not load file or assembly System.Windows, Version=2.0.5.0
To fix these errors:
  1. Close the designer.
  2. Set the designer's project as the start-up project.
  3. Build the project. Sometimes this step isn't necessary.
  4. Open the designer.
  5. If the errors persist, rebuilding the project or restarting Visual Studio sometimes fixes these problems, although only temporarily.

OutOfBrowserContentControl reports a COM error in the designer for WPF, Silverlight or Windows Phone

Typically this error can be resolved as described in the previous issue.

F# designer error: "The given key was not present in the dictionary."

This error occurs because of the x:Class attribute on the UserControl element. Deleting this attribute will fix the problem with the designer; however, this attribute is required for the labs application to match the source XAML file to the source code file for the lab. The labs application will load this lab and it will run without this attribute specified in XAML, but the XAML tab in the application will not be visible for the lab.

Last edited Nov 2, 2014 at 3:45 AM by davedev, version 8

Comments

No comments yet.