-
I've been developing a solution that I need to access data in a large DB. Ran into infrastructure issues at multiple clients, IT says NO SQL server allowed. My bypass of that is a TCP "service" that uses SQLite as the DB. The catch is the solution must be accessed through VBA, not an MS Office front end. Using .Net 4.7.2 COM exposed class library to accomplish this. That said, I have a successful WatsonTCP server built and tested with WatsonTCP.Test.Client app. But when I add the client into the class library (.net 4.72) and test using nunit 3. I never get the response message back from an internal authenticate, NOT SSL auth process. The server fails in send: if(!_Client.Send(.....)) response with Failed message per the server log. The client side MessageReceived(object sender, MessageReceivedEventArgs args) never gets called.
The Nunit test looks like
Here is the server side log I get:
The lines: 2022-01-27 15:42:18.267 and 2022-01-27 15:42:18.279 are from the class library NUnit test Here is the WEatsonTCP.Test.Client side Console Log:
Is there something I should be doing in my NUnit test to ensure the class library actually receives the response? I think the test is terminating before the server can send the response. Do I need to run the client as a task? The sample does not look like it would. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Well after much review of the overall process and the fact that in the Class Lib I could not get an Invoke of my logging call, I switched to Client.SendAndWait(). This solved my issues and provided a cleaner request/response handshake process and it'll remove the need to provide what command triggered the response. Here is the server side code yet to remove the command kick back:
|
Beta Was this translation helpful? Give feedback.
Well after much review of the overall process and the fact that in the Class Lib I could not get an Invoke of my logging call, I switched to Client.SendAndWait(). This solved my issues and provided a cleaner request/response handshake process and it'll remove the need to provide what command triggered the response.
Here is the server side code yet to remove the command kick back: