Share via

Introducing .NET to Office Developers

  • Article

 

Paul Cornell
Microsoft Corporation

October 2, 2001

The Microsoft® .NET platform promises new opportunities for designing integrated software applications that connect businesses and individuals anytime, anywhere, and on virtually any software device. In this month's column, I provide a high-level overview of .NET, suggestions for when to consider .NET for your Microsoft Office solutions, and some introductory examples of .NET solutions using Microsoft Visual Basic® .NET. In upcoming Office Talk columns, I will show you how to:

  • Use .NET features in Office Visual Basic for Applications (VBA).
  • Create .NET applications that automate Office.
  • Create XML Web services in .NET that Office can use.
  • Use Office ActiveX® controls in .NET solutions.
  • Unlock Office data from .NET.

Why Should I Be Interested in .NET?

There are several reasons to be interested in .NET, including the following:

  • Fewer development paradigms to learn. Office macro development requires you to learn a development paradigm using Visual Basic for Applications (VBA). Web application development requires you to learn another development paradigm using a different set of development languages, such as Microsoft Visual Basic Scripting Edition (VBScript) or Microsoft JScript®. If you need to call the Microsoft Windows® application programming interface (API), you have to learn yet another development paradigm. Microsoft .NET consists of one development paradigm for both desktop and Web-based applications, which reduces the number of new Microsoft development technologies you need to learn.
  • Easier and faster application deployment. One big frustration for Office developers is application deployment and versioning. If you ask an Office developer about distributing macros, deploying Microsoft Outlook® Forms, registering dynamic-link libraries (DLLs), or updating Component Object Model (COM) add-ins, you are bound to get complaints. For many .NET applications, .NET features "copy and paste" or XCOPY deployment (users simply copy your application files from the source media to any single directory and run the application). Finally, .NET no longer relies on the Windows registry or regsvr32.exe, which eliminates DLL and COM add-in version compatibility issues.
  • New types of Office solutions. Office VBA solutions development is currently restricted to macros, UserForms, or Outlook Forms applications, and Web projects such as data access pages, Microsoft FrontPage® Web sites, applications interacting with the Microsoft Office Web Components, and static HTML pages. Office VBA has made advances into the .NET world by integrating with XML Web services through the SOAP Toolkit, as well as integrating with the Microsoft Windows Server System™, such as Microsoft Exchange Server, Microsoft SQL Server™, and Microsoft BizTalk™ Server. However, additional types of applications in .NET include richer desktop-based applications with custom user controls, Web form–based applications with custom Web controls, .NET Framework class libraries, command-line applications, and Windows background services. In the years ahead, Visual Basic .NET will also be the language of choice for Office developers to create digital dashboard solutions, solutions based on SharePoint™ Team Services and SharePoint Portal Server, Web Parts, smart tags, XML-based solutions, and more.

Examples of .NET and Office Working Together

Here are some examples of how you can use .NET and Office together:

  • Console applications. Console applications, which run from command prompts, are useful for automated solutions. For instance, although you can create Office VBA macros to automate tasks, these macros cannot run on their own. They require some type of application-level intervention, such as a Document_Open event, or some type of user input, such as pressing a button or triggering an event. For example, using Scheduled Tasks in Control Panel, you can run a console application that validates and transfers data from a Microsoft Excel spreadsheet to a Microsoft SQL Server database every morning at 2:00 A.M. when network traffic is low. As a side benefit, you can design console applications to accept command-line parameters. This allows you to customize an application's startup behavior, which lessens the need to create a user interface. Console applications are not available in Office VBA or Visual Basic 6.0, but they are available in Visual Basic .NET.
  • Microsoft .NET Windows Forms applications. Windows Forms take the concept of Office VBA UserForms and Visual Basic 6.0 forms to the next level. They allow you to create base forms that contain repetitive controls and code (such as name and address data-entry text boxes) and include these base forms in other forms. Windows Forms also have features such as transparency, on-the-fly menu editors, and automatic control resizing and anchoring. Many cool new form controls are also available, such as data-entry validators, common dialog boxes, hyperlinked labels, system tray icons, panels, numeric up/downs, on-the-fly designable tree views, Help file linkers, ToolTip extenders, and more.
  • ASP.NET Web applications. Creating Office Web-based solutions today requires you to learn several development paradigms. Office can emit static HTML that offers rich formatting, but does not allow for any user interaction. Data access page solutions and the Office Web Components allow for user interaction, but to extend these solutions, you need to learn an array of HTML, DHTML, VBA, and VBScript technologies. If you want to extend these solutions even further, you face at least three additional development paradigms, including FrontPage, Microsoft Visual InterDev® and DHTML Application projects with WebClasses in Visual Basic 6.0. Microsoft .NET converges and simplifies these development paradigms down to one: Microsoft ASP.NET Web applications. With this paradigm, you can quickly create Web-based forms just as you would using the UserForms editor in Office VBA—you drop controls onto the design surface and double-click user interface elements to write Visual Basic .NET code. In many cases, you do not need to install DLLs or other components on users' computers; they only need a compatible Web browser.
  • ASP.NET Web Services. Creating XML Web services today is complex and time consuming. For example, let's say you want to create an XML Web service that validates information on some sales proposals created with Microsoft Word before they are submitted to a document management system, such as Microsoft SharePoint Portal Server. To create the XML Web service, you first need a tool like Visual Basic 6.0 to create a COM DLL that contains all the logic behind the sales proposal validator. Then, you need to register the DLL on a compatible Web server. Finally, you use the SOAP Toolkit to generate Web Services Description Language (WSDL) and Web Services Meta Language (WSML) files on the Web server. An XML Web service created with Visual Basic .NET avoids all of these steps. You can be productive immediately without worrying about any of these plumbing issues—just create an ASP.NET Web Service project and start coding your sales proposal validator functions.

