Release Notes for OGSI.NET 2.1

1. If you have been using a previous version of OGSI.NET and you have re-compiled the main OGSI.NET assemblies (those in the UVa.Grid namespace), the uninstaller distributed with OGSI.NET may not completely uninstall your version. If you are having problems installing the current version of OGSI.NET, try the uninstaller and then perform the following (if they have not already been done):
  • delete the entry HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\AddIns\AddGridReference.Connect                 from the registry
  • remove the OGSA and Schema directories from your Inetpub directory (e.g. c:\Inetpub)
  • remove the ISAPI filter (Go to the IIS control panel, right-click on "Web Sites" and choose "Properties". Then select the "ISAPI filters" tab on the dialog box that appears. You should see an entry titled something like "OGSIdotNetIsapiUrlFilter". Select it and click on the "Remove" button. Now, restart IIS.)
  • remove the directory in which OGSI.NET is installed
2. The solution and project files for OGSI.NET's container and browser are installed under the OGSIdotNetServer\Src and OGSIdotNetClient\Src directories of the path given to the install program (e.g. c:\Program Files\UVAGCG). However, OGSI.NET uses strong names for its libraries and these libraries are signed with the UVAGCG key. This key is not distributed with OGSI.NET. You must generate your own keys to sign the OGSI.NET dlls, if you wish to modify and recompile the server dlls. The easiest way to do this is to use the "sn" utility to generate new keys with the same name as the UVAGCG keys. This is done as follows:

1. From a VS.NET command prompt (Start->Programs -> Microsoft Visual Studio .NET 2003 -> Visual Studio .NET tools -> Microsoft Visual Studio .NET 2003 command prompt), run "sn -k UVaGCG.snk"

2. copy the file UVaGCG.snk to a directory called c:\GCGKeys. Note that this must be in c:\.

3. The Configuration directory of the OGSI.NET Server install (e.g. c:\Program Files\UVAGCG\OGSIdotNetServer\Configuration) contains files used to configure the OGSI.NET container. The file OGSI.config is used to provide parameters to the various services that OGSI.NET starts automatically when the container is started. The <globalConfiguration> section container parameters passed to every service. An important parameter is "schemaRoot". This parameter provides the base path to the web server that serves up the WSDL files for services running in the OGSI.NET container. The default value is "http://localhost/".

The value of this parameter has implications for the WSDL generated for any service running in the OGSI.NET container. Any "import"  statements in a WSDL file generated by OGSI.NET for a service will use the schemaRoot parameter in generating the import location. This means that if the schemaRoot parameter is set to http://localhost/, any import statements in a service's WSDL will try and import the specified file from http://localhost/.... This means a client receiving this WSDL file will try and import the associated files from http://localhost/. While this works when the client and server are on the same machine, or when the client is running on a machine that has the same WSDL installed on it as is installed on the server, it is not a general solution.

We recommend setting the schemaRoot parameter to the name or IP address of the machine running the OGSI.NET container (e.g. <parameter name="schemaRoot" value="http://abbott.cs.virginia.edu/"/>) if that machine has a fixed IP address. For machines without fixed addresses, such as laptops on wireless networks, it is probably best to leave the parameter set to http://localhost/, but understand that when accessing a container running on that machine, the client must either also be on that machine, or the client must be running on a machine that has the same WSDL files installed as the server machine (see the OGSI.NET tutorial and Programmer's Reference for details on how to install WSDL for your own services). Note that often just installing OGSI.NET on both client and server machines is sufficient. 

If you modify the OGSI.config file, you must restart the container. You can do this from the Services control panel (Start -> Settings -> Control Panels -> Administrative Tools -> Services). Select "OGSIContainerService" from the right hand panel and click "Restart" from the left hand panel.

4. The included solution and project files are compatible with VS.NET 2003 Pro, the latest release from Microsoft. They are not compatible with VS.NET 2002. Upgrades are free to MSDN subscribers or they can be purchased from Microsoft.
5. OGSI.NET 2.1.6 is compatible with WSE 2.0 SP2. Its installer checks for WSE 2.0 SP2 and prompts you to install it if it is not present.