Today’s post covers one of the general IDE improvements that I know a lot of people are already eagerly looking forward to with VS 2010 – multiple-monitor support.

Using Multiple Monitors

VS 2008 hosts all documents/files/designers within a single top-level window – which unfortunately means that you can’t partition the IDE across multiple monitors.

VS 2010 addresses this by now allowing editors, designers and tool-windows to be moved outside the top-level window and positioned anywhere you want, and on any monitor on your system.  This allows you to significantly improve your use of screen real-estate, and optimize your overall development workflow.

Taking advantage of the multi-monitor feature is really easy to-do.  Simply click on a document tab or tool-window and drag it to either a new location within the top-level IDE window – or outside of the IDE to any location on any monitor you want:

You can later drag the document/window back into the main window if you want to re-dock it (or right click and choose the re-dock option). 

Visual Studio remembers the last screen position of documents when saved – which means that you can close projects and re-open them and have the layout automatically startup where you last saved it.

Some Multi-Monitor Scenarios

Below are some screen-shots of a few of the scenarios multi-monitor enables (obviously there are many more I’m not covering).  Pretend each window in the screenshots below is on a different monitor to get the full idea…

Code source file support:

Demonstrates how code files can be split up across multiple monitors.  Below I’ve kept a .aspx file in the main IDE window and then moved a code-behind file and a separate class file to a separate screen:

Tool window support:

Demonstrates how any tool window/pane within VS10 can be split across multiple monitors.  Below I’ve moved the test runner tool windows to a separate screen:

Designer support:

Demonstrates how a designer within VS can be split across multiple monitors.  Below I’ve moved the WPF/Silverlight WYSWIYG designer and the property grid to a separate screen (the code behind file is still in the main window). Note how the VS10 property grid now supports inline color editors, databinding, styles, brushes, and a whole bunch more for WPF and Silverlight applications (I’ll cover this in later blog posts):

Summary

If you work on a system that has multiple monitors connected to it, I think you are going to find the new multi-monitor support within VS10 a big productivity boost.

If you don’t already have multiple monitors connected to your computer, this might be a good excuse to get some…

Hope this helps,

Scott

P.S. In addition to blogging, I have been using Twitter more recently to-do quick posts and share links.  You can follow me on Twitter at: http://www.twitter.com/scottgu (@scottgu is my twitter name)

Today’s post discusses VS 2010’s enhanced multi-targeting support – which allows you to use and target multiple versions of .NET.  We did significant architectural work in the VS 2010 release to enable a number of new multi-targeting features, and provide a much better experience.

Understanding Side-by-Side

VS 2010 can be installed “side by side” with previous versions of Visual Studio.  What this means is that you can install it on the same machine as VS 2008/VS 2005/VS 2003 – and use all of the versions at the same time if you’d like.

.NET 4.0 can also be installed “side by side” with previous versions of .NET on the same machine.  .NET 4.0 has a new version number for both the framework libraries and CLR engine – which means it runs completely independently from .NET 2.0, 3.0 and 3.5.  What this means is that you can install .NET 4.0 on a machine that has .NET 2.0/3.0/3.5 installed, and configure some applications to run using .NET 4.0 and others to run using the older .NET versions (the IIS admin tool allows you to configure this for ASP.NET applications).  This allows you to use .NET 4.0 for new applications - without having to necessarily test and upgrade all your existing ones.

VS 2008’s Multi-Targeting Support

VS 2008 was the first release of Visual Studio that included multi-targeting support for .NET.  What this meant was that you could use VS 2008 to create and edit not only .NET 3.5 projects, but also .NET 3.0 and .NET 2.0 projects as well.  This allowed developers to more quickly upgrade and take advantage of new Visual Studio tooling features – without having to necessarily require the newer version of .NET to be installed on the clients and production servers running their applications.

VS 2008’s multi-targeting support was able to take advantage of the fact that .NET 2.0, .NET 3.0, and .NET 3.5 all ran on top of the same version of the CLR – and that the primary difference between the .NET versions was in their framework libraries.  As a result, Visual Studio’s compilers were able to generate the same IL output, the debugger was able to debug against the same CLR engine, and the IDE support for multi-targeting was primary focused on filtering out new assemblies and project templates from showing up when they weren’t supported with a given .NET version.

This multi-targeting experience worked – although it wasn’t perfect.  Intellisense within VS 2008 always shows the types and members for the .NET 3.5 version of a framework library (even if you are targeting .NET 2.0).  This means that you can sometimes inadvertently end up using a method that is only in ASP.NET 3.5 even when you are working on a ASP.NET 2.0 project.

VS 2010’s Multi-Targeting Support

We made some pretty major architectural changes with VS 2010 to enable much better and more accurate multi-targeting support.

