Inside Microsoft® Visual Studio® .NET 2003 [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Inside Microsoft® Visual Studio® .NET 2003 [Electronic resources] - نسخه متنی

Brian Johnson

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










Visual Studio .NET Features


In this section, we'll present an overview of the Visual Studio .NET feature set. We'll look at some of these features in more detail in the next few chapters of the book. Here we'll define some common terms that we can use to describe the different parts of the IDE. Visual Studio .NET is a fairly large and complex product. The terms used to describe the IDE are helpful for developers who are working to understand the tool and, perhaps more important, for developers who will eventually extend the IDE through macros and add-ins.


Editors, Designers, and Tool Windows


The windows in the Visual Studio .NET IDE fall into two major groups. Document windows are windows that usually appear tabbed in the center of the IDE and that contain editors, designers, Web pages, or Help topics. Tool windows are windows in the IDE that present utility functions to the programmer. The tool windows include Solution Explorer, the Class View window, and the Properties window, among others. Tool windows are distinct from editors and designers in the way they dock around the sides of the IDE.

Note

The extensibility API built in to Visual Studio .NET allows programmers to create tool windows for use with language packages installed into the IDE. The editors and designers in the IDE can be accessed through this API, but the extensibility model doesn't allow the creation of new document window types. For that you'll need to look into the Visual Studio Integration Program (VSIP), which we'll describe at the end of this chapter.

Figure 1-3 shows a typical developer setup with the different window types labeled.


Figure 1-3. A typical solution in Visual Studio .NET



Note

All of the managed languages that ship with Visual Studio .NET 2003 feature designer support in the IDE.

The Start Page


The first time you run Visual Studio .NET, you're presented with a Start Page open to the My Profile tab, as shown in Figure 1-4. A profile is a window, keyboard, and Help layout that's tailored to a specific type of programmer. The My Profile tab allows you to select the profile that best describes the type of programmer that you are and to apply those characteristics to the IDE. In general, this page is designed to help you apply a window and keyboard layout that lets you easily transition from your preferred Visual Studio 6 language into Visual Studio .NET. If you're moving to .NET from Visual Studio 6, it's probably worth your time to spend a few minutes viewing the available profiles.


Figure 1-4. Setting the preferred initial profile from the Visual Studio .NET Start Page



Tip

If you can live with it, we suggest going with the default Visual Studio Developer profile. You'll find that most of the books on Visual Studio .NET use this profile and that it lays out the various tool windows in a logical, efficient manner. You'll probably also find yourself spending less time messing with the layout as you rebuild machines and move from one machine to another in your work environment.

In addition to affecting the window layout, the profile you choose affects the keyboard shortcuts that are set in the IDE. For the most part, you'll find that the Visual Basic 6 and Visual InterDev shortcuts have been employed in the appropriate profiles. If you're a C++ programmer who's used to the keystrokes in Visual C++ 6, you might notice some changes that can affect the way you work. For example, in the Visual Studio Developer profile, the Alt+7 Disassembly window keystroke is replaced with Ctrl+Alt+D. If you're finding that the keystrokes you're used to aren't doing what you want in the IDE, we suggest you check the profile you're using and adjust the Keyboard Scheme setting accordingly. In Chapter 3, we'll discuss customizing and saving a keyboard mapping scheme.


Lab: Using a Custom Profile in a Macro


As you delve into Visual Studio .NET extensibility, you'll use the Macros IDE a lot to experiment with the Visual Studio .NET extensibility APIs. We'll discuss macros in detail in Chapter 4, but let's take a minute to try out the macros facility right now. To get started, press Alt+F11 to open the Macros IDE. Take a look in the Project Explorer tool window in the Macros IDE. If you installed the samples for this book, you should see a Macros project named InsideVSNET. In that project, you'll find a module named Samples, which contains macros that demonstrate concepts described in the book.

In this case, the macro we're going to run is named AutoHideToggle. What AutoHideToggle does is to toggle the state of the tool windows in Visual Studio .NET. It does this by calling the Window.AutoHideAll named command that's available from the Visual Studio .NET main menu.

The problem with calling Window.AutoHideAll is that there's no Window.AutoUnhideAll command, so you have to reset the window layout using the Reset Window Layout button in the Options dialog box,reselect your profile from the My Profile tab on the Start Page, or tack open the tool windows you want to see by hand. Our little macro takes care of all this in true hacker style.

We want to keep our carefully customized window layout, so we'll create a temporary profile that stores the positions of all the open tool windows. We'll do this through the DTE.WindowConfigurations object. Our macro will then apply this profile and call the Window.AutoHideAll named command. To get back to where we were, we'll check whether the temporary configuration is the active configuration. If it is, we'll use Apply again, which will load all the tool windows back into place.

Here's the code:

[View full width]

Sub AutoHideToggle()
Static aTemp As WindowConfiguration = Nothing
Dim cmdobj As Command
' Create a variable to hold the AutoHideAll command.
cmdobj = DTE.Commands.Item("Window.AutoHideAll")
With DTE.WindowConfigurations
' Check if whether we're using our temporary configuration.

' If we aren't create one and save it out.
If aTemp Is Nothing Then
' If we're not in the aTemp config, create a new
' aTemp and apply it to save it.
aTemp = .Add("aTemp")
aTemp.Apply()
' Call AutoHideAll.
DTE.Commands.Raise(cmdobj.Guid, cmdobj.ID, Nothing,
Nothing)
Else
' The second time this is run,
the windows are put back
' the way they were the first time it was run.
aTemp.Apply()
aTemp = Nothing
End If
End With
End Sub


When you run this macro, you'll notice that it works but that it might be too painfully slow to use. (Then again, it's no slower than getting things back together by hand, so go ahead and use it if you feel so inclined.) What it's doing is loading the configuration profile a number of times (whenever the Apply method is called). In Chapter 4 we'll show you how to speed up this little macro by turning it into an add-in. Chapter 3 provides some techniques you can use to make this macro accessible through a menu command or a keyboard shortcut.

