CLRObject not found comes up in remote Server machine when I referenced few System.DirectoryServices dlls in local AX client

(0) Share

Report

Posted on by Sagnik Majumder

792

Hello All,

I am trying to extract the AD Group information from the curuserid() using few classes from System.DirectoryServices.AccountManagement namespace. For this reason I had added 3 references in my AOT.

System.DirectoryServices
System.DirectoryServices.AccountManagement
System.DirectoryServices.Protocols

As a practice, I do my development stuff from my local AX client installed in my machine which points to a remote machine where the corresponding AOS is installed. Therefore I have added all these DirectoryServices namespaces in my local AX client.

Now the scenario is :-

I have added an existing AD Group into the Users list in AX. Now when I login to my local AX client using a userid which doesn't exist in the AX users list but is a member of the said AD Group, it will popup the Group information and some other stuff in the infolog. AX will automatically add this userid to the Users list in AX. The userid is shown as a random text prefixed by a '$' sign.

Now the problem is:-

I login to AX client in the remote machine containing the AOS. If I login using this userid (which doesn't exist in Users list), a error popup comes up "CLRObject cannot be found." This issue is not observed in my local AX client where I have done my development. If I login using this userid in my local AX client, all the desired info is shown properly.

My guess is:-

These dlls that I have referenced is not available to the AX client at that remote server machine where the AOS is installed. Do I need to put explicitly those dlls somewhere in the server machine (like Client/Bin or Server/Bin or XppIL?)?

*This post is locked for comments

I have the same question (0)

All responses (7)

Answers (0)

Martin Dráb 237,801 Most Valuable Professional on at

Like (0)

Report

Are you sure about the error message? Isn't it "CLRObject could not be created"?

Did you find the place in code that throws the error, or is it just a guess? Note that there may be other reasons why an object can't be created, such as because of insufficient permissions. Can you isolate the problematic code to a simple piece of code that others can review and run?

Was this reply helpful? Yes No
Sagnik Majumder 792 on at

Like (0)

Report
Yes Martin, you are right, the error says "Object 'CLRObject' could not be created".

I have singled out the issue.

I am giving here the reproduction scenario and a small snippet which you can follow and reproduce the issue.

Condition:-

AOS (plus client) is installed in one VM (say X), and only an AX client which points to this AOS is installed in my own local machine (say Y) . I have TFS integration in my local AX client in Y and hence do all the developmental activities inside my local client in Y.

The following code developments are done by me as the SysAdmin.

Snippets:-

Create a new job called getADGroupFromUserJOB in AOT in the local client in Y.

Enter this code:-

public static str getADGroupFromUserJOB() { System.DirectoryServices.AccountManagement.PrincipalContext yourDomain; System.DirectoryServices.AccountManagement.UserPrincipal user; System.DirectoryServices.AccountManagement.GroupPrincipal p; CLRObject groups, enum; //System.DirectoryServices.AccountManagement.PrincipalSearchResult<Principal> groups; //System.Collections.Generic.IEnumerator<T> enum; System.String domain, username1,groupName; str groupN; Userid userId = curUserId(); InteropPermission permission; UserInfo userInfo, groupInfo; info('The current User is ' + curUserId()); try { permission = new InteropPermission(InteropKind::CLRInterop); permission.assert(); yourDomain = new System.DirectoryServices.AccountManagement.PrincipalContext(System.DirectoryServices.AccountManagement.ContextType::Domain); // find your user userInfo = xUserInfo::find(false, userId); domain = UserInfo.networkDomain; username1 = UserInfo.networkAlias; user = System.DirectoryServices.AccountManagement.UserPrincipal::FindByIdentity(yourDomain, username1); // if found - grab its groups if(user != null) { groups = user.GetGroups(); enum = groups.GetEnumerator(); }
} catch (Exception::CLRError) { CodeAccessPermission::revertAssert(); info(CLRInterop::getLastException().ToString()); return ''; } }

If you run this Job in local AX client Y, you'll see no error and the result is perfect.

But if you run this Job in AOS machine X, you'll see the error log coming as Object 'CLRObject' could not be created.

The first info (in blue) is getting printed indicating that the CLRObject error is coming at the line in Red.

i.e.

groups = user.GetGroups(); enum = groups.GetEnumerator();

How can I remove this?

