3

I have a c# Framework 4.7.2 Com visible library that calls a web api.

Unit tests in the VS2017 C# IDE library work fine.

However if I try to call via VB6 I get

System.IO.IOException unable to read data from the transport connection: An existing connection was forcibly closed by the rempte host.

System.Net.Sockets.SocketException

I am running Windows 10

I call as administrator

C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm /codebase /verbose  /tlb:SBD.ComBridge.tlb C:\dev\SBD.ComBridge.dll

to create the .dll and .tlb

I also tried running regasm from the VS2017 command prompt as administrator

RegAsm reports that the libraries register successfully.

In Vb6 the (simplified) code is

Dim o As SBD_ComBridge.BridgeImplementation
Set o = New dBridgeImplementation
o.SetOrderDates id 
set o = nothing

In BridgeImplementation the (simplified) code is 

[DispId(25)]
[ComVisible(true)]
public void SetOrderDates(int Id)
{
     PackAndSend.SetReadByInfo(Id) // calls freight service
}

I know that the code calling the service from within SetReadyByInfo works because my unit test passes when I run it in VS2017

Unfortunately I have been asked not to post the code. However I know that the vb6 code calls Com correctly because there are other methods I call without errors.

I had a similar issue with MYOB api and TLS the solution was to upgrade the Framework. However I can't upgrade the VB6 framework ( the large re-write is not an option) Probably I will just make a .Exe and shell out to it.

[Update]

The link Simon Mourier gave me solves it. If I add 

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

then my com call works on VB6

As the link points out,

This isn't a good solution since it hard codes what TLS version to use, so it wouldn't use TLS 1.3 in future

Kirsten
  • 15,730
  • 41
  • 179
  • 318
  • 1
    Going to have to show some code, both the calling VB6 code and probably the .NET side too. – tcarvin Aug 27 '19 at 12:16
  • Is `PackAndSend.SetReadByInfo` a blocking call? It is a .NET exception so I think the next set of code to post is that. – tcarvin Aug 27 '19 at 21:03
  • If you are getting a .NET exception then your VB6 code *did* call the .NET library. If there is any question on whether or not your VB6 code is loading and calling your .NET library, create a no-op method in the .NET library and call that first. If that succeeds then we know your are doing basic .NET / COM interop correctly. Then we can look at `PackAndSend.SetReadByInfo`. I understand you called it from a unit test, but I bet your unit test is not getting called from an STA threaded 32-bit application to simulate a VB6 program. One step at a time though. – tcarvin Aug 28 '19 at 11:51
  • If you know the VB6 is calling into the C# `SetOrderDates` correctly, and that code only calls `PackAndSend.SetReadByInfo(Id)`, then the logical next step is to list the source code of that method. The goal is to review all source code called to see what there might take issue with being called from a VB6 process. Also, please post the full stack trace of your exception, that would be extremely informative. – tcarvin Aug 29 '19 at 14:59
  • Thanks @tcarvin I updated the question to explain I can't do this and deleted some of my chat comments. – Kirsten Aug 30 '19 at 00:54
  • 2
    As you found out, TLS is probably the issue. But you shouldn't have to upgrade anything if the machine and the installed .NET framework support TLS 1.2 (which seems to be the case since you say it works with other programs) Your VB6 exe is probably not using the good .NET Framework (there can be more than one installed on a given machine), or not using the configuration that works. Check out the answers here, for example: https://stackoverflow.com/a/44765698/403671 (adapt to your context) – Simon Mourier Aug 30 '19 at 09:30
  • 1
    Based on @SimonMourier links, you could probably just use code to explicitly set ` ServicePointManager.SecurityProtocol` as desired. You could try the config file route, but since VB6 is the host app, I'm not sure a config-file based approach will work. – tcarvin Aug 30 '19 at 12:12
  • @SimonMourier many thanks! – Kirsten Aug 30 '19 at 23:39
  • 1
    Thanks :-) If you found the solution, you should answer yourself with some details of what you did to make it work. – Simon Mourier Aug 31 '19 at 06:40

1 Answers1

0

As per the update section at the bottom of my question, a work around is to include

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

I need to investigate further for a more complete solution

Kirsten
  • 15,730
  • 41
  • 179
  • 318