The Help Filter setting lets you filter the information that the Visual Studio .NET Help system presents to you by default as you work. If you're a specific type of developer, such as an MFC or ATL C++ programmer, you can save some time and clock cycles by having Visual Studio .NET filter the Help to the main topics you're interested in. The Help Filter setting affects the Filtered By combo box in the Search window, making what you set on the My Profile tab the default. We'll explain how you can create your own custom Help filters in Chapter 14.

The final option on the My Profile page sets the way that Visual Studio .NET opens when you run the program. If you set At Startup to Show Start Page (the default), you'll get the Get Started tab on the Start page when the IDE loads. The Start Page offers some compelling features, but it's not everyone's cup of tea. Keep in mind that this option is enabled in every profile and that if you want to change how the IDE loads, you must set this option separately.

The Editor


In talking with members of the team that developed the base editor in Visual Studio .NET, it's clear that they understand that programmers live in the editor. It's where the most important programming work is done. To this end, the Visual Studio .NET team worked hard to create a code editor that's on par with the best commercial and free editors available today. To a great extent, they have succeeded in this goal, largely due to new enhancements to the macros facility. These enhancements include an extremely powerful extensibility model, a new macro recording facility, and a dedicated Macros IDE. The Visual Studio .NET extensibility model is a major focus of the book because it's what we use to customize and to add functionality to the IDE.

Other new features in the editor include outlining, line numbering, and a really outstanding search and replace facility, all of which are discussed in detail in Chapter 3.

Designers


Visual Studio .NET offers four major types of designers: Windows Forms designers, which let you create Windows Forms applications visually; Web Forms designers, which help you create WYSIWYG ASP.NET Web Forms applications; the Component Designer, which is used to build server-side components for enterprise solutions; and the XML Designer, which makes it easy for programmers to work with XML Schema Definition (XSD) files.

In Visual Studio .NET 2003, all languages provide designers for .NET application creation. This means that you can design your Windows Forms and Web Forms in the same language you use to write your most important algorithms. In the past, it was common for developers to create the front end of their application using a visual tool such as Visual Basic and to write the back end in Visual C++. Because of the way that .NET assemblies interoperate, you're still free to do your forms layout and library writing in different languages, but you're no longer forced to work that way.

Tool Windows


Tool windows are the nondocument windows in the IDE that provide you with information and utility functionality as you work. The IDE has a large number of tool windows, and you can access them easily using keyboard shortcuts, the Command Window, and menu commands. The following are the most commonly used tool windows in Visual Studio .NET. These tool windows are presented with their associated default keyboard shortcuts.

Solution Explorer (Ctrl+Alt+L)


The Solution Explorer window is arguably the most important tool window in Visual Studio .NET. In Visual Studio .NET, nearly all the work done by a programmer revolves around a solution. A solution is a collection of projects, which are themselves collections of files. It's through Solution Explorer that you'll get access to the files in your projects. Here you'll add new classes and files to projects, and even new projects to larger solutions. Figure 1-5 shows a project in the Solution Explorer tool window.


