Introduction to Visual Studio 2010

April 15, 2016 | Author: Lionel Carroll | Category: N/A
Share Embed Donate


Short Description

Download Introduction to Visual Studio 2010...

Description

Introduction to Visual Studio 2010  

Introduction If you haven’t used Microsoft Visual Studio before, then this tutorial is for you. It will walk you through  the major features of Visual Studio 2010 and get you started with creating various types of Synergy .NET  applications. You will also learn useful tips and techniques that can save you valuable time while  programming within Visual Studio. 

Tutorial Setup No specific preparation is needed in order to complete this tutorial. 

Tutorial Steps Starting Visual Studio Before we can get started, if it’s not already running, we need to start Microsoft Visual Studio 2010. 



From the Windows Start Menu, select All Programs > Microsoft Visual Studio 2010 > Microsoft  Visual Studio 2010. 

Once Visual Studio has finished loading, you should be looking at a screen called the Start Page. This  screen allows you to easily create a new development project, or open an existing one, and open  recently used projects. On the right side of the Start Page Visual Studio presents all kinds of information,  the content of which is also customized to the type of environment that you select (we’ll talk about this  more in a moment). This information can include news and announcements, technical information, and  lots of other types of content. The Start Page is often overlooked by developers, but when you are  learning Visual Studio and .NET development it can be a valuable source of information.  The Start Page closes when you create or open a development project, but you can return to it at any  time by selecting View > Start Page from the menu.  Many things in Visual Studio are customizable, so to help to ensure that you are able to complete this  tutorial, we’re going to reset all Visual Studio settings to default values. In fact, there are multiple sets of  default values, as you will see shortly. There are default settings based on the some of the available  programming languages, defaults for types of development (e.g., web development) and various other  scenarios.  The first time you start Visual Studio after installing it, you will be asked to select which default  configuration you wish to use. Many people select General Development Settings for an initial  configuration well suited to multiple languages and various types of development projects.  It is also possible to switch Visual Studio to a different collection of settings at any time, and also to save  and restore custom settings. 

Introduction to Visual Studio 2010  

Page 1

Introduction to Visual Studio 2010  

Reset to Default Settings

□ □ □ □ □ □

From the menu, select Tools > Import and Export Settings.  Select the Reset All Settings radio button, and then click the Next button.  On the “Save Current Settings” page, check that Yes, save my current settings is selected (to  save a backup so that you may restore your current settings after completing this tutorial, if  required) and then click the Next button.  On the “Choose a Default Collection of Settings” page, Select General Development Settings  Click the Finish button  When you see the “Reset Complete” screen, click the Close button. 

Selecting one of these pre‐defined collections of default settings can make many changes to your  environment. Things that are commonly changed include menu items, menu item shortcuts, toolbars,  and more. 

Creating a New Project One of the first things you’re likely to want to do is create a new development project, so let’s do that  now. As with many things in Visual Studio, there are often several ways to do something. For example,  to create a new development project you can:     



On the Start Page, click the New Project… link.  Select File > New  > Project… from the menu.  Click the New Project button on the toolbar.  Type Ctrl+Shift+N.    On the Start Page, click on the New Project… link. 

You will notice that the New Project dialog is divided into several main parts. On the left is a tree view  where you can select from various project categories and sub‐categories, many of them based on the  programming language that you wish to use. When you select a category, the center part of the dialog  displays a list of project templates that belong to the category that you have selected. When you select  a project template, a brief description of the project created by the template is displayed at the right of  the dialog. Finally the lower portion of the dialog allows you to pick the location where you would like  the project to be created, and specify a name for your new project.  The project name that you pick is used in many ways, depending on the type of project you are creating.  Generally the project name will be used to determine things like:     

The name of the “Solution” that is created (more about this in a moment).  The name of the project that is created. 

Introduction to Visual Studio 2010  

Page 2

Introduction to Visual Studio 2010     

The name of the folder that the project will be created in.  The name of the main “assembly” (program or library) that will be created by the project.  The name of the “default namespace” that will be used when some types of item are added to  the project.  

Of course, even after a project has been created, all or any of these things can be changed, but some are  harder to change than others. It’s best to put some thought into the name of your project before you  create it. 

□ □ □ □ □

In the templates tree (left) expand the Synergy/DE category, and then select Windows.  In the project templates list (center) select Windows Forms Application.  In the Name field, enter IntroToVisualStudio.  Decide on a folder to create your project in, and enter its name in the Location field.  Ensure that the Create directory for solution checkbox IS checked . 

In Visual Studio, one or more projects may exist within a Solution. Every project will have some type of  output, usually an assembly, either a program (.exe) or library (.dll). Projects make up the various parts  of an application. A Solution is merely a collection of projects, providing a way for developers to move  around the various parts of their application easily. Every project must exist within a solution, and a  solution can contain multiple projects.  When you create a new project in Visual Studio by one of the mechanisms that we discussed earlier,  Visual Studio will also create a Solution. If the “Create directory for solution” box is not checked, then  the solution file is named the same as the project being created, and is created in the same folder as the  project. This is generally appropriate if you only plan on working with one project in the solution.  If the “Create directory for solution” box is checked, then Visual Studio will create a folder for the  solution (below the location that you specify) and save the solution file in that folder. Then a second  folder, for the project, will be created below the solution folder, and all of the project files will be  created in or below the project folder. This is appropriate when you intend to add several projects to a  solution, as each project will be stored in its own folder below the main solution folder. You’ll also notice  that in this case you are able to specify a different name for the solution itself. 



Click on the OK button to create your new solution and project. Because of the virtual machine,  creating and opening the solution and project may take a few seconds. 

Different project templates cause different things to happen when a new project is created. For a  Windows Forms project, what generally happens is the solution and project, and various default project  files are displayed in the Solution Explorer towards the top right of the screen, the visual design surface  for the default form that was added to the project is displayed filling most of the screen, and the  Properties window is displayed towards the bottom right of the screen.  Introduction to Visual Studio 2010  

Page 3

Introduction to Visual Studio 2010  

Solution Explorer The Solution Explorer window is a key part of Visual Studio, and is  frequently used by developers. It allows you to navigate around the various  files and other items that make up your projects and your solution.  Generally, double‐clicking on a file will open that file, either in a text editor  or perhaps some kind of visual design surface. Some files can be edited in  various ways. For example, you will notice that when the project was  created, the file Form1.dbl was automatically created, added to the project,  and opened in design view. But there is another way of working with  Form1.dbl, in a source code editor. To see this in action: 



In Solution Explorer, right‐click Form1.dbl and select View Code. 

When working with pieces of a UI it is common to work with these two  views of a given source file, the design view and the code view. 



Right‐click Form1.dbl again and this time select View Designer. 

You may have noticed that once a file (or a view of a file) is opened, it remains open until you specifically  close it. Each file is assigned a tab towards the top of the main work area, which looks like this:    You can use these tabs to switch between the views of a file, or between multiple files that you have  opened. You’ll also notice an X to the right of each tab, which can be used to close that file or view.   You may sometimes see red dots next the file name on a tab. This is an indication that the file has been  modified and needs to be saved. Visual Studio will automatically save files when you build or run, and  there are also various ways to manually save one or more files. The easiest way to manually save files is  to use the Ctrl+S shortcut to save the current file, or the Ctrl+Shift+S shortcut to save all changed files.  It is easy to change the layout of the UI in Visual Studio, where most things can be repositioned, docked,  stacked in tab sets, and hidden away at will. If at any time you can’t find Solution Explorer you can  always make it visible by selecting View > Solution Explorer from the menu, or by using the keyboard  shortcut Ctrl+Alt+L.   



Introduction to Visual Studio 2010  

Page 4

Introduction to Visual Studio 2010  

Visual Design Surfaces Many things that you work with in Visual Studio have visual design  surfaces. Certainly it is common to work with a visual design surface  when building a user interface, but several other things have them  also. As the name suggests, a visual design surface allows you to  design something visually, often by dragging items from a palette of  available “things” and arranging them on the design surface.   Right now we are creating a Windows Forms application, so we  have access to a wide variety of components that can be used to  build a Windows user interface. These components include things  like the TextBox, CheckBox and Button controls that you’re  probably familiar with. These controls are located in the Toolbox  (more in a moment) and can be dragged to the visual design  surface as needed.  By the way, the same concept also applies when working with other types of application. As well as with  traditional Windows Forms applications, developers commonly work with visual design surfaces and  toolboxes when developing Windows Presentation Foundation (WPF) applications, ASP.NET Web  applications, Silverlight applications, and others. 

The Toolbox The Toolbox may not be visible right now, but if not look down the left  hand side of the Visual Studio window and you may see a vertical tab that  says Toolbox. 

□ □

If you don’t see the Toolbox Window then select View > Toolbox  from the menu (or type Ctrl+Alt+X).    With the Toolbox visible, click on the small   icon at the top right  of the Toolbox window to “pin” the window in place. 

