|
|
Rank: Advanced Member
Groups: Member
Joined: 9/4/2007
Posts: 114
|
Hello, We have been using Live Help (www.dotnetlivehelp.com) for about a year now. Recently, we implemented the EO AJAXUploader control on our website. The documentation for the AJAXUploader control, specifies a required entry in the web.config file to ensure requests for uploads are handled properly. e.g.:
Code: HTML/ASPX
<httpModules>
<add name="EOWebRuntime" type="EO.Web.Runtime,EO.Web"/>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</httpModules>
Unfortunately, the EOWebRuntime entry results in a LiveHelp applicaiton connection failure when accessing the Operator Console. The LiveHelp icon also does not appear on the website. Are you aware of this type of issue, or know why there is a conflict with LiveHelp ( or other) controls? Thanks, Duane
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
We are not aware of any of such issues. Our module acts as a "filter" to check all the request to see if it is from the uploader, if it is from the uploader, then we process it accordingly; If it is not, then we ignore it and it continues to go down the pipe line. So in theory it should not cause any problems.
Have you contacted LiveHelp support about this yet? They might be able to pin point the exact point of failure on their side because it fails inside their code. Once we have those information, we will try to simulate the same scenario without LiveHelp (because we do not have LiveHelp's source code and can not trace into it) and we can then go from there.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 9/4/2007
Posts: 114
|
Apparently .netLIVEHELP is not aware of any such conflict. The original error condition did not pinpoint the location of the error. I'll see if I can get more info. I got the below reply from .netlivehelp support before I posted here:
No, we have not heard of such a case before. We would suggest you create another application for your site in IIS to run your uploader in to avoid the conflict. -- Information .netLIVEHELP http://www.dotnetlivehelp.com
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
Setting up a separate IIS application may not be an option because it would significantly change the application structure. The issue at here is because the problem surfaces inside their code and our implementation is based on standard ASP.NET frameworks. So we are not even sure whether it is our problem at all. We are not saying it's definitely their problem, but because we don't have access to their source code, so if we were to dig it we at least need them to dig with us together. They will have to dig the first layer and if that produces a valid scenario to reproduce the problem without their whole product with closed source, we will be happy to take over. Before that we are not in a position to investigate or make changes to our product just because it does not appear to work with another black box; not only because we are not even sure whether it is rooted in our product, but also because we have no way to technically come up a clean solution without knowing what’s causing their code to fail.
Thanks
|
|