The .NET Tools

The .NET tools that you will use to create and deploy these types of solutions include the following:

  • Microsoft Visual Studio® .NET, currently at Beta 2, is the next generation of Microsoft Visual Studio. Visual Studio .NET includes tools such as Visual Basic .NET, the .NET Framework Software Development Kit, and the .NET Framework redistributable package, which gives you all of the resources you need to create, deploy, and run .NET applications. You can get Visual Studio .NET Beta 2 by subscribing to MSDN Universal, or you can order Beta 2 online.
  • The .NET Framework redistributable package, commonly referred to as the ".NET runtime" and currently at Beta 2, includes everything that your users will need to run client-based .NET Framework applications, including the Common Language Runtime and the .NET Framework class libraries. Microsoft ASP.NET is also included if you want to install ASP.NET on a compatible Web server without the overhead of Visual Studio .NET. The .NET runtime runs on Microsoft Windows XP, Windows 2000, Windows NT® 4.0, Windows 98, and Windows Millennium Edition (Windows Me). Microsoft Internet Explorer 5.01 or later is required. For server-side installations, MDAC 2.6 is required; MDAC 2.7 is recommended. Visual Studio .NET includes the .NET Framework redistributable package.

Should I Use Office VBA or Visual Basic .NET?

Whether you should use Office VBA or Visual Basic .NET (or both in conjunction) depends on what type of solution you are creating.

You should use Office VBA in the following cases:

  • If you are developing a quick Office macro, a solution that is tightly coupled with a single Office document, or a solution that is built on a specific Office technology that has no direct .NET equivalent, such as Data Access Objects (DAO). In some cases, creating a .NET equivalent is either impossible or involves too much overhead.
  • If you are developing a solution unique to Office, such as a COM add-in, data access pages, Outlook Forms, a Word-based solution that must live in Normal.dot, and so on. Not only are these familiar solutions for Office developers, but they are also well documented and supported.
  • If you are developing UserForm-based applications, and the forms are simple. For more complex forms-based applications, you may want to use Windows Forms applications in Visual Basic .NET, in which you can also create Windows Controls (similar to ActiveX controls).

You should consider using Visual Basic .NET in the following cases:

  • If you are developing solutions that are not solely Office-based, but do use some of the functionality of the Office VBA object libraries. Visual Basic .NET can interoperate with the Office VBA object models.
  • If you are creating Web-based applications or Web controls, Windows controls, console applications, class libraries, or Windows background services.

Getting Started Using Visual Basic .NET

To become oriented with .NET development, let's use Visual Basic .NET to create a few .NET applications. In next month's column, I will present code that specifically targets Office and demonstrates .NET and Office code compatibility, so I will present very simple applications here to build a good foundation.

Installing Visual Basic .NET and Using the Integrated Development Environment (IDE)

Installing Visual Basic .NET is very straightforward—simply run setup.exe from the Visual Studio .NET Beta 2 CD or Visual Studio .NET Beta 2 download, and follow the on-screen directions.

