Visual J++ Technology Preview 2 Readme

© 1998 Microsoft Corporation. All rights reserved.

Other product and company names herein may be the trademarks of their respective owners.

Visual J++® Readme includes updated information for the documentation provided with Microsoftâ Visual Studioä -- Development System for Windows® and the Internet. The information in this document is more up-to-date than the information in the Help system. Many of the issues outlined in this document will be corrected in upcoming releases.

This release is provided for evaluation purposes only. It contains pre-release code, documentation and specifications, and is not at the level of performance and compatibility of the final product offering.

This release is confidential and proprietary to Microsoft and its suppliers. Do not disclose or provide copies of this product or any information relating to it to any other party, or use it for any other purpose than as provided in the End User License Agreement without the prior written consent of Microsoft.

NEW   The Visual J++ Technology Preview 2 documentation contains comprehensive documentation about the Visual J++ product and preliminary information about Windows Foundation Classes for Java (WFC). For the latest technical articles on WFC, including a walkthrough of a sample WFC application, a description of WFC graphics programming techniques, and more, be sure to visit the Visual J++ Technology Preview at http://www.microsoft.com/visualj/.

For other issues on the Help system of the Visual Studio suite of products, go to:

MSDNä, the Microsoft Developer Network Readme.

Contents - Click any of the items below

Setup Issues

Documentation Issues

Development Environment Issues

Control Issues

Code Development Issues

Forms Designer Issues

Sample Issues

Visual Component Manager

"Related Files Tab (Component Properties Dialog Box)" topic incorrect

Removing Repository 1.0 Registry Keys

Adding repository tables to an existing .mdb file

Setup Issues

Visual J++ Technology Preview 1 Must be Removed Before Installing Technology Preview 2

To fully uninstall Visual J++ 6.0 Technology Preview 1, you must use the Windows Control Panel. Select Add/Remove Programs from the Control Panel, and double-click "Microsoft Visual J++ 6.0." When prompted, select Remove All.

Minimum Disk Space Requirement to Install Visual J++ Technology Preview 2

For a successful installation of Visual J++ Technology Preview 2 shipped with Visual Studio 6.0, your computer must have at least 140 MB of space available on the drive to which the TEMP or TMP environment variable is set, in addition to the 50 MB needed for the program (total of 190 MB). This space requirement is specific to the setup procedure used for the Technology Preview version.

This issue will be resolved in the final release of Visual J++ 6.0.

Compatibility Issues Between Technology Preview 2 and the Pre-Release of Visual Studio

Do not install the web download of Microsoft Visual J++ Technology Preview 2 on the same system with any pre-release of Visual Studio 6.0 Enterprise Edition. Microsoft will not provide support for such configurations.

Compatibility Issues Between the Visual J++ Technology Preview 2 and the Pre-Release of Office 9.0

Installing a pre-release version Office 9.0 on the same computer that the Visual J++ Technology Preview 2 is installed will prevent both applications from running correctly. This problem will be resolved in the final release of these products.

Interactions with Visual J++ 1.1

There are no known problems with installing this Technology Preview version of Visual J++ on the same computer as Visual J++ version 1.1, as long as you do not install them in the same directory. However, Visual J++ Technology Preview 2 does require the final version of Internet Explorer 4.01 or greater, which affects Visual J++ 1.1 debugging. This known problem with Visual J++ 1.1 debugging and pre-release versions of IE4.0 is described in the Microsoft Knowledge Base article "Q167998 Cannot Debug Visual J++ Programs On IE 4.0 Pre-Release." To view this article, see http://www.microsoft.com/kb/ and type Q167998 in the Search phrase field. To prevent this debugging problem, install Visual Studio 97 Service Pack 3 from http://www.microsoft.com/vstudio/sp/.

Visual J++ 1.1 Project Import Issues

Why is it necessary to "import" a Visual J++ 1.1 project? Projects in Visual J++ 6.0 work differently than they do in earlier versions. The "import" process converts a Visual J++ 1.1 project into a Visual J++ 6.0 project.