Pinning a window provides a mechanism to ensure that it remains on the  screen. Most windows, when unpinned, slide out of sight but leave behind  a tab so that you can access the window again. Hovering the mouse over  the one of these tabs will make the window appear so that you can access  it, or pin it in place. 

□ □

Make sure that the design view of Form1.dbl is visible.  In the Toolbox, go to the Common Controls group, then click once  on and drag a Button control to the design surface. 

Introduction to Visual Studio 2010  

Page 5

Introduction to Visual Studio 2010   You will notice that when the button is created on the form, several white “handles” appear around the  outside of the button. These handles perform two functions; they indicate which item is currently  selected to be worked with, and they can be used to resize the selected item. 

□ □

Single‐click the body of the form (not on the button) and you will see that the handles move to  the form, which is now selected to be worked on.  Single‐click on the button again, the handles move back to the button. 

As you click between these two items, look to the lower right portion of the screen. You should see a  window called Properties, and you should see the content of the window change as you select different  items on a visual design surface. 

□ □

If you can’t see the properties window, select View > Properties Window from the menu, or use  the F4 keyboard shortcut.  If necessary, pin the properties window in place. 

Properties Window The properties window is another key part of Visual Studio where, if you’re developing a user interface  at least, you are likely to spend a lot of time.  Essentially each item that you work with (buttons, textboxes,  checkboxes, etc.) have properties, sometimes hundreds of them,  and the properties window allows you to inspect and change the  values of these properties, in order to achieve the desired  functionality within your application.  Notice the mini toolbar at the top of the properties window; in fact  many of Visual Studio’s windows have a similar toolbar, which  generally allows you to view the information in the window in  various ways. For example, the properties window is currently  grouping the various properties of the selected button control by  type (Accessibility, Appearance, etc.) because the first button ( on the toolbar is selected. 



Click on the second icon (



) to order the properties alphabetically. 

Notice that the properties window also has a drop‐down list (at the top) which shows you which item is  currently selected. Another way of changing the selected item is to drop down this list and select a  different item. 



Drop‐down the list at the top of the properties window and select Form1. 

Introduction to Visual Studio 2010  

Page 6

Introduction to Visual Studio 2010   Notice how the selected item handles moved from the button to the form, and how the content of the  properties window changed to reflect the properties of the newly selected item. 

□ □

On Form1’s design view, select the form.  In the properties window, Locate the Text property and set the value to My Form. 

A Windows Form’s text property is used to set the title of the window; notice how the text that you  typed is now also displayed in the title area of the form designer. Some changes that you make in the  properties window are reflected visually in the designer.  In some cases, the opposite is also true. For example: 

□ □ □ □

With the form selected, locate the Size property. It may be easier to switch to alphabetic mode  (toolbar at top of properties window).  Notice the current value of the size property; probably the default 300, 300  Now use the designer’s current item handles to visually resize the form.  Check the Size property again, it should have changed. 

So, making changes in the properties window often visually changes the designer window, and making  changes in the designer window also changes the properties window.  Another thing to notice with respect to the properties window is how properties that have not been  changed (i.e., currently have a default value) are displayed in normal text, whereas properties that have  had their value changed are displayed in bold text. This visual indication of what properties have been  changed can be very useful.   So, we’ve discovered that we can change the properties of something either graphically in a design view,  or via the properties window, but where is all of that information stored? The answer to that depends  on what type of project you are working on. Some common examples are:  Project Type 

Designer / Properties Changes Written To 

Windows Forms 

A “designer” programming language source file. 

Web Forms (ASP.NET) 

The main web page file (.aspx) in HTML format. 

Windows Presentation  Foundation 

The main form or control file (.xaml) in XAML format. 

Silverlight 

The main form or control file (.xaml) in XAML format. 

Other 

Various, generally a programming language source file. 

  Introduction to Visual Studio 2010  

Page 7

Introduction to Visual Studio 2010  

Designer Source Files To help you to understand what is happening when you interact with a visual design surface or with the  properties window, let’s dig a little deeper into our simple application. 



In Solution Explorer, expand the Form1.dbl item. 

You will notice that below Form1.dbl are two other files, called Form1.designer.dbl and Form1.resx. By  the way, these particular files are specific to a Windows Form, but the general principle of what we’re  looking at here applies in a number of different scenarios.  For now, the file that we are most concerned with is the Form1.desidner.dbl file. This is a special source  file that is altered whenever you make changes to a Windows Form’s visual design surface or Properties  window.  WARNING: As a general rule, you should not edit “.designer” files. They are created and maintained by  Visual Studio visual designers and the Properties window. It is relatively easy to break your application  by making inappropriate changes to these files, and it can be difficult to resolve problems like this.  With the warning out of the way … let’s edit the file! 



In Solution Explorer, double‐click on Form1.designer.dbl to open it in code view (you could also  right‐click the file and select either Open or View Code). 

Right now the designer source file is fairly simple, because all we have is a form and a button. Notice  how the “class” Form1 “extends” (is a) System.Windows.Forms.Form, and how the class contains an  instance variable called button1 which is of type System.Windows.Forms.Button. That variable was  created, by the designer, when we dragged the button onto the form.  Look down a little and you will see that there is a method called InitializeComponent, and in that  method there are various assignment statements which set various properties of the button  (this.button.something) and the form its self (this.something). These lines of code are inserted when we  make changes to the properties of the form, or objects “on” the form, either via changes that we make  on the graphical design surface, or changes that we make in the Properties window.  You may also notice that the code in this file defines the class as “public partial class Form1”. 



Click on the tab at the top of the edit area called Form1.dbl. If you closed this view then in  Solution Explorer, right‐click on Form1.dbl and select View Code. 

Notice that the class in this source file is also defined as “public partial class Form1”. A partial class is a  class composed from partial class definitions in multiple source files, so in this case the class Form1 is  made up of source code in the file Form1.dbl, which the developer controls, and code in the file  Form1.designer.dbl, which the designer and properties window control. If you look at the default code  in Form1.dbl you will notice that there is a “constructor” method (public method Form1) which contains  Introduction to Visual Studio 2010  

Page 8

Introduction to Visual Studio 2010   a call to the InitializeComponent method which is in Form1.designer.dbl. So, when the application  creates an instance of the Form1 class, the designer‐generated code is executed to create and configure  all of the controls on the form. 

Program.dbl Projects which target an assembly which is an executable program (i.e., an .exe rather than a .dll)  include another source file, called Program.dbl. This is the “main‐line” or the “entry point” to the  application. 



In Solution Explorer, double‐click on the file Program.dbl to open it in the code editor. 

The default code in the Program.dbl file will vary, depending on the type of application, but tends to be  very simple in nature. In the case of a Windows Forms application, as you can see, the file contains a  main‐line program which essentially just launches a new instance of the default form, Form1.  If you were to rename the class in Form1.dbl (and of course the matching partial class in  Form1.designer.dbl) to a different name, or if you wanted to launch some other form at application  startup, then you would need to edit the code in Program.dbl as appropriate. 

The Properties Folder Each project that you create will include a folder called Properties, and depending on the type of  project, the folder will contain one or more files. 



In Solution Explorer, expand the Properties folder to view the files that it contains. 

In the Windows Forms project that you’re currently working in, there will be various files in the  Properties folder. These files are AssemblyInfo.dbl, Resources.resx and Settings.settings. Although you  can edit some of these files directly, and some of these file types also have visual designers associated  with them, the files in the Properties window are usually maintained via the Project Properties dialogs,  as you will see shortly. 

AssemblyInfo.dbl



In Solution Explorer, double‐click  AssemblyInfo.dbl  to open it in a code editor. 

AssemblyInfo.dbl contains various attribute definitions  used to embed information into the compiled assembly.  You can specify information about your company, the  name of the product, copyright information, etc.  The file can also be maintained via a dialog window  which can be accessed by opening the project 

Introduction to Visual Studio 2010  

Page 9

Introduction to Visual Studio 2010   properties, selecting the Application tab and clicking the Assembly Information… button. 

Resources.resx This file is a resource file which is a special type of file that can be used to embed various resources  (strings, images, audio files, etc.) the application might need, directly into the application’s assembly.  The benefit of using resource files is that any resources that the application needs do not need to be  provided as individual files on disk, which in turn can significantly simplify application deployment.  Resource files are actually XML files. The resources added to the file are serialized (if necessary) and  stored within the XML file. That being said, you will probably never deal with a resource file as an XML  file, because Visual Studio provides a graphical designer that lets you work with the contents of resource  files.  Resources in resource files are also very easy to use within the application, because the resource file  designer dynamically generates a class which represents the contents of the resource file. Accessing a  resource is as easy as referring to a static property in this class. 



In Solution Explorer, double‐click the Resources.resx file to open the resource file designer.   

  By default the resource file designer opens in Strings mode, but you can switch to working with Images,  Icons, Audio, Files or Other Items using the drop‐down field in the top‐left corner of the resource  designer. You will also notice that there are buttons on the toolbar which allow you to add and remove  items from the resource file.  Let’s work through a simple example of adding a string resource to a project: 

□ □ □ □

In the Name column, where it defaults to String1, change the resource name to  WelcomeMessage.  In the Value column add the text Welcome to my application.  In the Comment column add the text Displayed at application startup.  Type Ctrl+S to save your changes. 

Now let’s take a look at what we actually did with the resource designer. 



In Solution Explorer, right‐click on Resources.resx and select View Code. 

Introduction to Visual Studio 2010  

Page 10

Introduction to Visual Studio 2010   The XML file that you are looking at is the actual resource file. If you scroll to the bottom of the file you  will see the resource that you just added via the designer. 

□ □

Close the XML view of the resource file.  In Solution Explorer, expand the view of the file Resources.resx 

Like forms that we discussed earlier, resource files also have a designer source file, in this case  Resources.designer.dbl 



Double‐click on Resources.designer.dbl to open it in the source code editor. 

As you interact with a resource file through the designer, Visual Studio generates the code in the  designer source file. As you can see, the source file contains a sub‐namespace called Properties (the  name of the folder) containing a class named Resources (the name of the resource file).  



Scroll down to the bottom of the source file. 

As you can see, the string resource that you added has been exposed as an internal static property. This  means that we can refer to the value of the string resource from anywhere in the project (assembly) like  this: 

Properties.Resources.WelcomeMessage 

 



Close the source file by clicking on the close (cross) icon in its main tab. 

Let’s add some code to the application to make use of the resource string that we just added: 

□ □ □

In Solution Explorer, double‐click on the file Form1.dbl to open its visual designer.  Double‐click somewhere in the body of the form to open the code editor window.  Place your cursor in the procedure division of the Form1_Load method and add the following  code: 

this.Text = Properties.Resources.WelcomeMessage 

 

 



Type Ctrl + F5 to save your changes, and to build and run the application. 

You should see the text that you entered in the resource file now displayed in the application drag bar. 

□ □

Close the application.  Close the Resources.resx file by clicking on the X icon in its main tab. 

Introduction to Visual Studio 2010  

Page 11

Introduction to Visual Studio 2010  

Settings.settings Conceptually the settings file is similar to a resource file. However, where a resource file is intended to  store resources like images, sounds and strings that are used by an application, the settings file is  intended to store application or user settings. A setting is a name / value pair, and you can specify the  data type of the value. 



In Solution Explorer, double‐click on the Settings.settings file to open the settings file designer. 

  Settings files also have a .designer.dbl file, and just like with resource files the settings designer  dynamically generates a class called Settings, with public properties to represent the settings that you  have defined in the designer. This means that you can programmatically access the settings with code  like this: 

Properties.Settings.Default.AutoLogin   

Default values for the settings that you define are stored in the .settings (XML) file.   



Close the Settings.settings designer by clicking on the X icon in its main tab. 

The References Folder



In Solution Explorer, expand the References folder. 

All Visual Studio development projects will include a special folder called References. The folder doesn’t  contain files, but rather contains a list of assemblies that are accessible from the code within your  application. If you want to access types that are stored in a particular assembly, you add a reference to  the assembly. We’ll look at how to do that shortly.  When you create a new project from a project template, the template will probably include a set of pre‐ configured references. Some of these references may be required because of existing code that has  already been included in the project by the template, while others may have been included simply  because you are likely to need them when developing a particular type of application. 



In Solution Explorer, right‐click on the References folder and select Add Reference… 

Introduction to Visual Studio 2010  

Page 12

Introduction to Visual Studio 2010   The Add Reference dialog allows you to browse assemblies that are available to be referenced by your  project.   There are five tabs at the top of the dialog, as follows:  .NET 

Lists all .NET Framework components available for referencing, as well as assemblies  from third parties that have been registered on your system. 

COM 

Lists all COM components available for referencing and use through .NET’s COM interop  capabilities. 

Projects 

Lists Visual Studio projects in the current solution available for referencing. Select  assemblies from this tab to create project‐to‐project references. 

Browse 

Allows you browse additional files to find a component not listed in the current tab and  add it to the list. 

Recent 

Displays recently added references. 

As an example of adding a reference to a project, to make types (classes, etc.) that are available in a  particular assembly available for use in the project, let’s assume we want to have the ability to expose a  WCF service from our application. To do that you would need to use several classes that are provided by  the .NET Framework in the System.ServiceModel namespace.  

□ □

In the .NET tab, click the Component Name column title to sort the list of assemblies in  alphabetical order, and then locate and select the System.ServiceModel assembly.  Click the OK button to add the reference. 

You should now see System.ServiceModel listed under the References folder in your project, meaning  that whatever types are defined in that assembly are now available for you to use in your code. 

Object Browser Visual Studio’s Object Browser window allows you to browse and view the content of assemblies. 



In Solution Explorer, double‐click on the System.ServiceModel reference that you just added. 

You should see the Object Explorer window open, and the System.ServiceModel assembly should be  selected in the list of assemblies to the left side of the screen. Similar to the .NET tab in the add  reference dialog, this list shows assemblies that are provided by the .NET Framework as well as other  assemblies that you may have referenced in your project. At the top of the dialog is a toolbar with a  drop‐down list which allows you to apply filters to the list of assemblies that are displayed. 



In the Browse drop‐down list, select .NET Framework 4 to filter the list of assemblies to only  those assemblies available in that version of the .NET Framework. 

Introduction to Visual Studio 2010  

Page 13

Introduction to Visual Studio 2010  



Click the small triangle icon next to the System.ServiceModel assembly. 

Assemblies can contain types (classes, etc.) from one or more namespaces. When you drill into an  assembly in Object Browser, the first thing you see is the namespaces that are present in the assembly: 

  Above you can see that the System.ServiceModel assembly contains types from multiple namespaces.  Note that the types in a namespace don’t have to be all defined in one assembly. For example, you can  see that this namespace contains some types from the System namespace, but there will be types from  the same namespace in other assemblies too. 



Click the triangle icon next to the System.ServiceModel namespace to drill into it. 

  Drilling into a namespace displays the types that are present in that namespace. The nature of the type  is indicated by the icon displayed next to it. For example, in the diagram above,  ActionNotSupportedException is a class while AuditLevel is an enumeration. 



Single‐click on the class BasicHttpBinding to select it. 

  In the upper‐right section of the Object Browser window you can see more detail about the type that  you have selected, and again the icon next to each item indicates the nature of the item. In the case of  the BasicHttpBinding class, you will see that the class has several methods, one of which is called  CreateBindingElements(), and also several properties, including BypassProxyOnLocal. 



Single‐click on the CreateBindingElements method to select it. 

Introduction to Visual Studio 2010  

Page 14

Introduction to Visual Studio 2010   In the lower‐right portion of the Object Browser window you can see even more information about the  thing that you have selected above. 

  In this case the information is telling us about the method that we selected. We can see that it is a public  method, so it’s available for us to call, it does not have any parameters (nothing is listed between the  parentheses following the method name) and it returns a BindingElementCollection. There is also useful  descriptive information about what the method does, any parameters it might accept, and the return  value.  You may also notice that other types that are mentioned here appear to be hyperlinks, and sure enough  clicking on one of them will take you to the documentation for that type in Object Browser. There are  also forward and back buttons on the toolbar to make navigating around easy, just like in a web  browser.  You can also use Object Browser to add references to your project. For example, let’s suppose that by  browsing around in Object Browser we determined that we need a reference to the  System.ServiceModel.Activation assembly. 

□ □

In Object Browser select the System.ServiceModel.Activation assembly  In Object Browser toolbar, click the Add to References in Selected Project in Solution Explorer  button. 

Object Browser can be very useful. If you have an idea about what you need then it can allow you to  easily browse detailed information about things, and, having confirmed what you need, you can add a  reference to the required assembly.  Object browser is also a great way to learn about the capabilities of things, because it makes it easy to  view detailed information about methods, parameters, return values, enumerations, and lots of other  things. 

□  

Close Object Browser by clicking on the cross icon in its main tab. 



Introduction to Visual Studio 2010  

Page 15

Introduction to Visual Studio 2010  

Project Properties Each project that you create includes many options which allow you to define lots of different things.  These options, more commonly referred to as project properties, all have default values and can be  customized through the “Project Properties” dialogs. 



In Solution Explorer, right‐click on the IntroToVisualStudio project (it’ll be shown in bold text  immediately below the solution) and from the context menu select Properties. 

The project properties dialog has various tabs down the left hand side. 



Check that the Application tab is selected. 

Let’s take a look through the various tab pages and explore what options are available to you. There are  lots of options, so we’ll just pick out some of the more important ones.  Application The tabs that are displayed will vary based on the type of application that you are working on. We’re  currently working on a Windows Forms Application, so you should see tabs that look something like this: 

  Most projects create one assembly, and that assembly can either be an executable program or a class  library. The assembly name and output type fields determine the name of the assembly that is created  by the project, with the output type being used to determine the file extension (.exe or .dll).  The default namespace determines the namespace that is inserted into any new source files that are  added to the project. When using most project templates, the assembly name and default namespace  default to the name of the project that you create, and by the time a new project has been created, the  default namespace will already have been used in whatever source files are added to the project by the  project template. So, if you change the default namespace you will usually want to review any existing  source files in the project and change the namespace used in those files.  Introduction to Visual Studio 2010  

Page 16

Introduction to Visual Studio 2010   The assembly information file (AssemblyInfo.dbl) was discussed earlier. You’ll notice the Assembly  Information… button that allows you to edit the content of the file through a simple user interface.  One of the most important settings for an application is the Target framework, which determines the  version of the .NET framework that the assembly will be built for. Synergy .NET projects will default to  either the .NET Framework 4.0, or the .NET Framework 4.0 Client Profile. The client profile is a smaller  version of the .NET Framework 4.0 which is commonly found on desktop PCs and laptops; it has some of  the features of the full framework removed. These features include things like the ASP.NET web  components which are typically only required on server systems. You can change the target framework  to an earlier version if you wish, which could for example help with deployment because most systems  will have V2.0 of the Framework already installed, but may not have 4.0. However by doing this you may  be restricting the capabilities of your application, because some features of the current .NET Framework  will not be available for you to use. A better approach is to target the latest version of the Framework,  and set up your deployment packages or procedures to install the latest Framework if required.  The Output type setting allows you to specify the type of assembly being created; either a Windows  Application, Console Application or Class Library. Generally this setting will be set correctly by the  project template that you use, and won’t need to be changed.  You can also set an application icon on this tab page. Doing so will cause the icon file to be added to the  project, and embedded as a resource in the target assembly. Selecting an application icon does not  cause that icon to be displayed at the top left of any forms that you may add to a project. If you want to  use the icon on forms then you must set each form’s Icon property also.  Build Events



Switch to the Build Events tab 

  The Build Events tab allows you to specify build configuration instructions. You can also specify the  conditions under which any post‐build events are run. Note the following: 

Introduction to Visual Studio 2010  

Page 17

Introduction to Visual Studio 2010      

Build events (specified in the Pre‐build event command line and Post‐build event command line  fields) can include any command that is valid at a command prompt or in a .bat file.  If you specify a .bat file, the name of the file should be preceded by "call" (without quotes) to  ensure that all subsequent commands are executed. For example: call C:\MyFile.bat.  The % character is reserved for MSBuild, so if you specify an environment variable, replace each  % with the %25 escape sequence. For example, replace %MY_VAR% with %25MY_VAR%25.  If your pre‐build or post‐build event does not complete successfully, you can terminate the build  by having your event action exit with a code other than zero (which indicates a successful  action). 

Compile



Switch to the Compile tab 

   On the compile tab you can determine which Synergy.NET compiler (dblnet) options are used when the  project is built. The Compiler command line box towards the top of the form displays a summary of the  actual command line options that will be used, and the other fields on the form allow you to determine  what those options should be. As you can see, there are some compiler options that are used by default.  There are specific UI controls on the form to allow you to set or unset some of the more commonly used  compiler options, and the Other options field allows you to specify any other compiler options that are  not specifically supported by controls on the form.  Environment Variables



Switch to the Environment Variables tab 

Introduction to Visual Studio 2010  

Page 18

Introduction to Visual Studio 2010  

  The environment variables tab allows you to specify environment variables that are to be set when the  project is opened. These environment variables will be in place during development in Visual Studio, and  also when you execute utilities or your application from the Visual Studio environment.  It is possible to refer to the translation of one environment in the value of another, using the syntax  $(ENVVAR). For example, if you had one environment variable called ROOT that translated to a folder  path, and you wanted to set another variable called DAT that translated to a folder called DAT below the  ROOT folder, you could express the value for the DAT environment variable as $(ROOT)DAT. This would  of course assume that the value of the ROOT variable was terminated with a trailing backslash character.  The environment within Visual Studio includes several pre‐defined macros that can be used when  setting environment variables. For example the macro $(SolutionDir) translates to the folder  specification of the current solution file, and $(ProjectDir) translates to the location of the current  project file, which may or may not be the same as the solution folder. As you can see in the screen‐shot  above, you can also refer to these macros when setting environment variables in your project. The table  below shows a list of some of the available macros:  Macro 

Translates To 

Example 

$(Configuration) 

The name of the current  project configuration. 

Debug 

$(OutDir) 

Path to the output file  directory relative to the  project directory. This path  should have a trailing slash.  This resolves to the value for  the Output Directory  property. 

bin\Debug\ 

$(ProjectDir) 

The directory of the project  (defined as drive + path); it 

c:\temp\MyTestApp\ 

Introduction to Visual Studio 2010  

Page 19

Introduction to Visual Studio 2010   includes the trailing  backslash.  $(ProjectExt) 

The file extension of the  project. It includes the '.'  before the file extension. 

.synproj 

$(ProjectFileName) 

The file name of the project  (defined as base name + file  extension). 

MyTestApp.synproj 

$(ProjectName) 

The base name of the project.  MyTestApp 

$(ProjectPath) 

The absolute path name of  the project (defined as drive  + path + base name + file  extension). 

c:\temp\MyTestApp\MyTestApp.synproj 

$(RootNameSpace) 

The namespace, if any,  containing the application. 

MyTestApp 

$(SolutionDir) 

The directory of the solution  (defined as drive + path); it  includes the trailing  backslash. 

c:\temp\MyTestApp\ 

$(SolutionExt) 

The file extension of the  project. It includes the '.'  before the file extension. 

.sln 

$(SolutionFileName) 

The file name of the solution  (defined as base name + file  extension). 

MyTestApp.sln 

$(SolutionName) 

The base name of the  solution. 

MyTestApp 

$(SolutionPath) 

The absolute path name of  the solution (defined as drive  + path + base name + file  extension). 

c:\temp\MyTestApp\MyTestApp.sln 

$(TargetDir) 

The directory of the primary  output file for the build  (defined as drive + path); it 

c:\temp\MyTestApp\bin\Debug\ 

Introduction to Visual Studio 2010  

Page 20

Introduction to Visual Studio 2010   includes the trailing  backslash.  $(TargetExt) 

The file extension of the  .exe  primary output file for the  build. It includes the '.' before  the file extension. 

$(TargetFileName) 

The file name of the primary  output file for the build  (defined as base name + file  extension). 

MyTestApp.exe 

$(TargetName) 

The base name of the  primary output file for the  build. 

MyTestApp 

$(TargetPath) 

The absolute path name of  the primary output file for  the build (defined as drive +  path + base name + file  extension). 

c:\temp\MyTestApp\bin\Debug\MyTestApp.exe 

Bear in mind that the environment variables that you specify through the project properties dialogs are  only present in your development environment. If you use this mechanism to specify values for  environment variables that are required at application runtime (outside of Visual Studio) then you must  provide those environment variables via some other mechanism.  Signing



Switch to the Signing tab 

  Introduction to Visual Studio 2010  

Page 21

Introduction to Visual Studio 2010   The signing tab allows you to specify that the assembly created by the project should be digitally signed.  To sign the assemblies, check the Sign the Assembly checkbox and then select the strong name key file  that you wish to use to sign the assembly.  Once you have enabled signing, there is an option in the Choose a strong name key file drop‐down list  which allows you to create a new key file. This is done using the .NET Framework’s strong name utility  (sn.exe).  We’re not going to get into assembly signing here because it’s a large and complex subject area, but it is  definitely something that you need to learn about before you release .NET applications to customers.  Reference Paths



Switch to the Reference Paths tab 

  The Reference Paths tab allows you to specify folders that will be searched when the project system  needs to locate a referenced assembly. When the project system finds an assembly reference, it resolves  the reference by looking in the following locations, in the following order:     

 

The project directory. The project directory files appear in Solution Explorer.  Directories specified on this page (Reference Paths).  Directories displaying files in the Add Reference dialog box.   The project's obj directory. (Assemblies created by adding COM references to your project are  added to the project's obj directory.) 