Figure 1-5. A managed project in Solution Explorer



Class View (Ctrl+Shift+C)


The Class View window provides you with a hierarchical view of the classes in your solution. If you're working with larger projects, you might find it easier to navigate your solutions using Class View than using Solution Explorer. Figure 1-6 shows the extensibility solution from Figure 1-5 in Class View.


Figure 1-6. The Class View window gives you an alternative view of the objects in your solution.



Properties window (F4)


In the Properties window, you can get and set properties for the user interface items that you add to Windows Forms and Web Forms applications. You can also use this window to set properties for solutions, projects, and files that you have selected in Solution Explorer. Figure 1-7 shows the Properties window for a setup project that's part of an extensibility solution.


Figure 1-7. You can use the Properties window to set properties of components, projects, and solutions.



Server Explorer (Ctrl+Alt+S)


You use the Server Explorer tool window to access data sources and information on your local machine and on remote servers. Through this window, you can make data connections, access performance counters and event logs, and even manage system services. Even when used locally, this tool can save you a ton of time, letting you easily start and stop system services that you're testing and access system logs. In Figure 1-8, you can see two machines available in Server Explorer. The first machine is the local machine on which Visual Studio .NET is running. The second machine is a remote test server.

Note

Keep in mind that you'll need the proper level of access on a particular server to access system information.


Figure 1-8. The Server Explorer window provides you with remote access to the machines you're working with.



Toolbox (Ctrl+Alt+X)


