Park Place

I had a conversation recently where I discovered that a new "XML to Schema" template was going to be added to the default set of Item Templates shipped with Visual Basic in Visual Studio 2008 SP1.  This template is designed to kick off a wizard that generates an XML Schema (.xsd) file from an XML source and inserts it into your project.  For VB users, this is incredibly useful since the VB IDE uses these schema files to populate their IntelliSense lists for XML literals.  And of course, there's the added benefit of having a tool that can automate XML schema generation. 

You can check out this template at: http://msdn2.microsoft.com/en-us/vbasic/bb840042.aspx

This conversation got me wondering two things:

1. Whether or not it would be worthwhile to add a C# version of this template to Visual Studio
2. What other templates should be added/removed to Visual Studio? 

On the first point, since C# doesn't support XML literals directly in the language like Visual Basic does, the value C# users would get from having this extra template seems to be much less relative to that of VB users.  Of course, this doesn't necessarily mean that it wouldn't be useful for C# users.  Given this, it would be great to hear any thoughts you have on adding this template as a default template for C#. 

On the second point, since we're in the early stages of planning for our next release, it would be great to get any feedback on templates that you feel are either missing or are useless so that we can plan accordingly.

For those of you that are using Visual Studio 2005 SP1, you may have run into an issue where typing certain constructs in an XML doc comment (i.e. <![CDATA[]]> or <!---->) would cause the IDE to become unresponsive.   

Below is an example scenario where this behavior can be observed:

1.   Open Visual Studio 2005 SP1
2.   Create a new C# class library project
3.   Type ‘///’ before the class definition to auto-generate the XML documentation comment
4.   Add a <![CDATA[]]> section in the XML documentation comment
5.   Try adding characters such as ‘<’ in between 'CDATA[' and ']'
6.   The IDE will become unresponsive

To address this issue, we've released a public hotfix that you can download at: https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=9646.

I hope this helps!  Please let me know if you have any questions or comments.

In this blog post, I’ll explain the possibilities and limitations of using solutions and projects between Visual Studio 2005 and 2008.  Read on!

The upcoming release of Visual Studio 2008 introduces a great new feature called ”.NET Framework Multi-targeting” that allows you to target multiple versions of the .NET framework using Visual Studio 2008. (Check out Luke Hoban’s blog and Scott Guthrie’s blog for additional information)  Multi-targeting opens up a new world of possibilities, in addition to its fair share of questions.  One particular question that we’ve been hearing often over the past few months is: “How can I work with solutions and projects between Visual Studio 2005 and Visual Studio 2008?”. 

The short answer to this question is:

1. Solutions created in Visual Studio 2008 cannot be opened in Visual Studio 2005
2. Projects created in Visual Studio 2008 can be opened in Visual Studio 2005
3. Solutions and projects created in Visual Studio 2005 can be opened in Visual Studio 2008

As with all things, there are some subtle details with these statements that I’d like to take some time to explore with you. 

Solutions created in VS2008 cannot be opened in VS2005

As you work with multi-targeting, you or your team may have a need to share solutions between Visual Studio 2005 and Visual Studio 2008.  One common scenario would be opening a solution created in Visual Studio 2008 and targeting .NET Framework 2.0 in Visual Studio 2005.  You’ll find that opening this solution in Visual Studio 2005 will give you the following error dialog.

      Diagram 1: Error message when opening VS2008 solution in VS2005

This dialog demonstrates an important point: Opening Visual Studio 2008 solutions in Visual Studio 2005 is not supported at the solution level.  This is triggered by the fact that the version number in the .sln file of any solution created in or upgraded to Visual Studio 2008 has been updated to 10.00 (see Diagram 2).  This was a tough decision that we had to take during the design of Visual Studio 2008 and was due to the enormous complexity and cost of supporting the resulting compatibility scenarios.  This is an area that we will be actively investigating to improve for our next release.

       Diagram 2: Comparison of .sln files between VS2005 and VS2008

Are there any workarounds?

If you’re daring, there are a few things that you can do to work around this restriction.  Given that these scenarios are not supported, going down these routes may cause your project items to become corrupt, designer elements to break, etc. so please keep these risks in mind. 

