Sunday, February 15, 2009

Visual Studio 2008 - Make sure the application for the file type (.xaml) is installed - Quick Fix

February 15, 2009 Posted by Jason Irwin , , 14 comments

I recently started getting the following error message when attempting to open the design view of a XAML document in VS2008:

Make sure the application for the file type (.xaml) is installed

I haven't yet been able to determine the root cause of the issue (I run SP1 of both the .NET Framework and Visual Studio itself and use this functionality every day), though there is a pretty straightforward fix. Navigate to the IDE folder of your VS2008 installation (for me: C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\) in DOS and run the following:

devenv.exe /setup

Reopening the development environment should result in the return of this functionality.

Wednesday, February 11, 2009

Project Conversion Woes: A project with that name is already opened in the solution

February 11, 2009 Posted by Jason Irwin , , , , , 5 comments

Tonight I decided to play with the project conversion (C# to VB.NET) capabilities of the wonderful #develop. For the uninitiated, #develop is an open source .NET IDE which is surprisingly robust, feature rich and lightweight. It has many cool features, one of which is the ability to convert entire projects (not solutions though) between languages. I really can’t recommend this app enough – it can be found at the following link.

I set my project up to convert and it ran smoothly. There were a few error messages (could not convert C# yield statement to VB.NET, anonymous method issues etc.) but pretty straightforward stuff and  the conversion ran extremely quickly. I attempted to add the newly created/converted vb.net project to a newly created VB.NET solution in Visual Studio, only to run into the following message:

A project with that name is already opened in the solution

It took some research but everything I read pointed to the ProjectTypeGuids in the vbproj file. Mine looked as follows:

<ProjectTypeGuids>{60dc8134-eba5-43b8-bcc9-bb4bc16c2548};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

Googling the possible ProjectTypeGuids I came across the following comprehensive list:

http://www.mztools.com/Articles/2008/MZ2008017.aspx

The first GUID (there are two – delimited by a semi-colon) was correct. {60dc8134-eba5-43b8-bcc9-bb4bc16c2548} corresponds to Windows Presentation Foundation (WPF) and the project I converted was a WPF C# application. However, the second GUID was incorrect – apparently a failure of the conversion process.

{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} corresponds to Windows (C#) and my app was no longer a C# app. Replacing this with its VB.NET equivalent - {F184B08F-C81C-45F6-A57F-5ABD9991F28F} – the line in the project file became:

<ProjectTypeGuids>{60dc8134-eba5-43b8-bcc9-bb4bc16c2548};{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</ProjectTypeGuids>

I reloaded the project in Visual Studio and lo-and-behold it worked! Another fine lesson learned!

Tuesday, February 3, 2009

.NET – Modal Dialog Issue

February 03, 2009 Posted by Jason Irwin , , , No comments

Today I finally got to the bottom of a niggling issue that has been bugging me for about a week. I had some downtime and debugged my way through it. The error message was as follows:

Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application

Like many developers I’ve gotten into the bad habit of googling before investigating and the only hits for this error message were related to ASP.NET applications where users were attempting to open a Winforms dialog from an ASP.NET page…

My setup was a little different – a WPF application connected to a server-side remoting service. After running out of ways to phrase my search term I went back to basics and ran the debugger a few times only to discover the root cause…similarly to the ASP.NET issue, someone had stuck a messagebox call in a catch block in our server-side remoting object…The lesson learned: investigate first, google later! :-)