VS 2010 now ships what we call “reference assemblies” for each version of .NET.  A “reference assembly” contains only the metadata of a particular framework assembly – and not its actual implementation (making it much smaller in size on disk).  This metadata is enough, though, to ensure that VS 2010 can always provide 100% accurate intellisense when targeting a particular version of the .NET framework. It also means that properties exposed through the property grid within designers, API listings within the Object Browser, and all the other various places within the IDE accurately reflect the exact API version signature.

We also updated the VS 2010 debugger, profiler and compilers to be able to target multiple versions of the CLR.

Using VS 2010’s Multi-Targeting Support

To get a better understanding of how these new multi-targeting features work, let’s create a new ASP.NET Web Application using VS 2010.  To-do this we can use the “File->New Project” menu command to bring up the “New Project” dialog.  We’ll use the version drop-down at the top of the dialog to filter the project templates to only show those supported with .NET 2.0.  We’ll then create a new ASP.NET 2.0 web application project:

Because we are targeting .NET 2.0 with this project, VS 2010 will automatically filter the toolbox and markup intellisense to only allow us to use those controls that shipped in ASP.NET 2.0.  Unlike VS 2008, the VS 2010 property grid now automatically filters to only show those properties that were supported on the ASP.NET 2.0 button control: 

When writing code, VS 2010 will also now only show code intellisense for those types and methods/properties/events supported with .NET 2.0:

When we run the application using the built-in VS web-server, it will run using the ASP.NET 2.0 version (and the VS 2010 debugger will debug the CLR 2.0 process):

Moving a Project from .NET 2.0 to .NET 4.0

We can optionally retarget our project to work with a later version of .NET by right-clicking on the project within the solution explorer and by bringing up its properties dialog.  We can select the “target framework” dropdown within it and select the version of the .NET Framework we want to target:

We can choose from a variety of different .NET versions above.  Included in the list is the "Server Core” profile that supports the GUI-less version of Windows Server 2008 R2 – and which does not support certain APIs.  Because the reference assemblies we use for metadata and intellisense can support any version or release, we’ll even be able to distribute versions of them with future service packs if they introduce any new APIs (enabling 100% accuracy).

For this walkthrough, we’ll choose to move the project to use .NET 4.0.  When we do this, VS 2010 will update the project reference assemblies and the web.config file of our project to properly reflect the new version.

Once we do this, VS 2010 will filter the toolbox and markup intellisense to show us the new controls and properties available in the ASP.NET 4.0 version.  For example, the property grid below now displays the new “ClientIDMode” property available on all controls in ASP.NET 4.0 - which gives you the ability to control how client id’s are output and avoid ugly client ids (a new ASP.NET 4.0 feature I’ll cover in a later blog post):

Now that we’ve upgraded the project to use .NET 4.0, VS 2010 will also now show us code intellisense for the new types and methods/properties/events on types in .NET 4.0.  For example, below you can see some of the new redirect methods available on the ASP.NET 4.0 “Response” object (which previously did not show up when the project was targeting .NET 2.0):

The new Response.RedirectPermanent() method above makes it easy to issue “HTTP 301 Moved” responses – which can avoid your site accumulating stale links in search engines. The URL Routing engine is now supported by both ASP.NET Web Forms and ASP.NET MVC based applications, and the new Response.RedirectToRoute() method allows you to easily redirect to a route declared with it.

And lastly when we run the application using the built-in VS web-server, VS 2010 will now run it using the ASP.NET 4.0 version:

Summary

VS 2010’s multi-targeting support enables you to work on projects that target .NET 4.0, .NET 3.5, .NET 3.0 and .NET 2.0.  It will allow you to start taking advantage of the new tooling features immediately, without having to immediately upgrade the clients and servers running your application’s to .NET 4.0.  The improved multi-targeting support will ensure that this experience is even better and more accurate than before. 

Hope this helps,

Scott

P.S. In addition to blogging, I have been using Twitter more recently to-do quick posts and share links.  You can follow me on Twitter at: http://www.twitter.com/scottgu (@scottgu is my twitter name)

Today’s post is about another small, but I think nice, change coming with VS 2010 and ASP.NET 4 when you create new ASP.NET Web projects – which is the ability to create both “Empty projects” as well as to create projects that already have some layout and common functionality included in them, and which can help you get started when building a new application.

Creating New Projects

When you use the File->New Project or File->New Web Site menu commands within VS 2010, you’ll see a “New Project” dialog like below that allows you to filter by language and application type and select different project templates to use when creating new projects:

VS 2010 ships with “empty” project templates for creating new ASP.NET applications – which will create minimal projects with just the bare essentials needed to get going.  My last post in this series included a screenshot that shows what the “Empty ASP.NET Web Application” project template creates when you use it to start a new application.

Creating a New Project using a Starter Template

VS 2010 also ships with starter template projects that allow you to create a new ASP.NET application that has some layout/CSS structure and common functionality already implemented within it. 

We first tried this concept with ASP.NET MVC 1.0 – whose project template provides a master page, CSS file, JavaScript libraries, login system, and a “home” and “about” page already wired up and implemented.  VS 2010 adds support for this idea when creating new ASP.NET Web Forms projects as well. 