1. The first workaround is a rather obvious one that you may have already tried.  It involves modifying the version of the Visual Studio 2008 .sln file to 9.00.  You’ll find that in most cases, this will do the trick and allow Visual Studio 2005 to open the solution.  However, if the solution contains any projects and/or settings that are new to Visual Studio 2008 (i.e. usage of new language constructs, designer interfaces, etc.), the solution can fall apart. I would encourage you to not use this workaround, especially for solutions that contain several projects.

2. The second work around involves adding projects created in Visual Studio 2008 directly into an existing Visual Studio 2005 solution.  The important point to note here is that Visual Studio 2008 projects are not explicitly blocked from being opened/added to Visual Studio 2005 solutions. The motivation behind this decision was to ensure that Visual Studio would remain performant by avoiding the performance hit of checking the versioning of every single project in a solution on startup.  This workaround has similar risks as the first workaround, but given that it forces you to make a targeted decision as to which project to use in the Visual Studio 2005 solution, it may be a viable workaround for you.

A note about the ToolsVersion attribute

For both of the workarounds above, you can update the project files (.csproj, .vbproj, etc.) to control the version of the build tools that will be used. This is done through the ToolsVersion attribute on the Project element. Diagram 3 describes the change that needs to be made in order for a project created in Visual Studio 2008 to invoke the 2.0 version of the build tools.

Solutions and projects created in VS2005 can be opened in VS2008

It's worth mentioning that when opening a Visual Studio 2005 solution or project in Visual Studio 2008, you will see a dialog that will guide you through the upgrade process.  The important thing to keep in mind is that this process will update the version number in the .sln file to 10.00, which will prevent this solution from being opened again in Visual Studio 2005.  Note that all of the points discussed in this post apply to these upgraded solutions and projects as well. 

Closing Thoughts

As always, I’d love to hear your feedback and questions.  I expect there to be some confusion on this topic so feel free to add your comments.  Also, if you happen to run into any issues while trying out different scenarios involving solution/project inter-operability between Visual Studio 2005 and 2008, file a bug on the Connect website.

Since the the release of VS2008 Beta2, we've been getting several reports of a crashing bug in the C# IDE.   If you've run into any crashes and are using explicitly implemented interfaces in a solution that contains project to project references, you're most likely running into this very issue.  More specifically, it turns out that when a C# IntelliSense feature (such as IntelliSense) is invoked on a member of an explicitly implemented interface that's defined in another project, the IDE will end up crashing. 

If you're interested in learning more about the compatibility plans for Visual Studio Codename "Orcas", this is the post for you. 

For products as complex as Visual Studio, achieving seamless compatibility between versions is an immense and ever growing task.  This being the case, we’ve spent a considerable amount of time and energy to reduce the barriers experienced by users after upgrading to Orcas. 

One of the efforts that I’ve been involved with over the past several months is the design time compatibility for Visual Studio.  In a nutshell, design time compatibility refers to the experience Orcas users will have when working with projects, solutions, and assets from previous versions of Visual Studio.  I’ve outlined these experiences in the document that I've attached to this post.  We're still flushing out some details but I would love to get your feedback on what we have so far so please feel free to comment on this post or send me an email at djpark@microsoft.com.  More specifically, I’m interested in the following:

-          What are your thoughts on our current plans?

-          What are your priorities when it comes to compatibility? 

-          Have you run into any bugs or noticed any general areas related to compatibility that you feel need improvement?  If so, what are they?

As a side note, run time compatibility is another interesting area where we’ve put a lot of effort, so if you have any comments or questions about that, I’d love to hear them as well.

As a final side note, check out Jason Zander's blog post from the days of Visual Studio 2005 for more useful information about compatibility. 

What better time than the start of a new year to kick off a blog.  Hi, my name is DJ and I’m a program manager on the C# team.  I work primarily on the Visual C# IDE and my job is to make your job as easy as possible.  Considering that I’m fairly new to not only the C# team, but to Microsoft as well, I hope that you’ll join me as I get more involved in the exciting things that are happening here.