Introduction to Visual Studio 2010  

Page 22

Introduction to Visual Studio 2010   Build



Switch to the Build tab 

  The build tab allows you to specify various settings related to how your assembly is built. Each project  that you create includes several configurations and, when working in the project, you always have one  of these configurations selected. By default there is a drop‐down list on the main toolbar which allows  you to easily switch to a different configuration. Most projects have two initial configurations defined,  called Debug and Release, and the default is usually the Debug configuration.  At the top of the form you will see a drop‐down list which allows you to select the Configuration to  modify. Changes that you make in the lower half of the form are applied to that configuration. You need  to remember this because if you’re making a change to one configuration, then you may want to make  corresponding changes to other configurations also. In fact, if this is the case, you can select All  Configurations in the configuration dropdown list, and the changes that you make will then be applied  to all configurations. The Platform field is not used in Synergy .NET projects and should be ignored.  Platform target allows you to specify the processor to be targeted by the assembly. Select x86 to target  32‐bit platforms, select x64 to target 64‐bit platforms, or select Any CPU for the assembly to be platform  agnostic.   Output path allows you to determine where the assembly created by the project (or more specifically  the project configuration) will be stored. As you can see the default location is in a bin\Debug (or  bin\Release) folder below the project folder.  The XML documentation file option allows you to enable the creation of an XML file which contains API  documentation for the code in your project. The information in the file is derived both from the actual  code in the project, as well as from any documentation comments that you may have included in the  code. Once you have the XML documentation file there are several products on the market that can  transform the information in the file into various types of documentation.  The Debug/Optimize code option allows you to specify whether to use just‐in‐time (JIT) optimization,  and specifies the level of debug and stack trace information that will be available, which affects  performance. The option can be set to the following values:  Introduction to Visual Studio 2010  