When you choose the default “ASP.NET Web Application” project template, you’ll find that the ASP.NET Web Forms project created already has some directories and files contained within it:

It includes a Site.Master master page file that provides an overall layout for the site (with headers, footers, etc), and which uses a CSS stylesheet for all styles.  It has a “Scripts” directory that contains jQuery within it (ASP.NET AJAX is available via the script manager control).  It includes a “default.aspx” and “about.aspx” pages in the root directory that are based on the master page and include some boiler plate content.  And it includes an “Account” directory that has some pages that implement a forms-based authentication system for users to log-in, register and change their passwords:

You can run the project without having to write any code or configure anything, and get a nice site up and running:

The site has full support for forms based security authentication, and is pre-wired up to use the ASP.NET Membership system for password management:

All of the styles and content within the site are configured using CSS, and take advantage of some of the new features with Web Forms in ASP.NET 4 – including clean client-side “id” names (no more ctrl_ mangled names – ASP.NET 4 gives you complete control over the client id), and CSS based rendering instead of table based rendering for the built-in server controls.  I’ll discuss these new Web Forms features in a lot more depth in later posts in this series (along with a lot of other features being added).

Online Template Gallery

In addition to the built-in project templates, VS 2010 also support the ability when inside the “New Project” and “Add Item” dialogs to search an online gallery of additional templates to use.  You can contribute your own templates to the gallery, rate and review submissions of others, and search and filter them by project type, keyword and community rating.  You can then easily download and install any template locally directly within the dialog:

This will hopefully facilitate the creation of lots of useful project starter kits (of all types of projects – not just web) that people can easily discover and use to quickly get going when building solutions.

Hope this helps,

Scott

P.S. In addition to blogging, I have been using Twitter more recently to-do quick posts and share links.  You can follow me on Twitter at: http://www.twitter.com/scottgu (@scottgu is my twitter name)

Today’s post is about an admittedly small, but I still think kind of nice, change coming with ASP.NET 4.0: clean, simple, web.config files. 

You’ll encounter this improvement the first time you do a File->New Project within Visual Studio 2010 and create an empty ASP.NET 4.0 Web application (which is why I thought it might be appropriate to-do as the first post).

Web.config files in .NET 3.0 and 3.5

Over the last few releases, the web.config files within new ASP.NET projects have steadily increased in size. For example: the default web.config file that is added to a new web project in Visual Studio 2008 SP1 is now some 126 lines long, and contains everything from tag definitions to definitions of handlers and modules to be included in the ASP.NET HTTP pipeline.

This increase in size is because .NET 3.0 and .NET 3.5 use the same CLR and machine.config configuration file as those shipped with .NET 2.0 – and simply add and update assemblies in the framework when they are installed.  To avoid the risk of us accidentally overwriting customized settings within the original 2.0 machine.config on the machine, we didn’t register the tag definitions, handlers and modules that shipped with the new ASP.NET functionality that came with the .NET 3.0 and .NET 3.5 versions.  Instead, we defaulted to having new projects register these settings within the application’s local web.config file instead.  This was safer – but caused the web.config files to increase and become more complicated and harder to read.

Web.config files in .NET 4

.NET 4 includes a new version of the CLR, and a new .NET 4 specific machine.config file (which is installed side-by-side with the one used by .NET 2, .NET 3 and .NET 3.5).

The new .NET 4 machine.config file now automatically registers all of the ASP.NET tag sections, handlers and modules that we’ve added over the years, including the functionality for:

• ASP.NET AJAX
• ASP.NET Dynamic Data
• ASP.NET Routing (which can now be used for both ASP.NET WebForms and ASP.NET MVC)
• ASP.NET Chart Control (which now ships built-into ASP.NET V4)

What this means is that when you create a new “Empty ASP.NET application” project in VS 2010, you’ll find that the new default application-level web.config file is now clean and simple:

The first config section above just tells ASP.NET to enable debugging by default for the application, and indicates the version of .NET that Visual Studio should target when it provides intellisense (VS 2010 supports multi-targeting – and the intellisense within the IDE will automatically vary depending on which version of the framework you are targeting).

The second config section indicates whether to use “integrated” mode when running the ASP.NET application within IIS7 – which controls whether to run ASP.NET HttpModules for all requests within the application or just for the ASP.NET specific URLs.  We enable this by default at the application level web.config file for new applications – since for compatibility reasons the default IIS7 setting registered at the machine-wide is to run modules only for ASP.NET URLs (and not for all requests).

Summary

The simplified web.config file in .NET 4 is an admittedly small change – but I think a nice one nonetheless, and one which makes the default experience when you create a new ASP.NET application a little cleaner and more approachable.

In the posts ahead I’ll be delving into many of the more substantial improvements coming with ASP.NET 4. (as well as a few more of the “small but nice tweaks” coming too)

Hope this helps,

Scott