.NET 6 API crashing whenever an RFC is called when using "InProcess" hosting model in IIS
bgmulinari opened this issue · 3 comments
Hello.
I'm developing a .NET 6 API where I call some RFCs in SAP to return the results as JSON. I'm facing a problem where the API works fine while debugging in IIS Express, but once published in IIS the API will crash (restart) whenever an RFC is called. What makes it even worse is that there's absolutely no error message or log that I could find to help understand what's happening, the application simply restarts. All the required DLLs are in the output folder and Visual C++ 2013 Redistributable is installed.
I already enabled tracing on the SAP connection string, enabled stdOut logs in my web.config, enabled application log via NLog, looked for something in Windows Event Viewer and couldn't find any information on the possible cause for the problem in any of these.
Right now, the only ways I found to make the API work as expected is to either run the application through .NET CLI (dotnet .\MyAPI.dll) and not rely on IIS at all (using Kestrel as the HTTP server) or change the hosting model in IIS to "OutOfProcess", which will also use Kestrel as the HTTP Server.
As the "InProcess" hosting model is the default and preferred way, I would like to understand what could be the problem. Any help is appreciated.
Have you verified the "bitness" of the application (API project) matches that of the SAP libraries?
Closing due to no feedback.
I ran into this (or at least a very similar) issue with an ASP.NET Core (.NET 6) app in "InProcess" mode, while it worked without problems in "OutOfProcess" mode. In my case it was not this open source library (SapNwRfc) I used, but another one that uses the C++ "sapnwrfc" library from SAP as well like this one.
At first I had no clue why the app was crashing in "InProcess" mode, but then I found the following solution: the path the C++ libraries (sapnwrfc.dll, ...) are located has to be in the environment path, so that the process w3wp.exe (not located in the app folder) finds them.
In my case the following was the solution (in Program.cs during the initialization of the app):
Environment.SetEnvironmentVariable("PATH", $"{builder.Environment.ContentRootPath};{Environment.GetEnvironmentVariable("PATH")}");