Page 23

Introduction to Visual Studio 2010    

Includes less debug information in the assembly than is included by the Debug setting,  and only includes limited line number listings for trace‐backs, but includes more  information than the Optimize setting. This is the default setting for Release  configurations. 

Debug 

Full debugging information is included in the assembly. This is the default setting for  Debug configurations. 

Optimize 

Includes the least amount of debugging information in the assembly, resulting in the  best performance. Enables JIT optimization. This option is recommended for production  code. 

 The Generate serialization assembly option determines whether the compiler will use the XML  Serializer Generator Tool (sgen.exe) to create XML serialization assemblies. Serialization assemblies can  improve the startup performance of XmlSerializer if you have used that class to serialize types in your  code. The option can be set to one of the following values:  Auto  (default) 

Serialization assemblies will be generated only if you have used XmlSerializer to encode  types in your code to XML. 

Off 

Serialization assemblies will never be generated, regardless of whether your code uses  XmlSerializer. 

On 

Serialization assemblies will always be generated. 

It should be noted that due to a Visual Studio issue, setting the Generate serialization assembly to On  might not result in a serialization assembly, even if there are serializable types in the project. There is an  article on Microsoft Connect (bug id 123088) which discusses this issue. You can locate the article via an internet search for "Project Does Not Generate Serialization Assembly Even When  Specifically Told To Do So".  The DLL base address specifies the preferred base address at which to load the assembly. This can be  specified in decimal or hexadecimal format, and it must be 0x10000 aligned. The default base address  for a DLL is set by the .NET Framework common language runtime. Setting a DLL base address is an  advanced subject and is beyond the scope of this introductory tutorial.   