While the new projects are improved in many ways over the Visual J++ 1.1 projects, there are certain Visual J++ 1.1 projects that will not import properly into Visual J++ 6.0. Described below is the import process, along with some possible problems and how to work around them.

See the "Directory-Based Projects" help topic in MSDN for a more general description of the differences between projects in Visual J++ 1.1 and Visual J++ 6.0.

How do I import a Visual J++ 1.1 project?

There are two ways to import a Visual J++ 1.1 project, via the project file (.dsp) or the workspace file (.dsw).

Open the project .dsp file.

One .dsp file is created per Visual J++ 1.1 project. Its name is derived from the project name. The .dsp file contains all the project-specific information associated with the project. To import a Visual J++ 1.1 project via the .dsp file, follow these steps:

1. Start Visual J++ 6.0.
2. Select the Existing Tab on the Project Open dialog box.
3. Navigate to the .dsp file that represents your Visual J++ 1.1 project.
4. Double-click the .dsp file.

Open the project .dsw file.

A .dsw file is created when two or more projects exist in the same Visual J++ 1.1 workspace. It contains information that is not specific to a particular project in the workspace. Importing the .dsw file causes all projects enumerated in the workspace file to be imported into Visual J++ 6.0. Thus, importing a workspace that originally contained four projects in Visual J++ 1.1 will result in a solution containing the same four projects in Visual J++ 6.0.

Note that some project types in a workspace cannot be imported into Visual J++ 6.0. In Visual Studio 97, a workspace can contain Visual J++ 1.1 and Visual C++ 5.0 projects at the same time. Importing mixed workspace into Visual J++ 6.0 will result in only the Java projects being imported. Visual C++ 5.0 projects are not imported and are removed from the imported solution file.

To import two or more Visual J++ 1.1 projects via the .dsw file

1. Start Visual J++ 6.0
2. Select the "Existing Tab" on the Project Open dialog box.
3. Navigate to the .dsw file that represents your Visual J++ 1.1 workspace.
4. Double-click the .dsp file.

What happens when a project is imported?

Assume that you have a directory called "MyProj" that contains a project file "Proj.DSP".

MyProj
	Proj.DSP
	foo1.java
	foo2.java
	…

When you import this project in Visual J++ 6.0, a new project file will be created. The default name for the new project is the name of the directory with a VJP extension, for example "MyProj.VJP."

MyProj
	Proj.DSP
	foo1.java
	foo2.java
	MyProj.VJP
	MyProj.SLN
	…

The information from your DSP file will be imported and stored in the VJP file. Some other files that are associated with this project will be created—a Visual Studio solution file (myproj.SLN) and others. In most cases, you can now use Visual J++ 6.0 to edit, compile, and debug your Java project without any further modifications.

Once I've imported, what happens to the old Visual J++ 1.1 project?

After import, Visual J++ 6.0 leaves the original, unmodified Visual J++ 1.1 project file (DSP) in place. We recommend that you do not continue to use the DSP, however. Any further changes to the DSP will not be reflected in the Visual J++ 6.0 (VJP) project. You can re-import the project, but the existing Visual J++ 6.0 project file will be overwritten and any changes you made will be lost.

Why can't I import a Visual J++ 1.1 project that is under source code control?

You can, but you must import it via the file system rather than through the Visual Source Safe browser. Navigate to your enlistment directory and double-click the .dsp or .dsw file. The appropriate project conversions are made.

What features of my Visual J++ 1.1 project won't be imported?

There are some features available in Visual J++ 1.1 projects that won't import properly into Visual J++ 6.0. Here is a list of those features, with suggested workarounds:

• Custom build rules

  For files other than Java source files, Visual J++ 1.1 allowed you to specify a per-file custom build rule. In Visual J++ 6.0, you will need to use the pre- and post-build commands instead. These are available in the Custom tab of the project Properties dialog box.