I also thought of replacing CLRObject types with the real types of the actual objects which I commented in the Job you see above and is written in green. But it gives compile-time syntax error. Thus I am not sure whether template<> is supported in x++ or not.

Plz help.

Was this reply helpful? Yes No
Martin Dráb 237,801 Most Valuable Professional on at

Like (0)

Report

Can you please use the debugger to identify which exact statement is throwing the error? By the way, are you able to compile your code on the machine where it throws the error?

Was this reply helpful? Yes No
Sagnik Majumder 792 on at

Like (0)

Report
My local AX client has debugger installed, but debugger is not present in the machine where AOS is installed (this is where it throws the error).

Anyways I have put enough logs and it showed me that the following line throws the error.

yourDomain = new System.DirectoryServices.AccountManagement.PrincipalContext(System.DirectoryServices.AccountManagement.ContextType::Domain);

Yes, I am able to compile the code on the AOS machine properly.

Was this reply helpful? Yes No
Martin Dráb 237,801 Most Valuable Professional on at

Like (0)

Report

So why don't you install the debugger? Wouldn't you be more productive then?

Your job doesn't compile ("Not all paths in return a value"). Are you sure you gave us your actual code? (If I fix this bug, it works in my system.)

If your code compiles, it seems that AX client can find all necessary libraries. Therefore the problem seems to be caused by a runtime exception thrown by the constructor. (If you believe it's caused by an assembly binding anyway, use the Assembly Binding Log Viewer.)

Do you get the same error if you run AX client as administrator? Isn't anything logged in event logs? What if you run the constructor in a simple console application in Visual Studio?

Was this reply helpful? Yes No
Sagnik Majumder 792 on at

Like (0)

Report
One more update.

I inserted the Exception::Internal catch block in that Job.

catch (Exception::Internal) // This exception handler was the Magic Sauce!! { info('im in Internal'); ex = CLRInterop::getLastException(); if (ex) { info(ex.ToString()); } else { info("Internal Error"); } }

And now it shows:-

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DirectoryServices.Protocols.LdapException: The connection cannot be established. at System.DirectoryServices.Protocols.ConnectionHandle..ctor(IntPtr value) at System.DirectoryServices.Protocols.LdapConnection.Init() at System.DirectoryServices.Protocols.LdapConnection..ctor(LdapDirectoryIdentifier identifier, NetworkCredential credential, AuthType authType) at System.DirectoryServices.Protocols.LdapConnection..ctor(LdapDirectoryIdentifier identifier) at System.DirectoryServices.Protocols.LdapConnection..ctor(String server) at System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(String serverName, ServerProperties& properties) at System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval() at System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, String name, String container, ContextOptions options, String userName, String password) at System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType) --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark) at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at System.Activator.CreateInstance(Type type, Object[] args) at Microsoft.Dynamics.AX.ManagedInterop.ClrBridgeImpl.NewClrObject(ClrBridgeImpl* , Char* pszClassName, Char* assemblyName, Int32 argsLength, ObjectWrapper** arguments, Boolean* isException)

AND Then,

Error executing code: Overflow in internal run stack. Stack trace (C)\Jobs\getADGroupFromUserJOB - line 110

Was this reply helpful? Yes No
Sagnik Majumder 792 on at

Like (0)

Report
Hi Martin,

I told you I have debugging setup only in my local AX client which points to a remote AOS (where this error occurs). And yes, I get the same error even if AX client is run as administrator.

Okay, I have some updates for you!

When I run the following constructor in a simple console application in Visual Studio in that remote machine, "The connection cannot be established" error is thrown.

class Program { static void Main(string[] args) { System.DirectoryServices.AccountManagement.PrincipalContext yourDomain; System.DirectoryServices.AccountManagement.UserPrincipal user; System.DirectoryServices.AccountManagement.GroupPrincipal p; try { yourDomain = new PrincipalContext(ContextType.Domain); Console.ReadLine(); } catch (Exception ex) { Console.WriteLine(ex.Message); Console.ReadLine(); } } }

So it all comes down to this PrincipalContext constructor with ContextType Domain.

yourDomain = new PrincipalContext(ContextType.Domain);

I also found out that this specific machine has a problem with fetching AD users information or modifying any information in AD users & groups. This problem was not there earlier, but recently due to a shutdown, some of the VMs were pushed out of domain, and when they are moved back to domain again, probably this AD problem has creeped in. We have contacted our local IT team to get hold of this issue.

Was this reply helpful? Yes No