Introduction to Visual Studio 2010  

Page 24

Introduction to Visual Studio 2010   Debug



Switch to the Debug tab 

  The options on the Debug tab are used to set properties for the behavior of the project when the  debugger is started. As with the build options, it is possible to specify different debugger settings based  on the currently selected configuration, and again the Platform field is not used with Synergy .NET  projects and should be ignored.  The options under Start Action are used to set the item to be started when the debugging begins, and  can be set to one of the following:  Start project (default) 

Specifies that the executable for the project should be started when the  application is debugged. 

Start external program 

Specifies that some other executable is launched when the application is  debugged. Specify the full path to the executable to be started in the field  to the right, which is enabled when this option is selected. 

Start browser with URL 

Specifies that a URL should be accessed when the application is debugged.  Specify the URL in the field to the right, which becomes enabled when this  option is selected. If you select this option without entering anything in  the text field, the debugger will work as if "Start project" were selected. 

The Command line arguments field allows you to specify any command line arguments that should be  passed to the program when starting an executable. The option is not applicable if starting a URL.  The Working directory option allows you to specify the directory from which the project will be  launched for debugging. This applies only when Start project is selected. The default is the output path  folder specified in the build tab’s Debug configuration.  Introduction to Visual Studio 2010  

Page 25

Introduction to Visual Studio 2010   The Use remote machine, Enable unmanaged code debugging,“Enable SQL Server debugging and  Enable the Visual Studio hosting process options are not implemented in Synergy .NET projects and  should be ignored.  Settings



Switch to the Settings tab 

  You’ve already seen the settings tab earlier, when we were introducing the Settings.settings file. When  you clicked on the file you were presented with the visual designer for the project settings file, and that  same designer is available via the project properties dialogs also.  Resources



Switch to the Resources tab 

  And you’ve seen the resources tab before also, when we discussed the projects Resources.resx file  earlier. Again, the designer for the file is also available via the project properties dialogs. 



Close the project properties dialog by clicking the close (cross) icon in the main tab bar. If  you’ve made any changes then you may be prompted to save your changes. 

Introduction to Visual Studio 2010  

Page 26

Introduction to Visual Studio 2010  

Building the Project Visual Studio 2010 utilizes an external build system called msbuild to perform build operations. Almost  all projects have the concept of a build which is the process of generating whatever the output of the  project is, generally a .NET assembly, from whatever the input for the build is, generally source code.  You don’t need to do anything special to define what happens during a build other than configuring the  content of the project, which in most cases involves adding source files and source code to the project.  However there are other types of project that Visual Studio supports. For example, there are project  templates to allow you to create Windows Installer installation packages (msi files), as well as various  other things.  But most projects have a build option, and that’s how you cause the project output to be generated  (assuming that you have no errors of course!). Based on the project template, Visual Studio knows HOW  to build the target output. In the case of a Synergy .NET project, it knows to build a dblnet command  line using the various options specified in the project properties dialogs and using a list of all the source  files and assembly references defined in the project. Then it executes this command and displays the  resulting output. 

The Output Window Generally the output from a build is displayed in one or two places depending on whether the build was  successful. First, the actual textual output is displayed in the Output window, and then, if there were  any errors, those errors are generally parsed and displayed in a more structured way in the Errors  window.  Follow these steps to ensure that the output and errors windows are visible. 

□ □ □

From the menu, select View > Output (or type Ctrl+Alt+O)  If the error window is not pinned in place, then pin it in place by clicking the small push‐pin icon  at the top‐right corner of the window.  From the menu, select View > Error List (or type Ctrl+\ and then E) 

Now to build the project: 



From the menu, select Build > Build Solution (or type Ctrl+Shift+B) 

You should see the output window become focused, and output similar to this:  ‐‐‐‐‐‐ Build started: Project: IntroToVisualStudio, Configuration: Debug Any CPU ‐‐‐‐‐‐  ========== Build: 1 succeeded or up‐to‐date, 0 failed, 0 skipped ==========   

This output indicates that the project was built successfully.   



Introduction to Visual Studio 2010  

Page 27

Introduction to Visual Studio 2010  

Error List Window To demonstrate what happens when there is an error: 

□ □ □ □

In Solution Explorer, double‐click on Form1.dbl to display the forms graphical designer.  Double‐click inside the body of the form to open the code editor window and position your  cursor in the Form1_Load method.  Somewhere in the procedure division of the method, add some invalid code – anything. Adding  the words junk code would work quite nicely!  Type Ctrl + Shift + B to build the project. 

It is not necessary to manually save your changes, because Visual Studio will automatically do that each  time you do a build, or execute, or debug.  Again you should initially see the compiler output in the output window, but when the compiler  completes with an error, the error list window should be displayed, and should contain the details of the  errors that were reported by the compiler. You’re probably looking at something like this: 

  The window displays the errors, warnings, informational messages emitted by the compiler, as well as  information about the file in which the error occurred, the line number, and the name of the project.  If you only want to look at a certain type of message (errors vs. warnings for example) then you can filter  the content of the list by clicking on the various buttons in the small toolbar above the error list.  The list is also active; in that you can double‐click on messages in the list to take you to the point of the  problem. To demonstrate this: 

□ □

Close the Form1.dbl source file by clicking on the close (cross) icon in its main tab.  Double‐click on the first error line in the error list window. 

You should see the source file be re‐opened, and your cursor be positioned at the line with the problem  … don’t fix it just yet!   



Introduction to Visual Studio 2010  

Page 28

Introduction to Visual Studio 2010  

Task List Visual Studio has another useful window called the Task List. It’s probably already displayed in the same  tab‐set as the output and error list windows, but, if not, then: 



Display the task list by selecting View > Task List from the menu (or by typing Ctrl+\ and then T) 

The task list window has two modes determined by the drop‐down list in its small toolbar. 



Make sure that the drop‐down list has the User Tasks option selected. 

With User tasks selected, a developer can manually create a to do list by clicking on the Create User  Task button and entering the details of the task in the list. Tasks can then be checked off once  completed, or deleted by right‐clicking on the task and selecting Delete. 