• Non-adjacent files

  All of the files in a Visual J++ 6.0 project must be in a single directory, or in sub-directories that are contained by a single directory. For instance, if you have the following directory structure:

  MyProj
  	foo1.java
  	MySubProj
  		Proj.DSP
  	foo2.java
  

  In Visual J++ 1.1, it was possible for both foo1.java and foo2.java to be part of the project contained in Proj.DSP. When Visual J++ 6.0 imports Proj.DSP, however, it will only import those files that are in the MySubProj directory or in directories that are contained by MySubProj. You can either move other project files underneath the MySubProj directory, or you can create a new Visual J++ 6.0 project in a directory that contains all of your project files (in this case, that would be the MyProj directory).

• Only debug and release build configurations are imported

  Visual J++ 1.1 supported custom build configurations in addition to the standard debug and release configurations. Visual J++ 6.0 only supports debug and release build configurations, and will only import those configurations from the old project.

• Project build order dependency maps are not imported

  Visual J++ 1.1 build order dependency maps are not imported into Visual J++ 6 projects. You must recreate them using the build order dialog box for the solution. Select the top node in the Project Explorer and press Shift-F4 to view the build order dialog box for the solution node.

Upgrading the Visual J++ 1.1 Compiler for use with the New Microsoft Virtual Machine for Java

Installing Visual J++ 6.0 will update the Microsoft Virtual Machine for Java, which stores the classes in the Package Manager. In order to compile from Visual J++ 1.1, you will need to copy three files (jvc.exe, msjvc.dll, and jps.dll) from the Visual J++ 6.0 compiler directory (an installation in the default directory would put the files in c:\program files\microsoft visual studio\vj98) into the Visual J++ 1.1 compiler directory (an installation in the default directory would put the files in c:\program files\devstudio\sharedide\bin). You will also need to recreate the CLASSES.ZIP file that VJ++ 1.1 uses by running the command line tool "clspack -auto". This will extract all of the class files from the package manager and recreate the CLASSES.ZIP file that VJ++ 1.1 recognizes.

Windows NT 5.0 Installation Not Supported by This Preview

Microsoft Windows NT 5.0 installations are not supported by Visual J++ Technology Preview 2. Setup will fail if attempted on a Windows NT 5.0 system. You must have either Windows 95, Windows 98, or Windows NT 4.0 with Service Pack 3 installed to run this product.

Windows 95 Registry Size: 64KB Limitation May Cause a Warning During Visual Studio Installation

A 64-KB limitation in the size of the SharedDLL key in the Windows 95 system registry may generate a warning to appears when you install Visual Studio 6.0.

Before continuing with setup, you should shorten the install path where you plan to install Visual Studio 6.0, reducing the amount of registry space required.

Additionally, you can uninstall programs you no longer use by utilizing the Add/Remove Programs from the Control Panel. The registry keys used exclusively by those programs will then be deleted.

To save further on registry space used by programs you intend to keep, uninstall, then reinstall these programs to shorter installation paths.

Consider using the RegClean utility, designed to clean up unnecessary entries in your registry. For more information and a download link, go to http://support.microsoft.com/support/kb/articles/q147/7/69.asp

Note   On Windows NT Workstations and Servers, Visual Studio setup will automatically resize the registry.

Internet Explorer 4.01 Setup May Require Two Reboots on Computers that have NT Option Pack 4.0 Installed

If you have previously installed the NT Option Pack 4.0 and are prompted by the Installation Wizard to upgrade Internet Explorer, you may see the following message after IE reboots the system the first time:

"Some services could not be started. Setup needs to reboot your system in order to start the services."

If you experience this problem, you should NOT continue with the Installation Wizard. Accept the IE 4.0 dialog and reboot. Upon the subsequent reboot, launch Visual Studio setup again. Setup will continue where it left off.

Removal of Visual J++ Technology Preview 2 if Installed from Removable Media

