Can't authenticate using secWinAD protocol with .Net SDK

[first_last]

I'm attempting to authenticate using a .Net client.

The relevant code:

ISessionMgr sessionMgr = CrystalEnterprise.GetSessionMgr();  
IEnterpriseSession enterpriseSession = sessionMgr.Logon([userName], [password], [server:6400], [authentication]);

If I use an account with secWinAD credentials, I get an error on the Logon line that reads:

System.ArgumentNullException: 'Value cannot be null.Parameter name: assembly'

If I use an account with secEnterprise credentials, however, the Logon method works.

I noticed that the secWinAD protocol isn't installed:

sessionMgr.InstalledAuthProgIds
{string[1]}
  [0]: "secEnterprise"

I've added the CrystalDecisions.Enterprise.Auth.secWinAD assembly to the project's reference.

When I use the RESTful SDK, I can access this server w/ the AD account.

What am I missing? Is there a way to programmatically add the secWinAD auth?

[first_last · Accepted solution]

I solved this problem, which I think was related to incompatible assemblies (as Shawn and Dan mentioned).

using CrystalDecisions.Enterprise;

try
{
  // create a new instance, rather than use singleton (which was from another assembly)
  SessionMgr sessionMgr = new SessionMgr();

  // use IS* interface, rather than the I* interface (which was from another assembly)
  // secWinAD works as expected
  ISEnterpriseSession enterpriseSession = sessionMgr.Logon("account", "password", "cmsName", "secWinAD");

  return enterpriseSession.LogonTokenMgr.DefaultToken;
}
// SDKException wasn't necessary
catch (Exception e)
{
  Debug.Print(e.Message);
  throw;
}

[former_member203619]

When I check the InstalledAuthProgId's on my test system, I see 8 members. It looks like this list comes from the CrystalDecisions.Enterprise.Framework assembly. I suspect that you have an old or bad version of that assembly in your application. Can you please check the properties of that assembly in your app and verify the version. Mine is Version 14.0.20000, Runtime Version v2.0.50727.

Shawn

[first_last]

Thanks for the help.

[DellSC]

This is a challenge and there's not a lot of information available around this. One option would be to log in to the RESTful web service to get the token and then use SessionManager.LogonToken() to connect the .NET SDK to the system.

Another option that I've used is to have the application get the user ID for the current session of the application and use SessionManager.LogonTrusted() to log the user in. This is based on the assumption that if a user is logged in to the application, I know who the user is and I trust the user so I can just tell BOBJ that I trust the user.

-Dell

[first_last]

daniel.paulsen any thoughts?

[first_last]

I removed this assembly:

I built the project and noticed a number of CrystalDecisions.* assemblies had been copied to the \bin directory. I ensured that all BusinessObjects.* and CrystalDecision.* assemblies were marked Copy Local = False and Embed Interop Type = False, built the project, and ensured that the \bin directory was free of assembilies of these two families.

When I hit the SessionMgr.Logon() line, using secWinAD, I still get this error:

Is there a way to get more-granular information from the SDKException?

What now? Is there a way to add the missing auth (secWinAD) in code?

[daniel_paulsen]

The error still appears to be mixed runtime. If you're working with Crystal Reports, then I cannnot think of any reason you should have any reference to BusinessObjects.Enterprise.* dlls. remove those from your project.

Ensure the path to each of your assemblies is consistent with the CPU you are building for (x86 or x64)

in the screenshot from your earlier post, you are referencing the Framework dll in the \win32_x86\ folder. Make sure none are pointing to the \win64_x64\ folder path.

We install assemblies to the "\SAP BusinessObjects Enterprise XI4.0\win32_x86\dotnet\ipoint\" folder, but they should also be in the GAC (c:\windows\assembly). The GAC is where an application should try and load and assembly first (providing BIN folder is cleaned up). If all of the above ideas fail, then possibly the GAC is out-of date. Verify the version of the dll in the GAC with the version in the \ipoint\ folder. by rigth-clicking on the assembly and selecting properties. You are interested in the file version(14.2.x.yyy) not the assembly version (14.0.2000.0). The file version should match the Service Pack you have installed. 14.2.x where 'x' is the SP number.

Dan

[first_last]

I'm using Window 7 (which is 32-bit). The build targets x86. The assemblies are in the GAC (c:\windows\assemby).

File versions:

• CrystalDecisions.Enterprise.Framework - 14.2.5.2618
• CrystalDecisions.Enterprise.InfoStore - 14.2.5.2618
• CrystalDecisions.ReportAppServer.ClientDoc - 14.2.5.2618

Questions:

• Are there 64-bit assemblies?
• How do I correctly reference the assemblies in the GAC, rather than the ones in \ipoint? I get this error:

[daniel_paulsen]

one assembly missing from your File Versions list is

CrystalDecisions.Enterprise.Pluginmanager

try adding that as well. If it fails, then remove all of the assemblies, re-add and ensure none were copied local.

Since your OS is 32bit, you won't have the 64bit runtime installed.

[first_last]

I added these assemblies (from the \ipoint directory):

I'm getting errors:

[first_last]

More errors:

Which assemblies am I still missing?

[daniel_paulsen]

Your references are fine.

• for the first error, CrystalEnterprise is not a namespace.
• for the second: SDKException comes from BusinessObjects.Enterprise.Exception
• for the third, I'm not sure unless your enterpriseSession object isn't declared as a CrystalDecisions.Enterprise.EnterpriseSession

[first_last]

What is the right way to get the SessionMgr?

You said that I didn't need any BusinessObjects.* assemblies in my project.

Is there a sample application that demonstrates this?

[first_last]

I appear to have the same version:

If it makes a difference, I can access the CMC and Launchpad using AD credentials.

[daniel_paulsen]

One thing that can cause strange behavior (everything works but .NET) is a mixture of assemblies in the Bin folder of the application.

This can happen if you've had "Copy Local : True" at any point and made changes to the application or runtime versions.

Old and incorrect versions can be left in the Bin folder after setting "Copy Local : False"

Try checking the application's Bin folder and remove any CrystalDecisions assemblies.

Dan