Unable to load dll (MEAIAU.DLL)

Discussion for developers using MailEnable.
Post Reply
Ruffs
Posts: 25
Joined: Sun Jan 14, 2007 4:21 pm

Unable to load dll (MEAIAU.DLL)

Post by Ruffs »

Hi there,


I was just trying to use an ASP.NET application we had built using the MailEnable.Admin assembly.

This application has started giving this error message when trying to use the components methods that are DllImported (and hence trying to go to the Win32 dll on the file system).

For example, the following code now gives this error:

MELogin = new Login();
MELogin.UserName = sUserId;
MELogin.Password = sPass;
MELogin.Account = "";
MELogin.Rights = "";
MELogin.Status = 1;

int nLoginResult = MELogin.GetLogin();

I believe this used to work correctly prior to the Lockdown Update utility, and would like to know what changes we will need to make to the permissions to return it to functional use.

We are using Enterprise 2.37 I believe, on a Windows 2003 Server box.


Kind regards,


Ruffs :)

Ruffs
Posts: 25
Joined: Sun Jan 14, 2007 4:21 pm

Partially Returned

Post by Ruffs »

Hello again,


Well I followed a few other ASP.NET guides about similar problems with other interop using assemblies, and found that setting the "Authenticated Users" group to have "Read and Execute" permissions on the MailEnable\Bin folder allowed me to at least get past that initial .NET error message.

However, now I get to the point where GetLogin() returns, however now it always returns Zero indicating a failure, even when I am certain the password is correct and it should not fail.

I am assuming now, that we are getting to a point where the Win32 library/ActiveX does something with the local file system that it is unable to do with the current permissions. Could someone please enlighten me as to what happens in the GetLogin() that could fail here because of the Lock Down directory access security settings.

Kind regards,


Ruffs :)

Ruffs
Posts: 25
Joined: Sun Jan 14, 2007 4:21 pm

Solutions Found

Post by Ruffs »

I'm unsure if it was the lockdown tool, or someone else that had changed the permissions, but the problem was that the NETWORK SERVICE was unable to read the CONFIG, POSTOFFICES and directories where extensions were installed, and didn't have the Full Control permissions it should have in those locations to do all it needed to do.

Changing at least these directories to allow the NETWORK SERVICE Full Control returned things to normal working order.

Post Reply