If you installed Visual J++ Technology Preview 2 from a removable media drive, such as an Iomega Jaz drive, and you do not have the disk from which it was installed, you should use the following steps to remove the product:

1. On the Start menu, click Settings and then click Control Panel.
2. On the Control Panel, double-click Add/Remove Programs.
3. On the list of program choices, select Microsoft Visual J++ 6.0 and click Add/Remove.
4. Click Remove All. The Uninstall dialog box appears.
5. In the Uninstall dialog box, click Yes. The Setup Message dialog box appears.
6. In the Setup Message dialog box, click Cancel to continue removing the product, or insert the source disk in your removable media drive. Click OK.

   The Setup Message dialog box appears again.

7. Click Yes to continue with the removal of this Technology Preview without the removable media source disk.

   Clicking No will allow you to cancel the removal.

Documentation Issues

Some Documented Sample Programs Are Not Available

Some of the program samples listed in the documentation are not yet available. This is a known problem and will be corrected in a later release.

Code Error in "Creating a Control" Topic

The topic, "Creating a Control," contains a code error. In step 4 of the procedure, "To add an event handler," the code to type should be:

edit1.setText("Position = " + HScrollBar1.getValue());

Documentation Errors in "Creating a Dynamic HTML Application" Topic

Note the following corrections to this topic:

• Your Java class extends com.ms.wfc.html.DhDocument. The template also creates a class that extends DhModule, which is hosted on an HTML page as a COM object, and creates an instance of your document class.
• When you create the project, two Java source files are added: Class1.java and Module1.java. (An HTML page named Page1.htm is also added.)
• The initForm method that appears in Class1.java is used to initialize your code, and is automatically invoked when an instance of Class1 is created.

Procedure for "Using the Microsoft Transaction Server (MTS)" Topic has Documentation Error

The topic "Using the Microsoft Transaction Server (MTS)" contains an error. Step 5 of the procedure has been revised and should read, "In the Arguments box, type /p:"MTS Package name", where MTS Package name is the name of the MTS package containing your component. Also, make sure that there are no spaces in this argument.

Development Environment Issues

Debugging on Windows 98

If you are running Visual J++ on Windows 98, you must do the following before other computers can run debug processes on your computer. You need to run DCOMCNFG.EXE and check the Enable remote connection check box on the Default Security tab. As on Windows NT, you will need to provide access permissions to other users, if applicable, and yourself to run the debug processes.

Windows NT 4.0 Service Pack 4 Required to Debug MTS Components

If you create components for Microsoft Transaction Server using Microsoft Visual J++, you will need the Windows NT 4.0 Service Pack 4 in order to debug them. You can obtain this Service Pack (when it becomes available) from /http://www.microsoft.com/windows/downloads.

Control Issues

Controls Using Windowless Activation Not Supported

Controls using windowless activation are not supported in this Technology Preview of Visual J++.

WFC Controls not Currently Supported as Web Page Content

Problems may occur when a WFC control is placed onto an HTML document. WFC controls cannot yet be hosted directly on HTML documents; however, WFC controls exposed as ActiveX controls can be hosted. This is a known issue and will be addressed in a later release.

Single Threaded ActiveX Controls are not Supported in Technology Preview 2

When attempting to place a single threaded ActiveX control on a WFC form, you will get an error message stating that these controls types will work but are limited in functionality. For Technology Preview 2, all single threaded ActiveX controls will not work. The final version of Visual J++ 6.0 will enable limited single threaded ActiveX control support.

Deleting Rows from the DataGrid Control does not Work with OLE DB Providers in this Release

With some Microsoft OLE DB providers, deleting a row in the DataGrid or deleting a record in the underlying recordset clears the DataGrid of all records. In either case, the record is not deleted from the recordset. This is a known problem and will be addressed in a later release.

Code Development Issues

Templates May Not Display Correctly if Format Settings Are Changed

By default, all templates are formatted with tabs (not spaces). If you want to change the format settings to use spaces instead of tabs, the templates will still have tabs in them. The workaround for this is to load the actual template .java file and then save it using spaces instead of tabs.