To start and configure Visual Basic .NET and create a .NET project, follow these steps:

  1. Once you have installed Visual Studio .NET Beta 2, you can start Visual Basic .NET by clicking Start, pointing to Programs, pointing to Microsoft Visual Studio .NET 7.0, and clicking Microsoft Visual Studio .NET 7.0.
  2. Set up your integrated development environment (IDE) to reflect a Visual Basic development environment. To do so, click Show Start Page on the Help menu. Click My Profile, and select Visual Basic Developer in the Profile list.
  3. On the File menu, point to New and click Project.
  4. In the Project Types pane, click Visual Basic Projects.
  5. In the Templates pane, click one of the available project types.
  6. Fill in the Name and Location boxes, and then click OK.

Creating a Console Application

When you follow the previous steps to create a console application, Visual Studio .NET creates several files and folders in the solution's root folder for you.

If you look in the console application's folder using Windows Explorer, you will see the following default files that Visual Studio .NET generates:

  • A solution file (similar to a .vbg file in Visual Basic 6.0), named something like ConsoleApplication1.sln. A solution can contain one or more projects in the Visual Studio .NET Solution Explorer window. The .suo file records all the Visual Studio .NET options that you might associate with your solution so that each time you open it, it includes customizations that you have made.
  • A project file (similar to a .vbp file in Visual Basic 6.0), named something like ConsoleApplication1.vbproj. The .vbproj.user file is similar to the .suo file in that it records all of the Visual Studio .NET options that you might associate with your project so that each time you open it, it includes customizations that you have made.
  • An assembly file, named AssemblyInfo.vb (also visible in the Solution Explorer window), which provides information to the compiler about the .NET assembly that will be generated.
  • A code module file, named something like Module1.vb (also visible in the Solution Explorer window), which contains the code that you will write for this assembly (similar to a .bas file in Office VBA).

**Note   **Most files in Visual Basic .NET have a .vb file extension, except for XML files (.xml), HTML pages (.htm), text files (.txt), Web Forms (.aspx), XML Web services (.asmx), and other minor file types. This is interesting, because Office VBA has .bas files, .cls files, .frm files, and so on. In Visual Basic .NET, there is just one file type for all of these—.vb. This means you could put all your solution code—code modules, class modules, form modules, and so on—inside of one large .vb file (although this is not a great programming practice!).

  • A \bin folder, which will contain your .NET assembly and other supporting files (which are generated when you click Build from the Build menu in the Visual Basic .NET IDE). To deploy your application, simply copy the files in the \bin folder to a single, local folder on a user's computer and run the .exe file.
  • An \obj folder, which contains a \Debug folder (intermediate files compiled with full symbolic debug information and no optimization), or a \Release folder (intermediate files that are fully optimized and contain no symbolic debug information), depending on the build type you select in the Solution Configurations list (on the Standard toolbar).

**Note   **If you build a Debug release, you will see a file named something like ConsoleApplication1.pdb in the \bin folder. This file contains debugging information that does not need to be distributed with a Release build.

Setting References in .NET

In the Solution Explorer window (similar to the Project Explorer window in Office VBA), you will notice a References folder. This is similar to the References dialog box on the Tools menu in Office VBA, in that you need to set a reference to an external library before you can use it, but you can set references to .NET Framework class libraries, as well as COM object libraries. To set a reference, right-click the Reference folder and click Add Reference, or from the Project menu, click Add Reference.

The System, System.Data, and System.XML entries mean that you do not have to type out the words System, System.Data, or System.XML if you want to call a member of one of these .NET class libraries to which the entries belong. For example, you can type Console.ReadLine() instead of System.Console.ReadLine(). This is similar to omitting the words Excel, Word, Outlook, and so on, in front of the word Application when coding in Office VBA, provided you have first set a reference to the corresponding object library in the References dialog box.

Sample Code for the Console Application

Let's create a simple console application. Here is the code that you can insert into Module1.vb to add two numbers together from the command prompt:

Module Module1
    
    Sub Main()

        Dim intFirst As Integer
        Dim intSecond As Integer

        Console.WriteLine("Enter first whole number:")
        intFirst = Console.ReadLine()
        Console.WriteLine("Enter second whole number:")
        intSecond = Console.ReadLine()
        Console.WriteLine("The value of " & intFirst & _
            " and " & intSecond & " is " & intFirst + intSecond & ".")
        ' Keep the command window visible.        
        Console.WriteLine("Press any key to continue.")
        Console.ReadLine()

    End Sub
    
End Module