□ □ □ □

Click on the Create User Task button in the task lists toolbar.  Type a new task … perhaps something like “Make this application actually do something!” and  hit enter.  Mark the task as complete by clicking its checkbox.  Delete the user task by right clicking it and selecting Delete (or by selecting the task and  pressing Delete). 

While creating user tasks in a project can be useful, what is more useful is the option to create to do  comments in your code. These are comments, with a special format, that a developer can place into a  source file, that will show up in the task list window.  



In the Form1.dbl code editor, add a comment like this after the bad code: 

;TODO: This needs fixing!   



In the task list window, change the drop‐down list from User Tasks to Comments. 

  You should see the comment that you entered displayed in the Task List. The TODO: prefix that you  typed is what determines that the comment should be displayed in this way. 

□ □

Back in the Form1.dbl source code editor, remove the TODO comment, and the bad code.  Perform a build to ensure that the application is in a good state (Crtl+Shift+B). 

Introduction to Visual Studio 2010  

Page 29

Introduction to Visual Studio 2010  

Executing a Project Depending on the type of project that you’re working on (you can’t directly execute a class library  project), once you have successfully performed a build, the next thing you’re likely to want to do is run  the application. Visual Studio makes this very easy. There are two main ways to begin executing a  project, one is to select Debug > Start Debugging (or press F5), and the other is to select Debug > Start  Without Debugging (or press Ctrl+F5).  As you have probably already deduced, the difference between these two options is that with the first, if  any things like breakpoints or watchpoints are activated, then control will pass to the debugger. With  the second method the debugger will not be used, even if breakpoints and watchpoints are present. 



Execute the application by pressing F5 (or by selecting Debug > Start Debugging). 

You should see the Windows Forms program start. Of course it’s not very interesting, because all the  application currently does is change the main form’s title to the string stored in the WelcomeMessage  resource file string. Even clicking the button doesn’t do anything! Let’s change that: 

□ □ □

Close the application.  Display the Form1 designer window.  Double‐click on the button. 

When you double‐click on a control Visual Studio takes you to the code for the default event for that  control. If that code doesn’t exist, then Visual Studio will insert a new empty event handler method for  the event. The default event for a button is the Click event, so you should now be looking at the  button1_Click method, which looks like this: 

 



In the data division, add a record and three integer fields, like this: 

  Introduction to Visual Studio 2010  

Page 30

Introduction to Visual Studio 2010    



In the procedure division, add the following code: 

  The point of this exercise is just to give us some code that we can interact with in the debugger later. 

Using the Debugger In Visual Studio the debugger is completely embedded within the development environment, making it  much easier to step through code and examine data. The debugger has many features, so we’ll just take  a brief look at some of the more fundamental things that you can do.  Breakpoints work in much the same way that you would expect in traditional Synergy, but are easier to  work with as a result of the graphical nature of the way that they are set, cleared and visualized.  Code editor windows all have a small region at the left margin where breakpoints can be set. To set a  breakpoint at a certain position you simply click in this region, and you will see a visual representation  of the breakpoint, like this: 

The red circle indicator in the breakpoint region indicates that a breakpoint is set at that position. If you  execute the application in debug mode then execution will be interrupted at that point.  It is also possible to have breakpoints set in your project, but disable one or more of those breakpoints  so that they will not fire while you are debugging. To disable a breakpoint right‐click on the breakpoint  indicator and select Disable Breakpoint. Disabled breakpoints look like this. 

  Re‐enable a disabled breakpoint by right‐clicking the breakpoint indicator and selecting Enable  Breakpoint. You can also toggle between an enabled and disabled state by placing your cursor on the  source line and pressing Ctrl + F9.  It is also possible to disable or enable all breakpoints via items on the Debug menu. 

Introduction to Visual Studio 2010  

Page 31

Introduction to Visual Studio 2010   If you wish to remove the breakpoint, simply click on the breakpoint indicator, or right‐click it and select  Delete Breakpoint. 



In the constructor method, Form1, add a breakpoint on the statement that calls the  InitializeComponent method, like this: 

   



Also add a breakpoint on the button1_Click method, like this: 

  There is also an easy way to examine all of your current breakpoints using a debugger tool window. 



From the menu, select Debugger > Windows > Breakpoints, or press Ctrl + Alt + B. 

  You should see the Breakpoints window which lists all of the breakpoints that you currently have set.  Double‐clicking on a breakpoint in the list will take place your cursor on the associated line of code, and  you can also easily add, remove, enable and disable breakpoints through this window. 



Execute the application by pressing F5 (Start Debugging). As an alternative, you can also use  the Start Debugging toolbar button, which looks like this 



When you start debugging you may notice that the layout of the Visual Studio user interface changes.  Visual studio maintains different window layouts when in debugging mode, and by default shows you  several windows which are useful during the debugging process. You can customize the window layouts  like we did earlier.  You won’t see the application on the screen yet, because we set a breakpoint in the constructor  method, and the form has not yet been initialized. What you should see is something like this: 

  Introduction to Visual Studio 2010  

Page 32

Introduction to Visual Studio 2010   The yellow arrow icon over the breakpoint indicator and the yellow highlight on the code indicates that  a breakpoint was encountered, and Visual Studio has handed control back to you. From this point on  you can determine what happens, using the same sort of techniques that you would if you were  debugging in traditional Synergy.  You can control the flow of execution using commands like Step Into (F11), Step Over (F10), Step Out  (Shift+F11) and Continue (F5). These options are available on the Debug menu column, and also have  corresponding icons on the Debug toolbar, which shows up when you start the debugger. It looks like  this:    

□ □ □ □

Step INTO the InitializeComponent() method by pressing F11, or by clicking the  button.  Start to step through the method by pressing F10 a few times, or by clicking the  button.  Step out of the method by pressing Shift+F11, or by clicking the 

 toolbar   toolbar 

 toolbar button. 

Continue execution by pressing F5, or by clicking the   toolbar button. 

You should now see the application appear on the screen, and it should operate normally until a  breakpoint is encountered. You set a breakpoint on the event handler for the button’s Click method, so: 



Click the button on the form. 

The debugger should now break on the proc statement of the button1_Click method. In the lower part  of the screen you should see a window called Locals; you may need to click on its tab to bring it to the  front. 



If you can’t see the locals window, select Debug > Windows > Locals from the menu. 

The locals window is very useful, it displays information about the local variables in the current scope. In  this case, the button1_Click method. You can use the window to view the content of local variables, and  you can also change the value of the local variables, at least for value types. 

□ □ □

Press the F10 key to step into the procedure division.  Double‐click in the Value cell for the var3 local variable, then type a new numeric value and  press enter.  In the locals window, click on one of the other local variables. 

You will see that when the value of a variable changes, the locals window temporarily displays the value  in red to indicate that it recently changed.  Introduction to Visual Studio 2010  

Page 33

Introduction to Visual Studio 2010  



Press the F10 key again to execute the first assignment statement and step to the next  statement. 

You will notice that the variable that you previously changed is no longer displayed in red, but that the  var1 variable is now in red, because the statement that was just executed changed the value of the  variable. 

□ □

Press F10 again to execute the second assignment statement.  Press F10 again to execute the addition expression and calculation. 

The yellow arrow indicator (next statement to execute) should now be pointing to the Debug.Print  statement which can be used to add tracing information to the output window in Visual Studio. This can  also be a useful debugging technique. If the application is executed normally (without debugging) then  this statement won’t do anything. 

□ □

Make sure that the output window is visible.  Press F10 to execute the Debug.Print statement 

You should see the text var1 + var2 = 3 printed in the output window.  Another useful window is the Immediate Window, which should be one of the tabs towards the bottom  of the screen. 

□ □

If you can’t see the Immediate Window then make it visible by selecting Debug > Windows >  Immediate from the menu, or by pressing Ctrl + Alt + I.  Check that the Immediate window is shown by clicking on its tab. 

The Immediate window allows you to type an expression into the window and have Visual Studio  evaluate the expression and display the resulting value. 



Click in the Immediate Window and type ?var1 and press enter. 

The debugger should display the value of the expression var1, in this case the value 1. 



In the Immediate Window, type ?var3 – var1 and press enter. 

Again, the debugger should display the value of the expression, 2.  Another way to interact with data is via the Watch window, which may not be displayed by default. This  window allows you to define expressions that you are interested in looking at on an ongoing basis.  These expressions could be simple variable names, or more complex expressions. 

Introduction to Visual Studio 2010  

Page 34

Introduction to Visual Studio 2010  

□ □ □ □ □ □ □ □ □