Projects Created With Code-Behind HTML Template Will Not Run Correctly on Client Computers if Only Standard Version of Internet Explorer 4.0 or 4.1 is Installed

Projects created with the Code-Behind HTML template will not run correctly on client computers that have only the Standard version of Internet Explorer 4.0 or 4.1 installed. These installations must be updated to include the same version of the Microsoft Vitural Machine for Java and the Windows Foundation Class Libraries that are installed with this product.

Specifying Output Directory as a Parent Directory of the Project will not Create DLL and EXE Output Types Correctly

If the project directory is a sub directory of the output directory specified on the Compile tab of the Project's Properties dialog box, certain resources will not be found when attempting to run a DLL and EXE output type. For example, if the project directory is set to "c:\my projects\com\company\sales" and the output directory is set to "c:\my projects" and the project is set to create a DLL or EXE, certain resources may not be correctly packaged into the DLL and EXE output. When this project is run, you will get a 'com.ms.wfc.core.WFCException was not handled' dialog. If you click yes to debug, you will see that it's failing on a call to 'com.ms.wfc.core.ResourceManager.getObject'. To fix this, set the output directory to be a sub directory of your project directory, such as "c:\my project\com\company\sales\debug" or under a different tree altogether, such as "c:\my projects\debug".

Java Files Created in Pre-Build Rules Are Not Built

Java files that are created in pre-build rules will not be built the first time the project is built. An example of this would be a project with a pre-build rule that uses jactivex to create Java wrappers. The first time the build is run, the new Java wrappers will appear in the project, but will not be built. Building a second time will build the new files.

Workarounds for this are:

1. Build the project a second time; now that the new Java files are there, they will build.
2. Create dummy Java files matching the names of the files that will be created in the pre-build rules.

Writing Add-ins for Visual J++

Visit the Microsoft Visual J++ Web site to download the Add-in Wizard. This is a single DLL that fully installs itself when you invoke regsvr32 on the DLL. The next time you start Visual J++, in the Visual Studio folder of the New Project dialog box, there will be a Visual J++ Add-in project that you can select. Creating one of these projects launches the wizard. The wizard creates a basic add-in that you can run immediately after you finish using the wizard. The wizard lets you supply a display name for the add-in (which appears in the Add-in Manager dialog box) and a description for the add-in. You can optionally choose to have the wizard generate the code to add a command to the Tools menu for invoking the add-in once it is loaded into Visual J++. After using the wizard to create a basic add-in, you can add project items for WFC UI to create add-ins that seamlessly integrate with Visual J++. If you do not install Visual J++ in the default location, then you will need to modify the project settings for the add-in project to correct the pathname for the alternate launch program (devenv.exe).

Potential Problem using DataBinder with Bindings set to DHTML Controls

In this release, DataBinder with bindings set to DHTML controls is not able to automatically update, add, or remove records from databases in the way that is possible when the bindings are set to WFC controls. Writing to the database must be done directly with methods provided by the Recordset, Field, and Fields classes. This issue will be addressed in a later release.

Forms Designer Issues

Copied Controls May Need New Event Handlers

When you copy and paste a control in the Forms Designer, the new copy of the control will, by default, have its events handled by the same handler methods as the original control. To create new handlers for the new control's events, follow these steps:

1. Select the new control in the Forms Designer.
2. In the Properties window, click the Events button to display the event handlers for the control.
3. Highlight each of the handler names in the right column and, once selected, delete them.
4. Add new handlers.

Live Control Development

A control in development can be hosted on a form that exists in the same solution as the control. Changes to a control, however, will not be reflected in the hosting form's designer until the control's project is rebuilt, and the designer is closed and reopened.

Sample Issues

Location and Instructions for Using Sample Programs

Please note that Visual J++ samples for Technology Preview 2 are currently only available from the Visual J++ Web site at http://www.microsoft.com/visualj. Please follow the links to download and install the samples. Be sure to revisit our Web site frequently for updates.

