M
matths
We have created a very simple user control (System.Windows.Forms.UserControl)
by making a new VB.NET Windows Control Library Project in Visual Studio 2003
(named VPControls.CtlGraph). The user control contains a graph control
(GSNetWinChart from GraphicsServer). We have successfully displayed the
control on PCs with 1.1, 2.0 and 3.0 .NET Frameworks installed. We ship 2
..msi files with our product that set the .NET security levels to 'Full Trust'
for both the 'Local Intranet' and 'Trusted Sites' zones.
The control is embedded into a web page that is served from an AS/400 host
(Apache) using the Object directive similar to this:
<object align="center" id="graph" width="100%" height="50%"
classid="VPControls.dll#VPControls.CtlGraph">
<param name="GraphTitle" value="DERIVED_01 by Cust Number">
<param name="RowOrder" value="1">
<param name="Selection" value="2|4|8|4">
<param name="ViewData" value="Cust Number~State~Current Balance Due~Credit
Limit~DERIVED_01^100700~CA~.00~20000~20000.00^126100~CA~.00~30000~30000.00^126500~CA~3000.00~10250~7250.00^218211~CA~26250.00~30000~3750.00^105400~CA~366.09~7000~6633.91^200200~CA~3883.67~61000~57116.33^200700~CA~.00~21000~21000.00^202900~CA~.00~36000~36000.00^203100~CA~.00~31000~31000.00^">
<param name="Active" value="true">
</object>
The problem is that the control simply does not work on certain computers
and/or networks, displaying the dreaded 'Red X' that tells me nothing about
why it is not loading. None of the computers on our network seem to have
this problem, and most (90%+) of our users have no issue. We are an ISV, so
we sell our product into hundreds of different environments. We go through
the following trouble shooting steps (the print screens have been removed)
but nothing seems to indicate a problem. Are there any further resources or
places to look for resolution of this problem? Thanks for any assistance
that you can give:
________________________________________________________
Here's the basic steps to debug SWI graph issues(.net troubleshooting):
1. Run http://SERVER_NAME/sequel/dotnet.html and (e.g.
http://rush/sequel/dotnet.html) verify that .NET CLR 1.1 or higher is
loaded. Some users may have multiple .NET versions. This should not be a
problem.
2. Make sure that the /sequel/swi/swi.msi and swi20.msi have both been run
3. Make sure that they are using Internet Explorer!
4. Make sure that the site is in the list of 'Trusted Sites'. There should
be an icon in the IE status bar that says 'Trusted Sites' :
5. Make sure that their security is set to 'default' or lower for 'Trusted
Sites' (i.e. Medium, Medium-Low, or Low). You can click the 'Sites' button
here to add the current site to the list of trusted sites.
6. If that fails, then there is a .net log that gets generated if it is a
..NET issue. In IE 7, you can do Tools:Internet Options, click on the
'Settings' button in the 'Browsing History' section of the page, click 'View
Files' and look for something like '?FusionBindError!name=VPControls.dll' -
it should have details about why .NET didn't work.
7. Enable IE logging as follows:
a.Click Start, click Run, type regedit, and then click OK.
b.Locate and click the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework
c.Add a DWORD value named DebugIEHost to this key; assign it any non-zero
value.
d.Add a string value named IEHostLogFile. Assign it the full path (including
the file name) of the file in which you want to record the debug trace (for
example, C:\Temp\IEDebug.log).
8. There could be an error in the Apache server. There are log files that
are generated constantly that have information about files that are served.
On our system those log files are in /www/goodapache/logs (i.e.
/ROOT/WWW/INSTANCE_NAME/logs). They are called access_log.xxx and
basic_error_log.xxx and are continually written to until the instance is
stopped.
9. Final step if nothing seems to fix the problem and requested by
developer: download the .NET 2.0 runtime
http://www.microsoft.com/downloads/...cb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en
, install it (it won't overwrite the 3.0 runtime), run the swi20.msi again,
and see if that takes care of that issue.
by making a new VB.NET Windows Control Library Project in Visual Studio 2003
(named VPControls.CtlGraph). The user control contains a graph control
(GSNetWinChart from GraphicsServer). We have successfully displayed the
control on PCs with 1.1, 2.0 and 3.0 .NET Frameworks installed. We ship 2
..msi files with our product that set the .NET security levels to 'Full Trust'
for both the 'Local Intranet' and 'Trusted Sites' zones.
The control is embedded into a web page that is served from an AS/400 host
(Apache) using the Object directive similar to this:
<object align="center" id="graph" width="100%" height="50%"
classid="VPControls.dll#VPControls.CtlGraph">
<param name="GraphTitle" value="DERIVED_01 by Cust Number">
<param name="RowOrder" value="1">
<param name="Selection" value="2|4|8|4">
<param name="ViewData" value="Cust Number~State~Current Balance Due~Credit
Limit~DERIVED_01^100700~CA~.00~20000~20000.00^126100~CA~.00~30000~30000.00^126500~CA~3000.00~10250~7250.00^218211~CA~26250.00~30000~3750.00^105400~CA~366.09~7000~6633.91^200200~CA~3883.67~61000~57116.33^200700~CA~.00~21000~21000.00^202900~CA~.00~36000~36000.00^203100~CA~.00~31000~31000.00^">
<param name="Active" value="true">
</object>
The problem is that the control simply does not work on certain computers
and/or networks, displaying the dreaded 'Red X' that tells me nothing about
why it is not loading. None of the computers on our network seem to have
this problem, and most (90%+) of our users have no issue. We are an ISV, so
we sell our product into hundreds of different environments. We go through
the following trouble shooting steps (the print screens have been removed)
but nothing seems to indicate a problem. Are there any further resources or
places to look for resolution of this problem? Thanks for any assistance
that you can give:
________________________________________________________
Here's the basic steps to debug SWI graph issues(.net troubleshooting):
1. Run http://SERVER_NAME/sequel/dotnet.html and (e.g.
http://rush/sequel/dotnet.html) verify that .NET CLR 1.1 or higher is
loaded. Some users may have multiple .NET versions. This should not be a
problem.
2. Make sure that the /sequel/swi/swi.msi and swi20.msi have both been run
3. Make sure that they are using Internet Explorer!
4. Make sure that the site is in the list of 'Trusted Sites'. There should
be an icon in the IE status bar that says 'Trusted Sites' :
5. Make sure that their security is set to 'default' or lower for 'Trusted
Sites' (i.e. Medium, Medium-Low, or Low). You can click the 'Sites' button
here to add the current site to the list of trusted sites.
6. If that fails, then there is a .net log that gets generated if it is a
..NET issue. In IE 7, you can do Tools:Internet Options, click on the
'Settings' button in the 'Browsing History' section of the page, click 'View
Files' and look for something like '?FusionBindError!name=VPControls.dll' -
it should have details about why .NET didn't work.
7. Enable IE logging as follows:
a.Click Start, click Run, type regedit, and then click OK.
b.Locate and click the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework
c.Add a DWORD value named DebugIEHost to this key; assign it any non-zero
value.
d.Add a string value named IEHostLogFile. Assign it the full path (including
the file name) of the file in which you want to record the debug trace (for
example, C:\Temp\IEDebug.log).
8. There could be an error in the Apache server. There are log files that
are generated constantly that have information about files that are served.
On our system those log files are in /www/goodapache/logs (i.e.
/ROOT/WWW/INSTANCE_NAME/logs). They are called access_log.xxx and
basic_error_log.xxx and are continually written to until the instance is
stopped.
9. Final step if nothing seems to fix the problem and requested by
developer: download the .NET 2.0 runtime
http://www.microsoft.com/downloads/...cb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en
, install it (it won't overwrite the 3.0 runtime), run the swi20.msi again,
and see if that takes care of that issue.