Azure WebService can't find one of my assemblies but it's there based on Azure Console

Question

I am very new to Azure and WebServices so please bear with me here. Basically, I have a WebService that references 3 different dlls SOCreate.dll, EOTCBase.dll, EOTC_InBuffer.dll, not standard .NET dlls but rather dlls from other projects I have. After I published a WebService on Azure successfully, I am calling my WebService which calls a method in EOTCBase.dll. The method in EOTCBase.dll tries to load an EOTC_InBuffer.dll assembly like so:

Assembly dbAssembly = Assembly.LoadFile(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "\\EOTC_InBuffer.dll");

but that call fails with an error The system cannot find the file specified. (Exception from HRESULT: 0x80070002)

When I check what files I have on Azure I can see my WebService and a bin folder:

then I go inside the bin folder and can see all 3 dlls in there:

I guess that means that all 3 dlls are published on Azure and are available in bin folder. I tried to google for something similar but wasn't able to find a similar scenario. Could somebody please maybe point what's wrong here or maybe reference a link to some reading materials? Thank you.

P.S. It almost looks like that all those 3 dlls in the same bin folder based on Azure Console output but in fact some of them not in there actually.

Jason Pan · Answer 1 · 2020-05-19T01:22:14.953

1

UPDATE

I mean open kudu on the portal, and manually add the mydll folder as in my screenshot. The specific path of the .dll file is D:\home\site\wwwroot\mydll\a.dll. In this way, if the operation is successful, you don't need to worry about the temporary folder. Copy all the .dll files that will be used to the mydll folder.

PRIVIOUS

You can use dynamic load function to use your .dll file. If this is successful locally, and unsuccessful after deployment, then the problem should be the Azure cloud environment.

    #region Dynamically load .dll
    object obj=null;
    byte[] filesByte;
    Assembly assembly;
    Type type;
    MethodInfo timerInitial;
    MethodInfo timerDispose;
    #endregion

    private void LoadDll()
    {
        try
        {
            filesByte = File.ReadAllBytes(Path.GetDirectoryName(Application.ExecutablePath) + "//EOTC_InBuffer.dll");
            assembly = Assembly.Load(filesByte);
            type = assembly.GetType("EOTC_InBuffer.dll");
            obj = System.Activator.CreateInstance(type);
            timerStart = tp.GetMethod("TimerStart");
            timerStop = tp.GetMethod("TimerStop");
            if (timerStart != null)
            {
                timerStart.Invoke(obj, null);
            }
        }
        catch(Exception)
        {

        }
    }

You are successful in running locally, but deploying to Azure will fail. This problem cannot be dealt with, because we cannot register the .dll in the Azure environment, nor can we read and load these .dll files in the bin folder through code.

I have replied to this question in another post before, and also tried to use the code to deal with this problem but all failed, I hope it will help you.

edited May 19 '20 at 01:22

answered May 14 '20 at 06:33

Jason Pan

15,263
1
14
29

Hi Jason, I believe I have a different situation here. Firstly, those dlls are not built by somebody else but by me and they are all built with C# .NET. Secondly, **EOTCBase.dll** is running successfully with no issues. The main issue here is that when a method that is executing in **EOTCBase.dll** tries to find an **EOTC_InBuffer.dll**, not register, it can't because it's not in the same folder. When Azure Console is actually showing that they are. – Oleksii Dniprovskyi May 14 '20 at 13:19
I updated the answer and provided sample code for dynamically loading .dll files. You can also find other codes to dynamically load .dll files yourself. Note whether the directory path is correct and whether it can be run locally before trying again. – Jason Pan May 15 '20 at 01:32
Hi Jason. Sorry, I forgot to say. Locally I get the same scenario. When I open a temp folder that ASP.Net creates each time you I run my WebService locally, I can see **EOTCBase.dll** in there but not **EOTC_InBuffer**. And yes, I need to load EOTC_InBuffer dynamically, but first I need to find it by **GetExecutingAssembly().Location** and it seems not to find it. – Oleksii Dniprovskyi May 15 '20 at 03:15
@OleksiiDniprovskyi Can you put the dll file under the specified path? For example, `D:/mydll/`, the file path in the code is also written as fixed, to test whether the program can run normally. If such modification can be run normally, it means there is no problem with the program. – Jason Pan May 15 '20 at 04:28
@OleksiiDniprovskyi If it can be run normally after being modified in this way, it means that there is no problem with the program. Then we try to create the mydll folder in the directory at the same level as the bin folder under the release folder, and then put the dll file for local testing. Then you can deploy directly, remember to manually create a folder on kudu and put the file, and then test. Hope this helps you solve the problem. – Jason Pan May 15 '20 at 04:29
Hi Jason, so I tried to hardcode the path to my dll on Azure and it worked okay. BUT, then I printed out the path and it looks like it's running the code from a Temporary folder on Azure: **Path of a directory --- D:\local\Temporary ASP.NET Files\root\46456d43\c9810f0e\assembly\dl3\67111e3c\47d8e85b_5b2dd601** and of course the **EOTC_InBuffer.dll** is not being copied into that folder but **EOTCBase.dll** is. The same issue happens when running locally. Any idea why EOTC_InBuffer is not copied to the Temp folder in both scenarios, locally or on Azure? – Oleksii Dniprovskyi May 18 '20 at 22:19
@OleksiiDniprovskyi Is your program normal now? I suggest that you use Kudu to add a folder directly on the Portal and put your `EOTC_InBuffer.dll` and `EOTCBase.dll` and other .dll files. Then hardcode it according to the path on Azure. Because you said that it can be run on Azure, then this should solve your problem. As for why you said, it may be that the third-party .dll file that is not registered in the registry is dynamically loaded, and it is temporarily loaded into the temp folder. carried out. – Jason Pan May 19 '20 at 01:10
@OleksiiDniprovskyi I have updated my answer, u don't have to worry about so many questions about the temporary folder at runtime, that should be related to the operation mechanism of the .net program. For that piece, it needs more in-depth research on .net related knowledge. According to my answer, it would be great if it could solve your problem. – Jason Pan May 19 '20 at 01:25
Hi Jason, I gave up on that after trying what you suggested as it turned out I need access to the registry on Azure and I am not sure how it will work either right now or in the future. Thank you for help, I am not sure if I should accept your answer as it did not really explain why one of the dlls doesn't want to be copied and another does. I will mark it as useful instead. Thank you for your time and effort! – Oleksii Dniprovskyi May 23 '20 at 00:50

Azure WebService can't find one of my assemblies but it's there based on Azure Console

1 Answers1