Sample Code Sometimes Does Not Cut and Paste Properly

Line breaks and formatting information may not copy correctly when you copy and paste sample code from the MSDN Library Visual Studio documentation to your code editor. To work around this issue, do one of the following:

• Manually edit the line breaks after you copy the code.
• View the sample code source, copy the entire code sample, including the <pre> and </pre> tags, paste it to your code editor, and then delete the unwanted sections from the pasted version.

Windows Foundation Classes (WFC) Issues

Changes to WFC in Technology Preview 2

As we strive to improve the quality of the Microsoft Windows Foundation Classes between the various Betas, many things have changed that will make code written against Microsoft Visual J++ Technology Preview 1 not compile in Technology Preview 2.

The following is a list of some of the more common things that users will run into:

• The package name for WFC has changed. Instead of being wfc.*, it is now com.ms.wfc.*. For example, Button used to be wfc.ui.Button, it is now com.ms.wfc.ui.Button. The import statement at the top of all your Technology Preview 1 files will need to be changed to reflect this.
• Many properties, methods, and events have changed names. Often, they only need to be renamed, such as changing getAlignText to getTextAlign (typically to be more consistent between controls), but sometimes multiple properties have been merged into one property, or one property is broken into multiple properties. An example of the combining multiple properties would be the "center", "stretch", and "autoSize" properties becoming the "sizeMode" property for the PictureBox control.
• Forms that contain resource files (images and so forth) will not load in Technology Preview 2. If you have an application that was localizable in Technology Preview 1, then you should load the form in Technology Preview 1, set the "localizable" property to false, and resave the form before upgrading to Technology Preview 2.
• The constructors for many objects have changed. Most notably, the Font object now has a different set of constructors.
• Control.setStyle is no longer public. The functionality of this method is exposed in other properties.
• The mode constants for opening a file are no longer in the File class. They are in the FileMode, FileAccess, or FileShare classes.

Note   Since Technology Preview 2 is not a final release of WFC, ongoing improvements may result in future changes to the WFC classes and methods. Specifically, between this TP2 release and the retail release later this year, some changes may affect your code. We will make every effort to document those changes in the final product, as we have above.

Solution Building, Packaging, and Deployment

General Notes

If you are installing Visual J++ or Visual Studio on NT5 (beta), you will also need to install signcode.exe from the NT5 NTSDK or the IE INETSDK for NT5, and then ensure that signcode is on the Windows path.

Known Problems in Solution Building, Packaging, and Deployment

Microsoft FrontPage Extension Support Limited When Using Microsoft Development Environment Deployment Feature

When using the Microsoft development environment deployment feature, you should be aware that servers which have the FrontPage acceptor installed as the default acceptor cannot support posting to URLs which contain non-7-bit characters. This is because the FrontPage acceptor is non-UTF8 compliant, and Visual Studio encodes all URLs in an encoded UTF8 format so that deployment between computers having different code pages is possible. When posting to a server which has the FrontPage acceptor installed as the default acceptor, URLs should be formed from characters in the range 0x20 through 0x7f (32 through 127).

If the server supports Posting acceptor 2.0 as the default acceptor, then this limitation does not occur.

Microsoft Development Environment Self-Extracting Package/Installation Feature Cannot Decipher Multi-Byte Character Set (MBCS) Characters Defining the TMP Environment Variable

Running a self-extracting executable created by the development environment self-extracting package/installation feature on an international operating system that allows the use of MBCS characters (for example, Japanese, Chinese, and so on) will fail if the TMP environment variable is set with MBCS characters. To solve this problem temporarily, you can change the TMP environment variable to use Single byte characters instead.

To temporarily change the TMP variable to Single byte characters

1. On the target computer, create a new dir using Single byte characters: c:\temp.
2. Open an MS-DOS window and run the command, "set TMP=c:\temp".
3. Type "set" to verify that the TMP variable was set properly.
4. Execute the installer from this MS-DOS window.