To run this code from Visual Studio .NET, on the Debug menu, click Start (or press F5). Alternatively, on the Build menu, click Build (or press CTRL+SHIFT+B), and then open ConsoleApplication1.exe from the solution's \bin directory using Windows Explorer.

The following explains some of the preceding code:

  • The Module...End Module keywords indicate that this code is part of a code module (similar to a .bas file in Office VBA). There could be multiple code modules, class modules, form modules, and so on, in this .vb file. The name of this module is Module1.
  • The ReadLine and WriteLine methods of the Console class allow you to read and write information from and to the command window, respectively.

Creating a Windows Forms Application

Let's move on to create a simple Windows Forms application, similar to a UserForms application in Office VBA. When you create a Windows Forms application by selecting the Windows Application project type, you will notice files and folders similar to the console application. In the solution's application folder, you not only get the standard .sln, .suo, .vbproj, .vbproj.user, and AssemblyInfo.vb files, along with the \bin and \obj folders, but you also get a Form1.vb file (similar to a .frm file in Office VBA) that represents the Form1 form, along with a Form1.resx file. A .resx file is an XML file that represents all of the external resources that the Form1 form can use, such as text strings, images, and other nonexecutable data.

To add controls to the Windows Form and write code, follow these steps:

  1. To add controls to the Windows Form, click Toolbox on the View menu (or press CTRL+ALT+X). You can also click Toolbox on the docking bar (you can unpin the Toolbox to have it collapse to the edge of your screen to expose more screen real estate).

  2. Click the Windows Forms tab. Then click TextBox and drag it onto Form1. Repeat this step for a button.

  3. Double-click Button1 to open the Code window. Make the code in the Form1.vb file look like this:

    Public Class Form1

    Inherits System.Windows.Forms.Form

' Windows Form Designer generated code

    Private Sub Button1_Click(ByVal sender As System.Object, _
            ByVal e As System.EventArgs) Handles Button1.Click

        Me.TextBox1.Text = "This is easy!"

    End Sub

End Class

  4. Build and run this application as you would for the console application.

The following explains some of the preceding code:

  • The Class...End Class keywords are similar to the Module...End Module keywords in the console application, except that they contain code for Form1. A Windows Form is a type of class module.
  • Inherits System.Windows.Forms.Form means that Form1 takes on all the characteristics, the look and feel, and the class members of a generic Windows Form.
  • The Button1_Click event looks slightly different from an Office VBA event (Private Sub Button1_Click()...End Sub) in that there are parameters and a Handles statement. The sender parameter represents the object that triggered the event (Button1). The e parameter represents miscellaneous event data. The Handles statement indicates that this procedure handles the Button1.Click method. In .NET terms, the Button1_Click subroutine is known as a delegate.
  • You will notice that there are plus (+) and minus (-) symbols on the left side of your code, with lines connecting the symbols. This is called outlining, and can be used to reduce visual code clutter. The line Windows Form Designer generated code has one of these symbols, and if you click on it, you will see a lot of additional code. Office VBA shields you from the code that keeps track of the behaviors, sizes, and locations of UserForms and controls on UserForms. Visual Studio .NET provides all of these details, hidden by default, within the #Region...#End Region keywords. This code changes as you make changes to Form1 within the Windows Forms Designer. You will never need to edit most of this code directly, unless you want fine-grained control over form initialization or destruction behaviors.

Creating a Web Forms Application

Let's now move into the realm of Web-based applications, starting with a Web Forms application. Of course, to create a Web Forms application, you need to have access to a Web server that is hosting ASP.NET.

After you create a project based on the ASP.NET Web Application project type, you will see the following default files created in the project's application folder on the ASP.NET Web server:

  • The .vbproj and .vbproj.webinfo files, which are similar to the .vbproj and .vbproj.user files from the Windows Forms application.
  • The AssemblyInfo.vb and .resx files, which are similar to their counterparts in the Windows Forms application.
  • The WebForm1.aspx Web Form, which is similar to a .NET Windows Form or an Office VBA UserForm, but the borders of the Web Form will be the borders of a Web browser. To develop a Web Form, you add controls and write the corresponding code in the WebForm1.aspx.vb file.
  • The Global.asax* files, also known as the ASP.NET application files, which are optional files that contain code for responding to application-level events raised by ASP.NET.
  • The Styles.css file, which contains style sheet information for the WebForm1 Web Form.
  • The Web.config file, which contains information about application and run-time settings, security, trust, policies, authentication and encryption, browser capabilities, compilation and globalization settings, and more.
  • The WebApplication1.vsdisco file, which contains high-level discovery information about the Web Forms application.

