To complete the Visual Basic to .NET upgrade process, you may need to revise some aspects of the application to guarantee a smooth experience for the end user. This chapter will guide you through these revisions, accurately explaining how to separate the VB .NET assembly, the procedure to upgrade the VB help file, and how to deal with the upgraded VB .NET application setup and deployment, among others.
An assembly is the primary building block of a .NET Framework application. It is a component library that is built, versioned, and deployed as a single implementation unit. Every assembly contains a manifest, which describes that assembly.
In these cases, the development, deployment and support aspects can be negatively affected. This can result in serious deployment problems if parts of the application are modified and new versions of those parts need to be installed. Visual Basic 6.0 supported this type of organization because it allowed the developer to define only a single user class per file. Visual Basic .NET supports having more than one class per assembly, which allows developers to create groups of related classes with high cohesion.
Small and medium-size projects can have components organized into assemblies that correspond to each of the application tiers. Assembly separation by tier is a natural consequence of the physical separation between the different application tiers.
The main reason is the size and complexity of the assembly. If an assembly is large and some of its functionality is rarely used, the assembly can be divided according to functional layers. You should consider locating the presentation tier, business logic, and data access layers in the same assembly if doing so will ease deployment and systems management concerns.
When the complexity of an application increases, you should organize assemblies into functional groups. A functional separation is useful from a design perspective because it allows developers to build new functionality based on blocks that operate at the same conceptual level as the new features. For example, the business logic and the data access functionality can be grouped into a single assembly that would be shared by multiple applications.
No. The Upgrade Wizard leaves the HelpFile property (used to specify the name and location of the Help document) and the HelpContextID properties (used to associate a specific topic in the Help file for each control on your forms) unchanged. In addition, the Upgrade Wizard generates a compilation error for each occurrence of these properties because of changes in the Help system in Visual Basic .NET.
The VB .NET HelpProvider class provides Help for controls by extending their properties to the following:
Visual Basic .NET supports the HTML Help format only. Therefore, if your existing Help project is based on a Windows Help project (a .hpj file), you must change it before you upgrade the source code.
You can do this by using the WhatsThisButton and WhatsThisHelp properties of a form. The What’s This button appears when you set these properties to True and you set the following properties to the specified values:
Run-time files. These are files an application must have to work correctly after installation. All Visual Basic 6.0 applications require these files. The following are the run-time files for Visual Basic projects: Msvbvm60.dll, Stdole2.tlb, Oleaut32.dll, Olepro32.dll, Comcat.dll, Asycfilt.dll, and Ctl3d32.dll.
These also include other files that your project depends on, such as the library and other files used by the ActiveX controls that your application contains.
Setup and Deployment projects is a new project type in VB .NET that allows you to create Windows installers or CAB files to distribute your applications.
The process of using the Setup and Deployment Projects option to create installers is easiest when you have used a Visual Basic 6.0 setup project to create installers without making any customizations to the resulting installer. For simple projects that require no customization in deployment, you need only indicate the executable files and the product name in the deployment project. However, if your original project’s installer required customization, such as adding additional dialog boxes or changing standard dialog text, then you will need to perform similar customization when you use Setup and Deployment Projects.
The editors available at Visual Studio .NET for applying changes and meeting the deployment requirements of an application are the following:
Some of the available dialog boxes that you can add are the following:
A merge module (.msm) is a single package that includes all files, resources, registry entries, and setup logic to install shared files. Merge modules allow you to install components that are shared by multiple applications, such as the COM projects.
The merge modules are Setup and Deployment project options available in Visual Studio .NET that you can add to your solution. Anything that can only be used by a developer, such as .dll files, controls, resources, and components, should be packaged into a merge module. This module can later be included in a Windows Installer for distribution to the end user.
The main properties that the File System Editor provides are the following:
These are some examples:
The first thing is the performance of the invocations. Calls between different processes are expensive compared with calls within the same process. Another aspect to consider is the security verification performed during component invocations. Security credentials are verified only for interprocess invocations. Library components use the security level of the host process.
8834 N Capital of Texas Hwy, Ste 302
Austin, TX 78759
Call us: +1 (425) 609-8458
info@wearegap.com