Stop the program by selecting Debug > Stop Debugging, or by pressing Shift + F5.  Press Ctrl + Shift + F9 and click the Yes button to remove all breakpoints.  Add a new breakpoint on the var1 = 1 statement.  Press F5 to start a new debugging session.  Once your application starts, in Visual Studio display the Watch window by selecting Debug >  Windows > Watch > Watch 1 from the menu.  Go back to your application and click the button.  In the Watch 1 window, click in the empty cell below the Name column, type var1 and press  enter.  Repeat this, but this time for the expression var2.  Add another watch, this time for the expression var1+var2. 

Your Watch window should now look something like this: 

 



Press F10 to step into the procedure division, then continue pressing F10 to step through the  assignment statements and notice what happens in the Watch window. 

Defining expressions in the Watch window can be a very useful technique when debugging complex  problems. 

□ □

Press Shift + F5 to stop the debugger.  Press Ctrl + Shift + F9 and click the Yes button to remove all breakpoints. 

The Visual Studio debugging environment is very powerful, and this has only been a VERY brief  introduction to its most basic features.   



Introduction to Visual Studio 2010  

Page 35

Introduction to Visual Studio 2010  

Working with Source Code You have seen the Synergy .NET source code editor a few times now, but so far we haven’t really  explored its capabilities. Let’s do that next.  As you would expect, the source code editor is also a very powerful tool. It is both language and context  sensitive, and can help you write code correctly first time, layout that code in an appropriate way, and in  many cases can actually write some of the code for you. 

Imports The concept of importing namespaces was first introduced in Synergy Language 9.1, when support for  object oriented (OO) development was introduced. In traditional Synergy, writing OO code is optional,  but in Synergy .NET everything is OO … whether you realize it or not. Yes, you can still use subroutines  and functions, but under the hood the environment is making those things methods on a class. In .NET …  everything is OO!  In OO programming, types (classes, interfaces, enumerations, structures, etc.) are organized into  namespaces. If these types are defined within a project then they are usually all part of the same  namespace and become part of the assembly being developed. This means that (subject to accessibility  rules defined in the code) they can be used within the assembly by simply naming the type.  However, if types are defined in a different assembly (project) then they are not automatically available  for use, and are generally going to be part of a different namespace. In this case, if we want to be able to  use the types in an external assembly then we add a reference to that assembly, as was discussed and  demonstrated earlier.  Having added a reference to an assembly, we can access the public types in the assembly, but to do so  we would typically need to fully name each type that we wish to use, each time we reference it. For  example, imagine that we have added a reference to an assembly called MyUtils.dll. In the assembly is a  class called DateUtils, and that class is part of the MyUtils namespace. The class has three public static  methods called DaysBetween(), AddDays() and SubtractDays().  If we wanted to refer to one of those methods in code in our project, we would need to fully name  them, including their namespace. Our code might look something like this:  paymentDue = MyUtils.DateUtils.AddDays(invoiceDate,30)  While there is nothing wrong with this code, it could be simplified. If we have referenced another  assembly and we are going to use the types in that assembly frequently, we have the option of  importing the namespace of the types that we wish to use. Importing the namespace makes the  compiler aware of the types in the namespace, and means that we don’t have to fully name the types  each time we need to refer to them (unless there is a duplicate type in two or more namespaces that we  have imported).   

 

Introduction to Visual Studio 2010  

Page 36

Introduction to Visual Studio 2010   So, we could import the namespace by adding code like this at the very top of the source file:  import MyUtils  And then we could write the code that uses those types without mentioning the namespace:  paymentDue =DateUtils.AddDays(invoiceDate,30) 





In the code editor for Form1.dbl, above the namespace definition and with the existing import  statements, add a new import for the System.Diagnostics namespace, like this: 

  Scroll down into the button1_Click method and remove the namespace prefix for the Debug  class, like this: 

  Importing a namespace is totally optional, but can make the code that uses the types in that namespace  much less verbose. 

IntelliSense When you were typing the import statement above, you may have noticed that after you typed  “import System.” something happened. You probably saw something like this: 

  What happened was a Visual Studio feature called IntelliSense recognized what you were typing, and  stepped in to help. In this case, IntelliSense recognized that you were not currently inside a namespace,  and had started to type an import statement. IntelliSense knows that if you have typed an import  statement, then you also need to add a namespace, so it presented you a list of all of the namespaces  that were currently available in your project (based on the project itself, and the assemblies that you  have referenced).  When this happens, you can continue to type, in which case the list of options will get gradually filtered  down to match the characters that you have typed so far:  Introduction to Visual Studio 2010  

Page 37

Introduction to Visual Studio 2010  

 

 

  At any time during this process you can use the arrow keys or mouse to select a suggested value, and  then press enter,  tab, or space to insert that value into your code. If you don’t want the assistance then  you can hit the escape key to close the IntelliSense prompts … and of course you can just ignore what  it’s doing and keep typing.  IntelliSense is context sensitive, so no matter where you are working in a piece of code you may find  that it jumps in there and offers shortcuts to what you’re typing. It can help you complete the names of  statements: 

  And types: 

 

Introduction to Visual Studio 2010  

Page 38

Introduction to Visual Studio 2010   And variables: 

  And parameters: 

  IntelliSense is very powerful, but until you get used to working with it, can also sometimes be a little  frustrating. The main reason for this results from the fact that the space key is one of the ways of asking  IntelliSense to complete what you typed. For example if you’re typing something, and IntelliSense is  offering you something that matches the characters that you have typed, you might instinctively press  the space bar to leave what you have typed and move on to the next word, but IntelliSense steps in and  replaces what you have typed with whatever match it was displaying when you pressed the space bar.  The solution to this is to hit the escape key to dismiss IntelliSense before you press the space bar, but at  first this can be a little frustrating. However, it is well worth persevering and getting used to the way  that IntelliSense works, because once you master the art it can save you a lot of typing. 

Snippets Another feature that can save you a lot of typing, particularly when you are writing new code, is a  feature called snippets. A snippet is similar in concept to an alias in Workbench. A snippet is a piece of  pre‐defined and named code that is inserted into the edit buffer, at the current cursor position, when  the name of the snippet is typed … followed by two tab characters. The first tab character selects the  snippet, and the second expands it.  Visual Studio also presents snippets to you via IntelliSense, like this: 

  Introduction to Visual Studio 2010  

Page 39

Introduction to Visual Studio 2010   You can tell that an item is a snippet because of its 

 icon. 

With a snippet selected, type TAB TAB to select and expand it. For example, the FOR snippet expands  like this: 

  Some snippets just expand to a piece of fixed code, but most expand to a piece of code that includes  special tokens that are intended to be replaced with some other value by the programmer. You can see  these tokens in the example above, the i with the green background is the currently selected token, and  1, length and 1 with the yellow backgrounds are other tokens to be selected and replaced.  With a snippet token selected, simply type the value that you want to insert, then press TAB to move on  to the next token or press ESCAPE to exit from token replacement completely.  So, to fully use the FOR snippet, you could type: 

for   count  10  1  ‐1  

 

Which would result in the following code: 

  While this may initially seem complicated, when you actually do it in the editor it is very natural, and can  save time. Another benefit of using snippets is that you’re pretty much guaranteed to produce the  correct code because the snippet does a lot of the work for you. Try it out: 

□ □ □ □ □ □

Place your cursor in the procedure division of the button1_Click method, after the  Debug.Print statement, on a new line  Type for and press tab twice.  Type var3 and press tab twice (once to dismiss IntelliSense, once to complete the snippet  token).  Type tab to accept the default value 1.  Type 10 to insert a custom value.  Type  to complete the snippet expansion 

Introduction to Visual Studio 2010  

Page 40

Introduction to Visual Studio 2010   Notice how when you pressed the escape key, the cursor moved into the begin end block. That’s part of  the functionality of the snippet also. 



Remove the FOR loop from the code. 

By the way, if you have blocks of code that you use frequently, then you can also create your own code  snippets and add them to Visual Studio, but that’s a little beyond the scope of our objectives for this  tutorial. 

Code Beautifier Synergy .NET includes a code beautifier, which can help you re‐format the source code in an edit  window. The beautifier follows the style rules that you have configured in your Visual Studio  environment … we’ll look at how to do that shortly.  Using the code beautifier couldn’t be easier; simply open a source file that needs cleaning up and  activate the beautifier by selecting Edit > Advanced > Format Document from the menu, or by typing  the key sequence Ctrl + K then Ctrl + D. Try it out: 

□ □ □ □ □

Place your cursor anywhere in the Form1.dbl source file.  Type Ctrl + A to select the whole method.  Type Shift + Tab several times to cause all of the code to be un‐indented to the left margin.  Click anywhere in the file to de‐select the code.  Type Ctrl + K followed by Ctrl + D to activate the code beautifier. 

You can also drag out a selection within the edit buffer and reformat just that selection using Format  Selection, or Ctrl+K then Ctrl+F. 

Adding new Items When you first created the project that you have been working on you used a Project Template, which  configured a new project for a specific type of development project. When it comes time to add  additional items to a project, you can use another type of template, this time called an Item Template.  Item templates provide an easy way to add various types of files to an existing project, and often  provide default content in the files that are added. 