Sample Code for the Web Forms Application

Let's repeat what we did for the Windows Forms application here on the Web Form:

  1. Add a TextBox and Button to WebForm1; double-click to open the Code window, and make the code in the WebForm1.aspx.vb file look like the following code:

    Public Class WebForm1
    Inherits System.Web.UI.Page
    Protected WithEvents TextBox1 As System.Web.UI.WebControls.TextBox
    Protected WithEvents Button1 As System.Web.UI.WebControls.Button

' Web Form Designer Generated Code

    Private Sub Page_Load(ByVal sender As System.Object, _
            ByVal e As System.EventArgs) Handles MyBase.Load
        'Put user code to initialize the page here.
    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, _
            ByVal e As System.EventArgs) Handles Button1.Click

        Me.TextBox1.Text = "This is easy!"

    End Sub

End Class

  2. Build and run this application as you would for the console application or the Windows Forms application.

This code looks similar to the code in the Windows Forms application:

  • The Inherits statement means that WebForm1 has the same characteristics, look and feel, and class members as a generic Web Form.
  • The WithEvents statements are familiar if you have ever created objects that can respond to events.
  • The Page_Load event is similar to a Visual Basic 6.0 Form_Load event.
  • The Button1_Click event is similar to its counterpart in the Windows Forms application.

Creating and Using an XML Web Service

Building on Web-based applications, let's create a simple XML Web service on our ASP.NET server that adds, subtracts, and multiplies two integers.

When you create a project based on the ASP.NET Web Service project type, in the project's application folder you get many of the same files and folders as the Web Forms application—the .vbproj files, the AssemblyInfo.vb file, the Global.asax* files, the Web.config file, the .vsdisco file, and the \bin folder. You also get the Service1.asmx.vb file, which holds the code for your XML Web service; the Service1.asmx.resx file, which holds the resources for your XML Web service; and the Service1.asmx file, which is similar to the Object Browser, in that it provides a browser-based user interface to allow you to view all of the XML Web service's exposed functions and function signatures. But the .asmx file also allows you to call the XML Web service's exposed functions, without writing a single line of code!

Sample XML Web Service Application Code

Here's the code I created for my XML Web service in the default file Service1.asmx.vb:

Imports System.Web.Services

Public Class Service1
    Inherits System.Web.Services.WebService

    <WebMethod()> Public Function AddTwoIntegers _
            (ByVal intFirst As Integer, ByVal intSecond As Integer)

        Return intFirst + intSecond

    End Function

    <WebMethod()> Public Function SubtractTwoIntegers _
            (ByVal intFirst As Integer, ByVal intSecond As Integer)

        Return intFirst - intSecond

    End Function

    <WebMethod()> Public Function MultiplyTwoIntegers _
            (ByVal intFirst As Integer, ByVal intSecond As Integer)

        Return intFirst * intSecond

    End Function

End Class

The following explains some of the preceding code:

  • The line Imports System.Web.Services is similar to the Add Reference dialog box in that it allows me to omit System.Web.Services in front of any class or class member of the System.Web.Services namespace (a namespace is a logical grouping of classes and class members, similar to the words Excel, Access, or Outlook before the word Application in Office VBA).

  • The line Inherits System.Web.Services.WebService signifies that this XML Web service takes on all of the characteristics, look and feel, and class members of a generic XML Web service.

  • The symbols < and > indicate something called an attribute. Attributes are additional information that "tags along" with code, providing special details to the compiler. In this case, <WebMethod()> instructs the compiler to expose the associated function to callers of the XML Web service. If we left the attribute off the function, it would be available for internal use but not exposed through the XML Web service.

  • The Return keyword returns a value back through the functions; you can use either the name of the function or the Return keyword to signify the return value. In other words, the following two lines of code are equivalent in the AddTwoIntegers function (an exposed function in an XML Web service is also known as a Web method):

    Return intFirst + intSecond
AddTwoIntegers = intFirst + intSecond

Note   You will notice that I didn't provide any error-handling code for checking to see if non-integers were supplied by the user, nor did I provide any error-handling code for any of my other code examples. In the interest of space, I will leave this discussion for next month.

Calling the XML Web Service from a Windows Form

