3rd party DLL refuses to work properly with ASP.NET but works in console application RRS feed

  • Question

  • User-1206059511 posted

    I'm trying to build a REST API for a local running application/service which provides a DLL to connect and exchange data with it (over a TCP connection).  When I use the DLL in a regular .NET console application, it works as expected and I can interact with it no problem.  When I try to use it the exact same way in an ASP.NET application, it doesn't even seem like it's attempting to connect.  I'm using Wireshark to look at TCP traffic on the service's port (5330), and when the ASP.NET application calls the library's `Connect()` function, there is no TCP traffic -- I DO see TCP traffic with the console application, however.  I have no idea why it would behave any differently in the web app.  I've tried using different host strings: localhost,, and my LAN IP, but I get the same results.  The .NET version is the same between the two.  I've also verified that I can open a raw TCP connection from the ASP app and send and receive data, just for the sake of trying to narrow down the issue.

    I'm on Windows 7 64-bit using Visual Studio 2019, .NET 4.5.2, and C#.

    In my application's `Global.asax.cs` file's `Application_Start()` method for simplicity:

    // Create the server object
    ServerConnection asiServer = new ServerConnection();

    // Set the host address we want to connect to

    // Get the configuration object

    asiObject commObj = asiServer.ConfigurationService.FindObjectById(524, false);

    catch (Exception ex)

    The session ID that is output is "0", indicating no connection, then the below exception is thrown:

    Exception thrown: 'AutoSol.ACM.Client.Exceptions.RemoteServerException' in AutoSol.ACM.Config.Client.dll
    AutoSol.ACM.Client.Exceptions.RemoteServerException: Object reference not set to an instance of an object.
    at AutoSol.ACM.Client.ConfigurationService.a(Exception a)
    at AutoSol.ACM.Client.ConfigurationService.a(Int32 a, Boolean b)
    at AutoSol.ACM.Client.ConfigurationService.FindObjectById(Int32 ObjectId, Boolean IncludeProps)
    at AutosolRestAPIDotNetFull.WebApiApplication.Application_Start() in C:\Users\matt\source\repos\AutosolRestAPIDotNetFull\AutosolRestAPIDotNetFull\Global.asax.cs:line 41

    I've also tried putting the code directly in a controller's route with the same results.  I have no idea what's happening here.  Any help would be greatly appreciated.  And please let me know if I can provide any further information.

    Friday, May 1, 2020 8:48 PM

All replies

  • User1120430333 posted

    Object reference not set to an instance of an object

    An object is sitting at a null value, it doesn't exist in memory, it's not there, it was never instanced and when code tries to reference an object that's not there, you're  going to get the exception.

    To me, you need to be talking to the 3rd party about its DLL.

    OO follows basic principles Java or .NET. 


    Friday, May 1, 2020 9:24 PM
  • User-1206059511 posted

    Thank you for the reply.  I do understand that must be what's happening (the object isn't getting instantiated).  My main goal is to get to the bottom of what could be different between this ASP.NET application calling it and the .NET console application where it works just fine using the exact same library calls.

    Friday, May 1, 2020 10:10 PM
  • User475983607 posted

    You misunderstand how web application work fundamentally.   A back ground thread is required for DLL to function like it does in a console application.  Even then the approach might work as expected because a console application is a single instance with a single user.  A web application is a single instance with many users.

    Can you explain the programming problem you are trying to solve?

    Friday, May 1, 2020 10:23 PM
  • User-1206059511 posted

    I'm trying to create some kind of API for this 3rd party service--that the DLL provides--that I can call into and get results from a limited, embedded scripting environment on the same machine.  That embedded scripting environment allows for HTTP calls, so it seemed to me that creating a REST API wrapper around the 3rd party service might be the path of least resistance, even though they're on the same machine.  So, ideally, I would have a singleton that exists for the life of the application that the controller routes can exchange data with, depending on the client requests.

    I've done quite a bit of development on web applications, mainly with Perl web frameworks on *nix OSes, but I'm very new to ASP.NET, and relatively unfamiliar with Windows programming in general.

    Monday, May 4, 2020 5:24 PM
  • User-474980206 posted

    this would probably be easier to write in .net core 3.1 (which is a command line program). you could do the hookup to the dll in program.cs, and inject  or make static a handler used  by the webapi to call the the dll.

    Wednesday, May 6, 2020 3:24 PM
  • User-1206059511 posted

    Thanks for the replies.  I'm sure there's a way to get it to work with ASP.NET, but I ran out of ideas and patience, and found embedio (https://github.com/unosquare/embedio) which just works as expected out of the box.

    Thursday, May 7, 2020 7:23 PM