□ □  

Close any open files by clicking on the close icon (cross) in the tab for each file. If you are  prompted to save changes then click Yes.  In Solution Explorer, right‐click on the IntroToVisualStudio project (it’s the one in bold) and  then select Add > New Item…, or type Ctrl + Shift + A.   

Introduction to Visual Studio 2010  

Page 41

Introduction to Visual Studio 2010   You will see the Add New Item dialog appear. It looks like this: 

  As you can see, the dialog content is filtered to file types appropriate for adding to a Synergy/DE project,  and organized into several categories. If you select the Synergy category then you will see all of the  available item templates and clicking on one of the more specific categories, such as Code, results in the  template list being filtered to only items that match that category. 

□ □ □ □

Select the Code category.  Select the Class template.  Change the name of the class to Customer.dbl  Click the Add button. 

You should see a new file added to Solution Explorer, and the new file should open in the editor; it  should contain default content for a new class.  Notice that the name of the class has been set to the name of the file that you entered, and also that  the namespace that has been inserted is the default namespace for your project as specified in project  properties. Files inserted by item templates are not necessarily produced from static content; rather  they can be generated as appropriate.    



Introduction to Visual Studio 2010  

Page 42

Introduction to Visual Studio 2010  

Adding Existing Items As well as adding new items to a project, you can add existing files. In fact there are two different ways  to add existing files to a project, one which places a COPY of the original file directly in your project  folder, and one which places a LINK to the original file into your project.   To copy an existing file into your project, go to Solution Explorer and right‐click on the project, then  select Add > Existing Item…. Use the resulting file browser dialog to locate and select the file or files that  you wish to add and click the Add button. Remember, this mechanism makes a COPY of the files directly  in your project folder.  An alternative is to add links to the existing files, without copying the files into your project. The  procedure for this is similar except that you will select Add > Reference Existing Item. When you add  links to existing items into a project, the file is not copied into your project folder, but is included in the  compilation when you build the project. 

Organizing Files in Folders As your development projects get larger you may find it necessary to organize your source files into  multiple folders below your project folder. This also has the advantage of organizing the files into folders  within Solution Explorer, and can make it much easier to work with larger projects in Visual Studio.  The approach usually taken is to group similar routines into folders. For example, if you are developing  an application using the MVVM design pattern, you might choose to place all of your view source code  into a Views folder, all the model code in a Models folder, and all of the view‐models into a ViewModels  folder. By the way, this isn’t a specific recommendation, it may be better to organize those things into  entirely separate projects and assemblies. It really depends on the scale of the application and several  other factors.  To create a new folder in your project: 

□ □ □ □

In Solution Explorer, right click on the IntroToVisualStudio project (it’s the one in bold) and  select Add > New Folder.  Change the folder name to Models and press enter.  Right‐click on the new folder and select Add > New Item.  Enter the information for a new Class called Product.dbl and click Add. 

You should see the new class added to Solution Explorer in the Models folder, and the new file should  open in a code editor window.  You will notice that the namespace used for the new item is IntroToVisualStudio.Models. You’ll  remember that IntroToVisualStudio was the default namespace for the project, and that items that you  add to the project are placed into this namespace. But, as you can see, when a new item is added to a  FOLDER in the project, the default behavior is to add the item to a nested namespace, based on the  Introduction to Visual Studio 2010  

Page 43

Introduction to Visual Studio 2010   name of the project. This behavior is consistent with other .NET languages and is generally a good idea.   However, if you don’t want to make use of nested namespaces, then you just need to remember to  change the namespace when you add new items into a folder. 

Adding Projects to the Solution So far we’ve only considered developing with a solution containing a single project. But very often when  working in Visual Studio you will work with solutions containing several projects, as you strive to  organize your application into logical units that can be re‐used from other places.  As we discussed earlier, a project is used to create a single assembly (program or class library).  Developers commonly organize reusable code (the equivalent of traditional Synergy’s subroutine  libraries) into separate assemblies and reference them from the projects which use the types that they  contain.  Let’s look at a simple example: 

□ □ □ □

In Solution Explorer, right click on the IntroToVisualStudio SOLUTION (it’s the one at the very  top) and select Add > New Project.  In the Add New Project dialog, select Synergy/DE and Class Library.  Set the Name of the class library to MyLibrary.  Press the OK button to add the new library.    You should now have two projects showing in Solution Explorer. You  will notice that the IntroToVisualStudio is still displayed in bold. That  is because it is set as the solution’s Startup Project, meaning that  when you execute or debug the solution that is the project whose  executable will be started.  Very often, solutions containing multiple projects will contain one  application and one or more class libraries, which can’t be started  directly, so it is usually clear which project should be the startup  project. However in some situations you may decide to have multiple  application projects in a solution, and in that case you can determine  which project is the startup project by right‐clicking the project and  selecting Set As StartUp Project. 

You have added a class library project to your solution, and it contains a single default class called  Class1. We’re not going to worry about functionality right now, because this tutorial is about how to use  Visual Studio with Synergy .NET, but what we do need to do is show how to modify the application  project to have a reference to the new class library project, so that it can use the types in the library. 

Introduction to Visual Studio 2010  

Page 44

Introduction to Visual Studio 2010  

□ □ □

In Solution Explorer, under the IntroToVisualStudio project, right‐click on the References  folder and select Add Reference.  In the Add Reference dialog, select the Projects tab.  Select MyLibrary and click the OK button. 

Your IntroToVisualStudio project now has a reference to your MyLibrary class library assembly, and can  use any public types in that assembly. 

Using the Code Converter Synergy .NET includes a code converter utility which is capable of translating C# syntax to the equivalent  Synergy .NET syntax. 



Select Tools > C# to Synergy Code Converter from the menu. 

  To use the code converter, either type or paste the C# code that you wish to convert into the box on the  left, and then click the translate button  . The translated code is placed into your clipboard so that you  can paste it into a source file.  The code converter can be very useful when learning how to program something in Synergy .NET  because there are many C# code examples in the Visual Studio documentation and on the Internet,  generally.  The code that you place in the left box must be a complete piece of code in a namespace. Pasting small  snippets of code into the converter will not work. 

Introduction to Visual Studio 2010  

Page 45

Introduction to Visual Studio 2010   The code converter has been substantially improved since the initial release of Synergy .NET and is now  capable of converting most C# code, but there are some syntax constructs available in C# that have no  direct equivalent in Synergy .NET, so occasionally the code converter may report Failed to convert.  Also, occasionally the code converter may encounter C# syntax which can be implemented in Synergy  .NET, but which is too complex to be converted automatically. In these cases, whenever possible, the  code converter will insert a TODO: comment into the resulting code to indicate that you need to do  some manual work.  In many cases the code converter is able to produce code which is 100% correct, but if you are using it  to produce code that you actually intend to use (rather than just to learn a technique from) then it is  recommended that you review the code that was produced. 



Close the code converter window. 

Building With Multiple Projects When you work within a solution that includes multiple projects then Visual Studio will build any  projects that are out of date whenever you execute or debug the application. Also, typing Ctrl + Shift + B  (build solution) will also build any projects which are out of date. Try it: 



Type Ctrl + Shift + B 

Check the output window and you should see that both of your projects were built: 

  You also have the option of building the projects individually via menu items on the Build menu. You will  see separate options to build the solution or the current project. The current project is whichever  project contains the selected item in the Solution Explorer tree. 

Configuring Visual Studio As with any modern software development environment, Visual Studio is VERY customizable. You can  change many aspects such as whether things are visible, where things appear on the screen, what  keyboard shortcuts are used, etc. You can also perform extensive customization of things like the  behavior of the editors and many other things.  Attempting to cover all of this in a tutorial like this is not feasible, so instead we’ll just point you in the  right direction and highlight a few of the Synergy .NET specific extensions.   

 

Introduction to Visual Studio 2010  

Page 46

Introduction to Visual Studio 2010  



From the menu, Select Tools > Options 

The Options dialog contains literally thousands of configurable settings which allow you to control  virtually any aspect of Visual Studio. 

 



In the tree control, select Text Editor, then expand and select Synergy/DE 

Below Synergy/DE you will find several pages of settings related specifically to working with Synergy  .NET. At some point you should take the time to familiarize yourself with the various settings available. 



Select the Formatting item 

The formatting page allows you to specify, in detail, how you want Visual Studio to format the code that  you type. These same rules are also followed by the code beautifier tool. 



Press Cancel to close the options dialog. 

Review During this workshop we have attempted to introduce you to the basic functionality provided by Visual  Studio 2010, but there is a lot more to learn. Visual Studio is an extensive application, with many options  and many ways of working, and is extremely customizable. 

Introduction to Visual Studio 2010  

Page 47

View more...

Comments

Copyright � 2017 SILO Inc.