Now let's call this XML Web service from a Windows Forms application by creating a new project and selecting the Windows Application project type:

  1. On Form1, drop two text boxes (txtNumber1 and txtNumber2) representing the two integers, and three buttons representing the addition, subtraction, and multiplication functions (btnAdd, btnSubtract, and btnMultiply).
  2. On the Project menu, click Add Web Reference. In the Address box, type the URL of the Service1.asmx file you created previously (for example, https://localhost/WebService1/Service1.asmx), click the entry in the Available references list, and then click Add Reference.

Here is the code for Form1.vb:

Public Class Form1

    Inherits System.Windows.Forms.Form

' Windows Form Designer generated code

    Dim wsCalcInts As New MyServerName.Service1()

    Private Sub btnAdd_Click(ByVal sender As System.Object, _
            ByVal e As System.EventArgs) Handles btnAdd.Click

        MessageBox.Show(Text:=wsCalcInts.AddTwoIntegers _
            (intFirst:=CInt(Me.txtNumber1.Text), _
            intSecond:=CInt(Me.txtNumber2.Text)))

    End Sub

    Private Sub btnSubtract_Click(ByVal sender As Object, _
            ByVal e As System.EventArgs) Handles btnSubtract.Click

        MessageBox.Show(Text:=wsCalcInts.SubtractTwoIntegers _
            (intFirst:=CInt(Me.txtNumber1.Text), _
            intSecond:=CInt(Me.txtNumber2.Text)))

    End Sub

    Private Sub btnMultiply_Click(ByVal sender As Object, _
            ByVal e As System.EventArgs) Handles btnMultiply.Click

        MessageBox.Show(Text:=wsCalcInts.MultiplyTwoIntegers _
            (intFirst:=CInt(Me.txtNumber1.Text), _
            intSecond:=CInt(Me.txtNumber2.Text)))

    End Sub

End Class

The following explains some of the preceding code:

  • The line Dim wsCalcInts As New MyServerName.Service1() is necessary because before you can call an XML Web service in Visual Basic .NET, you need to declare and initialize an object that will hold an instance of the XML Web service class (called a proxy class; the resulting object is called a proxy object). The proxy class is MyServerName.Service1, and the proxy object is wsCalcInts. The text MyServerName will be different depending on the name of your Web server; see the Web References folder in the Server Explorer window for the name of your Web server.
  • The MessageBox class of the Systems.Windows.Forms namespace is similar to the familiar Office VBA.MsgBox function. The MessageBox.Show method displays the message box. The Show method's Text parameter is the same as the MsgBox function's Prompt parameter.

Creating Other Types of .NET Applications

Because I am out of space to describe how to create class libraries, Windows controls, Web controls, and Windows background services, I will leave it up to you to experiment with creating these types of applications. To use a Windows control, you must first create a Windows Form and then place the Windows control on the Windows Form. Similarly, to use a Web control, you must first create a Web Form and then place the Web control on the Web Form. In this sense, Windows control and Web Form control development is similar to ActiveX control development.

Deploying .NET Applications

Deploying .NET applications is straightforward. After you've successfully built an application by clicking Build on the Build menu (or pressing CTRL+SHIFT+B), or clicking Run on the Debug menu (or pressing F5) and receiving no build errors, do the following:

  • For a console application or a Windows Forms application, simply copy the files in the application's \bin directory to media such as a network file share, disk, or CD (for simple applications, this is usually a single .exe file). Users can then copy the same files to any single directory on their computer and open the application's associated .exe file.

    **Note   **If you attempt to run a console application or a Windows Form application from a computer on which the .NET runtime is not installed, you will receive the error "Unable To Locate DLL: The dynamic link library mscoree.dll could not be found in the specified path..." To solve this problem, install the .NET runtime on the computer and try running the application again.

  • For a Web Forms application, simply provide users with the URL of the application's .aspx file.

  • For an XML Web service, provide users with the URL of the XML Web service's .asmx file.

For more complex applications that require actions such as installing files into specific folders, registering assemblies in the global assembly cache, placing entries on the user's Programs menu or desktop, registering COM DLLs, and so on, you will want to create a Setup and Deployment project in Visual Studio .NET. I will discuss more about this in next month's column.

Where to Go for More Info

There is no way I can cover all the great features that .NET offers you in one column! Here are some additional .NET resources that you can explore:

General .NET Topics

Visual Studio .NET

Visual Basic .NET

.NET Framework

ASP.NET

XML Web Services

And, as always, check in regularly at the Office Developer Center for information and technical articles on Office solution development.

 

Paul Cornell works for the MSDN Online Office Developer Center and the Office developer documentation team. He spends his free time playing card games with his wife and reading to his daughter.