Reference to native dlls not added about naudio.lame

[Corey-M]

Looks like this is a limitation of the Azure Function tool chain then, unfortunately. It will be interesting to see if they resolve it in future. I hope so, as there are endless amounts of native DLLs out there that would be painful to reimplement as managed code.

I'll close this for now. If something changes let me know and we can revisit it.

[Corey-M]

Hi @GeXiaoguo

I haven't worked with Azure Functions before. From the reading I've just done it seems that you should be able to load native DLLs in this kind of project. Sadly I don't have am Azure account and therefore no way to test, so you'll have to help me track this one down.

Firstly, the native DLLs are never added as references as they are not .NET assemblies. Instead they are added to the project as content items with CopyToOutputDirectory set to true. They should end up in the output directory after the build is complete and need to be published along with your code and all of the other assemblies.

So, the first thing to check is that you have the LAME native DLLs added to your project as items, and that they both have their Build Action property set to Content and Copy to Output Directory set to Copy always or similar.

The second check is whether they are actually being copied to your output folder during build.

That's as far as I can take the issue, unfortunately. The next part is speculation and some things for you to try to see if you can isolate the problem.

On standard Windows desktop platforms - server and workstation - the most common reason for a failure to load the DLLs is that they are not in the search path. For example, when working with ASP.NET the Bin folder path is not in the search path and needs to be explicitly added. See this question on StackOverflow for an example.

This might also be the case for your Azure Function.

To see if this is the issue, add some test code that does the following before using NAudio.Lame:

• Find the FS path of the assembly, using something like:
  Path.GetDirectoryName(typeof(NAudio.Lame.LameMP3FileWriter).Assembly)
• Confirm that the lame DLLs are present in that path.
• Try adding the DLL location to the PATH environment variable (as per the ASP.NET problem)

If the DLLs aren't present in the folder where the NAudio.Lame assembly is located then it's possible that you have an error in your deployment. Changing the PATH environment variable is non-persistent and will need to be done each time.

If you can get it working by adding to the path, let me know. If I can figure out a reasonable way to do it I'll add something to the library to do it automatically.

[GeXiaoguo]

@Corey-M Thanks for the reply.
Yes, adding those native dlls manually as Content works fine. That was also how I have solved the problem. I kinda expected that adding the nuget package would do these things for me. It did not come across initially that those are actually native dlls and can not be managed as references.

I did not find in the documents and examples mentioning that I have to manually add the native dlls. Maybe it is necessary to mention this point in the document. But I haven't spent too long with the documents and examples either. Apologize if it is already mentioned.

Once I've added the native dlls as Content, the runtime error went away when running the Azure Function locally. Running the function with nunit still report the same problem but it is because of the well known nunit CurrentDirectory problem. Manually setting the current directory for unit tests fixed it. I have not publish the function to Azure yet. Don't know how it will behave on Azure. It might have the same problem as running it in the unit test does. I'll report it when it happens. I guess there should be easy solutions. Loading native dlls in Azure functions should not be a rare use case.

[GeXiaoguo]

I had a look at the readme again. In the first paragraph, it says

The resultant assemblies (DLL files) are then added as resources to the NAudio.Lame assembly and loaded on demand.
This can be interpreted as that the native dlls are already contained in the assembly.

And then in the second paragraph, the readme says

I've included both 32-bit and 64-bit versions of libmp3lame.dll (named libmp3lame.32.dll and libmp3lame.64.dll respectively), both of which will be copied to the output folder

This can be interpreted as that the native dlls are contained in the nuget package and will be copied to the project output path.

This seems to be true for regular C# Library projects, but not true for Azure Function projects. The native dlls are not added as content automatically.

[Corey-M]

It's possible that this could be a problem with either the preview build of VS2017 or with the Tools for Azure Functions build at the moment. The content references are added in all of the project types I have used so far, which points to there being some issue with the toolchain for Azure Functions.

Perhaps you can raise this as an issue over at the Azure Functions GitHub repo.

[GeXiaoguo]

Just realized there might a rightful reason that Azure Function does not reference native dlls. Azure Function does live in a Sandbox. I may need a full managed library for audio processing in an Azure Function. Thanks for the help.

[GeXiaoguo]

And found this feature request