Any executable launched from within the MS-DOS window will use the temporarily set TMP variable until the window is closed.

Deploying and Debugging Updated Visual J++ Authored COM Servers that Run in IIS

You can deploy Visual J++ authored COM servers that are called from ASP pages in Microsoft Internet Information Server (IIS). Once IIS has executed an ASP page that loads a Visual J++ authored COM server, IIS will cache the server in its internal storage. If you then deploy an updated version of the COM server to IIS and try to execute it, the new version will not be loaded, and IIS will continue to use the old version until IIS is stopped and restarted.

To make IIS use the updated version of the COM class by restarting IIS

1. On the Microsoft Windows NT system, go to the Start menu and click Windows NT Option Pack. Click Personal Web Manager or Microsoft Internet Information Server.
2. If you are using the Personal Web Manager, click Personal Web Manager, and then click Stop on the Main page.

- or -

2. If you are using the Internet Service Manager, click Internet Service Manager, and expand the IIS node. Expand the computer's node. Select the Default Web Site and click the Stop button on the IIS toolbar.
3. Restart IIS using the Play button.

External Dependency Download Limitations in Internet Explorer 4

You can build a .cab file distribution unit with an external dependency in another .cab file distribution unit, so that both distribution units will be downloaded to the client computer when the client views the Web page that hosts the distribution unit. However, be aware that Internet Explorer 4 does not track changes to the versions of external dependencies -- creating a situation in which the first .cab file is downloaded but the updated dependency is not.

For example, if you modify both distribution units, update their version numbers, and update the dependency's version number in the External Dependency tab of the Cabinet Properties dialog box, the first .cab file will be downloaded, but the second will not.

To resolve this, you might change the friendly name of the second .cab file distribution unit. This will cause the second .cab file to be downloaded again. Be aware that both versions of the .cab file distribution unit will now be installed on the client computer.

FrontPage Servers Require a 7-bit URL for Deployment

Microsoft Visual Studio supports deployment between computers with differing code pages. It does this by converting the URL to a tokenized UTF-8 format, so that characters outside of the range 0x20 - 0x7f can be used in URLs. Thus, if you specify the following URL on an English computer for your deployment target:

http://myserver/ÜÖ

The characters Ü and Ö are hi-ASCII and are not necessarily supported outside of the scope of the current code page, and so the URL used internally for the purpose of deployment will be:

http://myserver/%c3%9c%c3%96

since 0xc3 0x9c is the UTF-8 representation of the hi-ASCII character Ü, and 0xc3 0x96 is the UTF-8 representation of the hi-ASCII character Ö. The server will then "decode" this URL, and place the files in the appropriate location, so that from the client computer you can still access the deployed files by using the URL "http://myserver/ÜÖ/{name of the file}".

A problem occurs, however, because FrontPage servers do not understand tokenized URLs, and will interpret the encoded URL literally without decoding it. Thus, if you deployed a solution to a FrontPage server, and used the URL "http://myserver/ÜÖ", Microsoft Visual Studio may indicate that the files were deployed successfully, but the files will in fact be deployed to "http://myserver/%c3%9c%c3%96". You will therefore be unable to access the files, either for browsing or debugging, by using "http://myserver/ÜÖ/{name of the file}".

Because of this limitation, it is important to use only 7-bit characters in URLs when deploying to FrontPage servers; specifically, characters in the range 0x20 - 0x7f (Microsoft Visual Studio does not encode the "space" character 0x20 in deployment URLs). Hi-ASCII and MBCS characters should be avoided when deploying to FrontPage servers. Alternately, you can install Microsoft Posting Acceptor 2.0 on the server, which fully supports UTF-8 encoded URLs for deployment. See the installation documentation for instructions on how to install Posting Acceptor 2.0 onto your server from the Microsoft Visual Studio CDs.

Build May Fail on Computers with Anti-Virus Software

