Error: NetWeaver DLLs need to be in PATH ?

[clint2627]

Getting the below error from a .net core web api app. Do the net weaver dlls need to be configured in PATH ?

[clint2627]

Where should these DLLs be located in relation to the output directory ?

[fw2568]

all dlls from nwrfcsdk lib folder should be copied to output directory of executables.
e. g. bin\Debug\netcoreapp3.1 for Debug of a netcoreapp 3.1.

[clint2627]

so a little more info. It looks like I'm running into an issue with .net core 2.1. Are there any known issues with core 2.1 ?

[clint2627]

No I think I was wrong. core 2.1 and core 3.1 both give me that error saying those DLLs should be in PATH

[fw2568]

Problems like this are typical related to the point that nwrfcsdk is platform specific (this also applies to x64/x86). While you are normally don't have to care on .NET if you are running a x64 or a x86 process you have to if you use a C++ dll like the sdk.

therefore we typical use

<RuntimeIdentifier>win7-x64</RuntimeIdentifier>

in project sdk file.

• I'm wondering how you caused this popup. Are you running in console mode, Krestrel or IIS?
• Are the icu*.dll actually in the output directoy?
• Have you used x64 nwrfcsdk or x86 sdk?

[clint2627]

Good questions.

I'm in Visual Studio 2019 using IIS Express. However, I will eventually need this to work in an IIS environment, and a kubernetes environment.

The icu dlls are in the output directory.

I downloaded the x64 version of nwrfcsdk. Is there any way I can confirm that ? Should I be using the x86 version?

A little more info. Everything seemed to work in a core 3.1 console app when I went thru your blog step by step. What I'm trying to do now is get it to work in a core 2.1 web api application. EDIT: This was a mistake. Our apps are targeting core 3.1, not 2.1

[fw2568]

let me have a look, I will add some samples for these platforms (docker instead kubernetes, but should work too).

[fw2568]

Ok, a colleague has told me that it is caused by IIS process mode.

IIS in in-process mode will not load the libraries, either

• switch IIS express to Hosting Model = Out-of-process
• use Program profile

Docker / Kubernetes will not use IIS at all, but launches in program mode. So there it will work out of the box, but keep in mind that you have to provide nwrfcsdk linux lib in container.

[clint2627]

ok thanks for the heads up. I didn't know there was a linux specific version of the nwrfcsdk DLLs. I guess I need to log back into SAP and see all the available downloads.

[clint2627]

is the Hosting Model issue specific to net core ? Do I need to worry about that with an asp.net webforms project?

[fw2568]

You don't have to worry. I have reviewed this topic again and finally it can be implemented in a way that work with any process mode / platform.

Please have a look at the new samples for aspnetcore. In Program.cs there is a call to a helper set sets the PATH variable (or LD_LIBRARY_PATH on Linux/MacOs):

YaNco/samples/netcore3.1/SAPWebAPI/Program.cs

Line 17 in 10d8bae

RfcLibraryHelper.EnsurePathVariable();

YaNco/samples/WebApi.Shared/RfcLibraryHelper.cs

