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):
|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:\.
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.|