If you build a setup distribution unit that contains large files on a computer that has anti-virus software installed, the build process can fail with file access errors. If this happens, try turning off the anti-virus software on that computer.

Deployed HTML Files Can Get Corrupted If Quotes Are Not Put Around Certain Values

If you include delimiting characters when assigning values to tag attributes in HTML files -- such characters include semicolons, colons, or angle brackets -- the values must be contained within quotation marks, as per W3C standards. The HTML editor in Microsoft Visual Studio does not do this, and in fact will remove quotation marks from values when an HTML file is loaded into the editor. Therefore, when the deployment engine updates the file's CODEBASE links, the deployment parser may stop reading in the value when the first standard HTML delimiter is encountered. If this happens, only part of the value will be saved back to the file before the file is actually deployed. (The deployment engine works with a temporary copy of the file, so the original is unaffected by this.)

To avoid this problem, manually put quotes around the values which contain delimiters before deploying the file. You will need to do this whenever you open the HTML file for editing in the Visual Studio HTML editor, since the editor will strip the quotation marks when the file is reopened, or the view type in the editor is changed.

Deploying Server Component Fails If the Specified Destination is a Floppy Drive

If you specify the floppy drive of a network server computer as the destination for server component installation for deployment, the deployment will fail even if no error messages are given. This is due to an inability to create folders on the floppy drive.

To correct the problem, right-click on the Server Components service in the deployment target and select "Deployment Target Settings." In the resulting dialog box, change the installation drive and directory so that a hard drive location on the network server is specified. (Since the default location for server component installation is the C: drive, users deploying to NEC PC's will want to change that default location, as C: may specify a floppy drive on those machines.)

Default Registration of COM Classes in Java Packages

The default naming convention for the registration of COM components is projectname.classname, regardless of the Java packaging of each COM class. A build error will result if you attempt to create two COM classes with the same name in the same project, even if they are in different Java packages. To create classes with the same name in different packages, you may deliberately specify a progid for the class using the "progid=" parameter in the @com.register tag. As an example convention, you could specify "progid=projectname.packagename.classname " in the @com.register tag for each of the COM classes.

Visual Component Manager

Known Problems in Visual Component Manager

"Related Files Tab (Component Properties Dialog Box)" topic incorrect

Visual Component Manager User Interface Reference: The topic "Related Files Tab (Component Properties Dialog Box)" incorrectly states that the tab is used to display and enter files that are related to the selected component. In fact, none of the information displayed on this tab can be modified. You can add related files to a component only when publishing or re-publishing the component. For more information, search online, with Search titles only selected, for "Publishing Components" in the MSDN Library Visual Studio 6.0 documentation.

Removing Repository 1.0 Registry Keys

If you installed VCM 5.0 (previously available for Web download) you will have the following Windows Registry keys setup. They were necessary for VCM 5.0 and the 1.0 version of the Repository. If you find the following Registry entries then it is safe to remove them and may, in fact, improve VCM 6.0 performance.

• HKEY_LOCAL_MACHINE\Software\Microsoft\Repository\CacheMaxAnnProps
• HKEY_LOCAL_MACHINE\Software\Microsoft\Repository\CacheMaxObjects
• HKEY_LOCAL_MACHINE\Software\Microsoft\Repository\CacheRelshipMaxCollections
• HKEY_LOCAL_MACHINE\Software\Microsoft\Repository\CacheRelshipMaxRows
• HKEY_LOCAL_MACHINE\Software\Microsoft\Repository\MaxRowCacheAge

Adding repository tables to an existing .mdb file

If you try to open an existing .mdb file from within VCM that is not a repository database (i.e., it does not contain the repository structure/tables), you will be asked if you want the repository tables added to the database. You should not do this for normal use; the repository should generally be in a separate database. This will work, but it can take as long as 10 minutes to create the repository structure in an existing .mdb file.

To create a brand new .mdb file containing the repository structure, right-click in the folder outline, click Repository, click New, and then enter the name of the file you want to create.