Lines 8 to 16 in 10d8bae

	/// <summary>
	/// This method ensures that either LD_LIBRARY_PATH or PATH points to base directory
	/// where referenced UCI libs should be stored.
	/// Please note that this don't work for docker containers
	/// </summary>
	public static void EnsurePathVariable()
	{
	var executeableDir = AppDomain.CurrentDomain.BaseDirectory;
	var pathVariableName = "PATH";

I have tested this with .net 471, aspnetcore 2.1 and aspnetcore 3.1. Except for IIS Express in-proc mode and aspnetcore 2.1 it will also work on Windows without setting the path. So behavoir was at least different for .NET Core 2.1. However if you use logic like in the sample you can make sure that it will work in any environment.

Containers

Please note that this don't work for linux containers. Here you have to set the environment variable

LD_LIBRARY_PATH = /app

for the container. /app is the default path for a dockerfile created in Visual Studio.

Debug Configuration / Launch Settings

In Debug Configuration the logic for containers has changed in Visual Studio 2019, as it will not rebuild the dockerfile in Debug config.

Instead you can just add it to the launch settings:

YaNco/samples/netcore3.1/SAPWebAPI/Properties/launchSettings.json

Lines 32 to 35 in 10d8bae

	"launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}/api/company",
	"environmentVariables": {
	"LD_LIBRARY_PATH": "/app/bin/Debug/netcoreapp3.1/"
	},

[clint2627]

that is a lot to unpack. I'm a little confused on the Linux part. Sounds like on a windows machine the variable name is PATH. On a Linux machine the variable name is LD_LIBRARY_PATH

However, this is not true in a kubernetes environment? The Linux pods in kubernetes the variable name needs to be /app ?

If so, can i change this

if(!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
pathVariableName = "LD_LIBRARY_PATH";

to this?

if(!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
pathVariableName = "/app";

[clint2627]

In framework 4.7.2 I get a different error. The DLLs are in bin folder. Is it again looking in PATH location for the DLLs ?

[fw2568]

looks like you are trying to load a x86 library into a x64 process (or x64 into x86 process). See my first answer:

#59 (comment)

[fw2568]

if(!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
pathVariableName = "LD_LIBRARY_PATH";

to this?

if(!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
pathVariableName = "/app";

no. Variable name is always LD_LIBRARY_PATH on Linux.
The point here is, that setting variable value within the running container has no effect. Probably this is a security feature of containers.

[clint2627]

looks like you are trying to load a x86 library into a x64 process (or x64 into x86 process). See my first answer:

#59 (comment)

OK I will download latest of each version and try both.

[clint2627]

if(!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
pathVariableName = "LD_LIBRARY_PATH";
to this?
if(!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
pathVariableName = "/app";

no. Variable name is always LD_LIBRARY_PATH on Linux.
The point here is, that setting variable value within the running container has no effect. Probably this is a security feature of containers.

So does that mean the DLLs won't work in containers?

[clint2627]

looks like you are trying to load a x86 library into a x64 process (or x64 into x86 process). See my first answer:

#59 (comment)

I've tried both x64 and x86 DLLs and get same error. Do you have any samples of .net framework web application running these DLLs ?

[fw2568]

So does that mean the DLLs won't work in containers?

no, that just means that you have to set the variable, e.g. in dockerfile:

ENV LD_LIBRARY_PATH=/app

[fw2568]

https://github.com/dbosoft/YaNco/tree/master/samples/net472/SAPWebAPI

this is ASPNET Core 2.1 running on .NET 4.72

however if you mean classic ASP.NET: that has never been tested, and I would not expect it to work as library support starts with .NET Framework 4.71.

[clint2627]

I am trying to use this in these two scenarios:

1. ASP.NET WebForms application targeting .Net Framework 4.7.2 - hosted in an AWS windows server via IIS
2. Web Api MVC application targeting .Net Core 3.1 - Kubernetes environment with Linux pods

I got #2 running locally once I set this in the cproj file:

<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>

However this is on my local windows machine with IIS Express. According to your previous comments it sounds like I will need to use Linux specific ICU*.dll for the Kubernetes environment. And it also sounds like I will have to modify docker file to set ENV LD_LIBRARY_PATH=/app

#1 however, I can't get passed the error I posted before:

I've tried both x86 and x64 version of the DLLs and get the same error. And I have verified the DLLs are in the output directory (bin). I'm wondering if I need to programmatically set PATH like you described above in your code sample.

[hangy]

Sorry in advance to dig up this old thread. We also had this issue with the sapwfrfc.dll in the bin directory of a .NET Framework ASP.NET MVC 5 web application. As far as I can tell, it's not YaNco's fault, nor necessarily SAP's fault. I was getting the same error in IIS, IIS Express, and when using MvcBuildViews=true.

Error

Fusion Log

*** Assembly Binder Log Entry  (15.04.2024 @ 19:57:18) ***

The operation failed.
Bind result: hr = 0x80131040. No description available.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable  C:\Program Files\IIS Express\iisexpress.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = sapnwrfc
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: sapnwrfc | Domain ID: 2
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Users/myname/source/repos/Solution/Source/Repo/Project/
LOG: Initial PrivatePath = C:\Users\myname\source\repos\Repo\Source\Solution\Project\bin
LOG: Dynamic Base = C:\Users\myname\AppData\Local\Temp\Temporary ASP.NET Files\vs\xy
LOG: Cache Base = C:\Users\myname\AppData\Local\Temp\Temporary ASP.NET Files\vs\xy
LOG: AppName = d632bbb5
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\myname\source\repos\Repo\Source\Solution\Project\web.config
LOG: Using host configuration file: C:\Users\myname\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Users/myname/AppData/Local/Temp/Temporary ASP.NET Files/vs/xy/yz/sapnwrfc.DLL.
LOG: Attempting download of new URL file:///C:/Users/myname/AppData/Local/Temp/Temporary ASP.NET Files/vs/xy/yz/sapnwrfc/sapnwrfc.DLL.
LOG: Attempting download of new URL file:///C:/Users/myname/source/repos/Solution/Source/Repo/Project/bin/sapnwrfc.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Users\myname\source\repos\Repo\Source\Solution\Project\bin\sapnwrfc.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: sapnwrfcsdk, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
WRN: Comparing the assembly name resulted in the mismatch: NAME
ERR: The assembly reference did not match the assembly definition found.
ERR: Setup failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Stack Trace

[FileLoadException: Could not load file or assembly 'sapnwrfc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +0
   System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +232
   System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection) +113
   System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +23
   System.Reflection.Assembly.Load(String assemblyString) +35
   System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +48

[ConfigurationErrorsException: Could not load file or assembly 'sapnwrfc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +767
   System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() +256
   System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo ai) +58
   System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig) +287
   System.Web.Compilation.BuildManager.GetPreStartInitMethodsFromReferencedAssemblies() +69
   System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded) +137
   System.Web.Compilation.BuildManager.ExecutePreAppStart() +172
   System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException) +854

[HttpException (0x80004005): Could not load file or assembly 'sapnwrfc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +532
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +111
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +719

Analysis

Apparently, LoadAllAssembliesFromAppDomainBinDirectory iterates through all *.dll files in the bin directory, detects that the SAP library has some managed parts, but fails loading it, because some kind of assembly name mismatch happens.

sapnwrfc is a managed and a native library

When you open sapnwrfc.dll in dnSpy, you can see that the architecture is correct, but it also looks like it is (partially?) a .NET Framework library

// C:\Users\myname\source\repos\Repo\Source\Solution\Project\bin\sapnwrfc.dll
// sapnwrfcsdk.dll

// Global type: <Module>
// Native Entry point: 0x002A7208
// Architecture: x64
// This assembly contains unmanaged code.
// Runtime: .NET Framework 4
// Timestamp: 64AEFA43 (7/12/2023 9:08:51 PM)

using System;

Solution

Just remove sapnwrfc from ASP.NET's compilation.

<configuration>
  <system.web>
    <compilation targetFramework="4.7.2">
      <assemblies>
        <remove assembly="sapnwrfc"/>
      </assemblies>
    </compilation>
  </system.web>
</configuration>

By adding the remove element for sapnwrfc, we can completely exclude the DLL from this automagic DLL loading.

[fw2568]

Ok, understood.
First: we have to be careful what we are talking about. The PATH environment variable is a requirement of SAPNWRFC as it itself depends on the ICU libraries. To lookup these libraries it requires PATH variable or LD_LIBRARY_PATH to be set.

In case of the ASP.NET application it already fails to load the sapnwrfc library. So for this environment forget the PATH topic for now.

The error "Could not load file or assembly … An attempt was made to load a program with an incorrect format (System.BadImageFormatException)"is always caused by a x86 / x64 mismatch.

So please check your hosting settings for IIS / IIS Express, to make sure that they use a x64 process model if you load the x64 sapnwrfc.dll.

see also: https://stackoverflow.com/questions/11370344/could-not-load-file-or-assembly-an-attempt-was-made-to-load-a-program-with-a

[hangy]

The error "Could not load file or assembly … An attempt was made to load a program with an incorrect format (System.BadImageFormatException)"is always caused by a x86 / x64 mismatch.

Apparently not always: #89 (reply in thread)

[fw2568]

True!
But beside this topic: may I ask why you are using our library and not SAPNCo in the classic .NET Framework?
I'm asking because of #272 we will have to drop support for it in next major release.

[hangy]

We have .NET Framework and .NET Core apps. We went with YaNco as we liked the API and it currently supports netstandard2.0. This enables us to have the same developer experience with both framworks and across platforms.

I did notice the announcement of YaNco 5.x requiring .NET 8, and could certainly pose an issue for the .NET Framework apps/libraries we migrated to YaNCo recently.

[fw2568]

Ok thanks for the details.yes that's the same reason why we initially have targeted .net standard.
Please note that YaNco 5 will still be on .net standard. YaNco 6 will be on .net 8 or higher.

[clint2627]

Anything else I could be missing?

[fw2568]

I have create a sample WebForms project that loads the library sucessfully:

YaNco/samples/webforms/SAPWebForms/Default.aspx.cs

Lines 11 to 31 in 352cc37

	namespace SAPWebForms
	{
	public partial class _Default : Page
	{
	protected void Page_Load(object sender, EventArgs e)
	{
	var settings = new Dictionary<string, string>
	{
	};
	var connectionBuilder = new ConnectionBuilder(settings);
	using (var context = new RfcContext(connectionBuilder.Build()))
	{
	var response = context.PingAsync().GetAwaiter().GetResult();
	}
	}
	}
	}

it cannot do anything except loading sapnwrfc.dll but thats all we need here.

During setup of project I first had same problem as you. But I could solve it by switching "Bitness" setting in Project settings / Web to x64.

However then the next problem occured. The web projects tried to load the DLL as .NET assembly and was of course failing because it is a C++ DLL.
So finally I found out that this could also be solved by setting the PATH variable to the folder with DLLs:
https://stackoverflow.com/questions/7996263/how-do-i-get-iis-to-load-a-native-dll-referenced-by-my-wcf-service

Or you can copy it to c:\windows\system32 (or c:\windows\syswow64 if you would like to use the x86 library).

So to summarize this:
For WebForms do not copy the DLLs to the bin directory.

Instead create a folder somewhere else and include this in the system PATH variable. Then you have also set the path for the ICU libs.

[clint2627]

I am not seeing in your webforms example, where you set the PATH variable. Can you help me find that part?

[fw2568]

You have to set the PATH variable system wide.

[fw2568]

WebForms sample has been update todo something useful and merged into master:

YaNco/samples/webforms/SAPWebForms/Default.aspx.cs

Lines 18 to 47 in 0f57fe4

	// this application has a special method to set the SAP connection.
	// it has to be passed as a single configuration string in user secrets:
	//
	// <secrets ver="1.0">
	// <secret name="SAPConnectionString" value="ashost=<hostname>;sysnr=00;client=<client>;username="<username>";password="<password>"" />
	// </secrets>
	var connString = ConfigurationManager.AppSettings["SAPConnectionString"];
	var settings = connString
	.Split(';')
	.Select(HttpUtility.HtmlDecode).Select(x => x.Trim('"', '\'').Split('='))
	.ToDictionary(sa => sa[0], sa => sa[1].Trim('"', '\''));
	var connectionBuilder = new ConnectionBuilder(settings);
	using (var context = new RfcContext(connectionBuilder.Build()))
	{
	context.CallFunction("BAPI_COMPANYCODE_GETLIST",
	Output: f => f
	.MapTable("COMPANYCODE_LIST", s =>
	from code in s.GetField<string>("COMP_CODE")
	from name in s.GetField<string>("COMP_NAME")
	select (code, name)))
	.Match(
	r =>
	{
	Session["Companies"] = r;
	},
	l => Session["ErrorMessage"] = l.Message).GetAwaiter().GetResult();

[clint2627]

Do you know for sure that in a Linux Docker Container environment, the dockerfile needs updated with ENV LD_LIBRARY_PATH=/app ?

[fw2568]

Quite sure actually, at least for the build container.

But of course that depends on variables like the container, how you start it and so on.
For example VS has at least two places where the binaries are copied to container:

• if you run it directly from debug config you have to use debug output dir:
  https://github.com/dbosoft/SAPHub/blob/main/src/SAPHub.SAPConnector/Properties/launchSettings.json

• But for same application started from docker-compose will then be on /app:
  https://github.com/dbosoft/SAPHub/blob/a0d8025a6b9beae6695a9b86f854fb2e0bd3d82c/docker-compose.yml#L48-L57

I would recommend to set it first to /app and if not found check how container is build in your use case.

[fw2568]

as working in updated samples, I close this issue

[clint2627]

I'm looking at the netcore3.1 SAPWebApi example. I see this in launchsettings.json:

"environmentVariables": { "LD_LIBRARY_PATH": "/app/bin/Debug/netcoreapp3.1/" },

I expected to see something similar in the docker file. Shouldn't this environment variable be set in docker file for linux containers?

[clint2627]

Also, I'm assuming I need to download the Linux version of the SAP Netweaver DLLs if being used in Linux containers correct?

[fw2568]

"environmentVariables": { "LD_LIBRARY_PATH": "/app/bin/Debug/netcoreapp3.1/" },
I expected to see something similar in the docker file. Shouldn't this environment variable be set in docker file for linux containers?

Yes, of course it has to be added to dockerfile for the released build. But Visual Studio don't use the docker file to build the container in Debug profile. For debug build the container will mount the file system with the source files and build output, thats why it is set in launchprofile.

[fw2568]

Also, I'm assuming I need to download the Linux version of the SAP Netweaver DLLs if being used in Linux containers correct?

Yes, that's correct.