For the most part, the Visual Studio .NET Toolbox window is used to hold the controls that you add to your Windows Forms and Web Forms applications. That part is probably fairly familiar to you. What you might not be aware of is that you can use the Toolbox to hold code fragments that you use frequently or fragments you want to keep as you read through the Help files or Web pages. The Clipboard Ring makes it possible for you to go back and access previously copied text. You can add your own custom tabs to the Toolbox to help organize your code and controls. You can see a custom tab in the Toolbox in Figure 1-9. This tab is installed by the Visual Studio .NET guided tour (available from http://msdn.microsoft.com/vstudio/productinfo/tour.asp).


Figure 1-9. The Toolbox window gives you access to controls and code snippets.



Command Window (Ctrl+Alt+A)


The Command Window is a new feature of Visual Studio .NET. It combines some of the best features of the Immediate window from Visual Basic with the power of a command line. Chapter 2 covers the Command Window in detail. You use the Command Window to enter and execute named commands directly in Visual Studio .NET. A named command is essentially any IDE command that you can run through a menu, toolbar button, or shortcut. Many of the named commands in Visual Studio .NET aren't mapped to a keystroke or available through a menu by default. The only way to access these commands without mapping them or adding them to a toolbar is to type them directly into the Command Window.

The Command Window has two modes of operation. In Command mode, the window acts as a command-line tool. In Immediate mode, the Command Window is used for debugging. In Immediate mode, you can execute statements, change variables and print their values, and evaluate expressions. To get to Immediate mode from Command mode, type immed. To get to Command mode from Immediate mode, type >cmd.

Tip

In Command mode, the > prompt will be visible on the line where you're typing in your commands. Immediate mode shows no prompt.

Figure 1-10 shows the Command Window in Command mode.


Figure 1-10. The Command Window in Visual Studio .NET provides easy access to named commands in the IDE.



Macro Explorer (Alt+F8)


The Macro Explorer window provides a view of the macro projects that are currently loaded in the IDE. Keep in mind that a macro project needs to be loaded in order for the macros in the project to be available for use or for editing in the Macros IDE.

When you record a temporary macro by pressing Ctrl+Shift+R, that macro becomes available through the MyMacros\Recording Module\TemporaryMacro item in Macro Explorer. You can rename the temporary macro to save it, or you can copy the code from the macro into another module in the Macros IDE. We'll discuss using recorded macros in more detail in Chapter 4. The Macro Explorer window is shown in Figure 1-11.


Figure 1-11. Macro Explorer gives you easy access to the macros available for use.



The IDE has a number of other important windows, which we'll talk about more fully in the next couple of chapters. Among these are the various debugging windows, the Help windows, and the Object Browser.


Visual Studio .NET File Paths


In this section, we'll tell you a little bit about where Visual Studio .NET places its important files. We'll cover this subject in more detail throughout the book, where it applies, but for now you should be aware of the locations of the files that you can manipulate to enhance the IDE and make automation a bit easier. The default base folder for the Visual Studio .NET 2003 installation is \Program Files\Microsoft Visual Studio .NET 2003. Most of the folders we'll talk about in this section are subfolders under the Microsoft Visual Studio .NET 2003 folder (unless we provide the full path).

Installing Visual Studio .NET also installs the .NET Framework SDK in the SDK\v1.1 subfolder. All the .NET Framework tools and samples are available in this folder, so it's a good place to start digging around if you're just getting to know .NET. Check out the StartHere file in the SDK\v1.1 folder for the full story on the .NET Framework SDK.

The various languages that ship with Visual Studio .NET all have their own subfolders that contain the project and solution templates for their respective project types. These folders are all named appropriately. Visual C++specific files are found in VC7, C#-specific files are in VC#, and Visual Basic .NET files are in Vb7. We'll use these folders to create and add custom projects to the various languages in the IDE.

Tip

You'll notice a file named Samples.vsmacros in the IDE folder. The sample macros for Visual Studio .NET that run in your IDE are actually stored in your My Documents\Visual Studio Project\VSMacros folder. The version in the IDE folder is a backup copy. You can edit the Samples.vsmacros file in your My Documents\Visual Studio Project\VSMacros\Samples folder, but try to keep the version in your IDE folder clean. If you ever run into a macro corruption problem, you can usually copy the Samples.vsmacros file from your IDE folder to your VSMacros folder to get rid of the problem.

The IDE executable itself is Devenv.exe. This file is available in the Common7\IDE subfolder. The IDE folder contains a number of subfolders that you'll be using throughout the book. These folders include the PublicAssemblies and PrivateAssemblies folders, which you'll use to add custom assemblies that are available to macros in the IDE. You'll use the HTML folder to customize the Start Page. The templates for the macro projects are stored in the MacroProjectItems and MacroProjects folders. Generic item templates (those not associated with a particular project type) are stored in the NewFileItems and NewScriptItems folders.


Adding an IDE Folder Shortcut to Your Tools Menu


If you do a lot of extensibility work, you might want to add a shortcut to the IDE folder to your Visual Studio .NET Tools menu. To do this, follow these steps:

Press Ctrl+Alt+A to open the Command Window, and then type Tools.ExternalTools. This will open the External Tools dialog box.

Click Add to add a new tool to the menu, and type IDE Folder as the Title.

In the Command text box, type Explorer.exe.

In the Arguments text box, add the path to your Visual Studio .NET IDE subfolder. (This is usually C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE.)

Click OK.


If all that works, your IDE folder should open when you choose IDE Folder from the Tools menu. We'll use the External Tools feature to create some more time-saving shortcuts later in the book.

If you do command-line builds or if you simply like to work from the command line, you'll want to set environmental variables for Visual Studio .NET when you launch Cmd.exe. You have a couple of options for setting these variables. First, you can simply open the Start menu and choose the Visual Studio .NET Command Prompt. You'll find that command prompt in the Visual Studio .NET Tools folder, which is in the Microsoft Visual Studio .NET 2003 folder.

Tip

We suggest pinning the Visual Studio .NET Command Prompt link to the Start menu so you'll have easy access to it as your primary command prompt.

The Visual Studio environmental variables are available in a file named vsvars32.bat, which is in the Common7\Tools subfolder. If you want access to these variables from every instance of Cmd.exe on your machine, you can add C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools to your system path. (Alternatively, you can copy this file to a folder in your path.) Then you can just type vsvars32 from any command prompt and you'll have a Visual Studio .NET working environment from your current command prompt.

You can take this one step further by creating a Command item on the Tools menu. You create a new menu item from the External Tools dialog box by clicking Add, making the Title of the new item Command Prompt, and making the Command item cmd.exe. If you want, you can set the Initial Directory box to $(ProjectDir). Setting the Initial Directory to your project directory will open the command prompt to that directory. This can make it very convenient to work with your project files from the command line.

Finally, consider adding the Common7\IDE path to your system variables. The full path is C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE. This will make Devenv.exe available from any command prompt on your system. This path is added by the vsvars32.bat command, but sometimes you just need access to Devenv.exe.

Tip

Consider using Devenv over Notepad when you're editing files for command-line builds. Even though you might not get access to the build and project facility without a solution, you still have access to your custom tools and to your macros.


/ 118