This section demonstrates how to access a user's attributes. Once the AUO system has been configured with a necessary default AUO provider, and any other desired providers, we can use the UserObjects and SchemaObjects COM classes to create objects that can be used to easily access this information.
C and C++ programmers can use the P&M COM classes in the standard way. A file containing the interface definitions (IDL) is included with the SDK. You can elect to run the MIDL compiler on these IDL files and generate the necessary header files and GUID definitions, or simply import the IDL file into a project in the standard way.
Example
This example demonstrates the process of creating and using the UserObjects coclass in a C++ program. This class and its COM interfaces are defined within the IDL file auo.idl. The step-by-step procedure is given below.
Create the project directory for the C++ source code. The header files and GUID definitions are required, so we run the MIDL compiler on an appropriate interface definition language (IDL) file. You can either copy the file auo.idl from the \include directory of the SDK into the project directory, or use the OleView.exe application to bind to the type library and list the IDL definition. In the latter case, simply bind to the type library, which is located within the dynamic-link library c:\microsoft site server\bin\p&m\auo.dll. After it is bound, click the type library node in the tree. Select all the IDL text in the right pane and paste it into your favorite text editor. Save the text into a file named auo.idl. We now run the MIDL compiler with this file as the argument. This generates the necessary files:
auo.h
auo_i.c
auo.tlb
If you run MIDL on the auo.idl file that accompanies the SDK, two other files are generated:
auo_p.c
dlldata.c
These files are used to build a proxy dynamic-link library that can be used to marshal data to and from an instance of the object. Since the desired interfaces are marked with the dual attribute, the oleautomation attribute is implied. Thus, the automation library can handle all marshalling duties using the type library within the AUO.DLL, and these files can therefore be ignored and/or discarded.
The UserObjects coclass has multiple COM interfaces exposed, and among these are the Active Directory Service Interfaces (ADSI) IADs and IADsContainer. In order to provide forward declarations of these, we must either include the appropriate header files or use the type library to generate them. We'll use the include file that comes with the Platform SDK because it contains declarations for the low-level functions that might come in handy. The actual type library that will be used to provide marshalling information for the Automation system depends on the namespace we use to access directory information. For the LDAP namespace, the type library information for these interfaces is located in the dynamic-link library: c:\mircosoft site server\bin\Commerce.dll. If you are unfamiliar with the ADSI system, see the documentation in the Platform SDK under Networking and Distributed Systems.
The file we will use is located in the directory <PlatformSDK_Install_Dir>\include\iads.h. If you do not have the Networking and Distributed Services portion of the Platform SDK, this file will not be present. In this case, you can either download this portion from the Microsoft Developer Network (MSDN™) (http://msdn.microsoft.com) or build an IDL file using the type library information and the OleView application.
Now that we have all the necessary declarations and GUIDs defined, we can proceed to use the UserObjects coclass in a program. The example below is a simple program that will fetch some properties from the directory service.
This example ignores all run-time exceptions for the sake of brevity.
#include "iostream.h"
#include "auo.h"
#include "auo_c.h"
#include "iads.h" // for IADs and IADsContainer
int main() {
CoInitialize(NULL);
IUserObjects* pIUserObj = NULL;
HRESULT hR = CoCreateInstance(
CLSID_UserObjects,
NULL,
CLSCTX_ALL,
IID_IUserObjects,
(PVOID*)&pIUserObj
);
// we have the interface to the UserObjects object
// we now initialize the object
BSTR bszUserName = ::SysAllocString("JohnS");
BSTR lIISInstanceId = ::SysAllocString(L"1");
hR = pIUserObj->Init( lIISInstanceId, bszUserName ) ;
// We now fetch the IADs interface on
// the object
IADs* pIAds = NULL;
hR = pIUserObj->QueryInterface( IID_IADS, (void**)&pIADs ) ;
// we don’t need the IUserObjects interface anymore
hR = pIUserObj->Release();
// Now say we want to fetch the GUID property
// of the object
BSTR bszObjGUID = 0;
hR = pIADs->get_GUID( &bszObjGuid ) ;
// for simplicy, convert the BSTR to char
char AdsPath[100];
extern OLECHAR wszGUID[];
wcscpy(wszGUID,bszObjGUID);
SysFreeString(bszObjGUID);
wsctombs(AdsPath,wszGuid);
cout << "The ADsPath is: %s\n",AdsPath) ;
In order to use Java to access the various COM objects provided by the P&M feature, the necessary classes need to be defined and imported into the source code. To do this, run the JactiveX tool which will generate the necessary .java files. You can specify either the .idl file or the type library. For example: JactiveX "c:\microsoft site server\bin\p&m\auo.dll" /d C:\myclasses. You can then import these classes into source code using the import directive.
It is highly recommended that you install the latest Microsoft® Java SDK, Version 2.01 and use only the classes and tools provided in that release. The low-level COM support from earlier Java releases can cause byte-compile and run-time errors.
Example
File: MyClass.java
import auo.*;
import activeds.*;
import com.ms.com.Variant;
class MyClass {
public static void main( String args[] ) {
IUserObjects pIUserObjects = (IUserObjects) new UserObjects();
// use IUserObjects
IADsContainer = (IADsContainer) pIUserObjects;
try {
String UserGuid = IADsContainer.Get(“GUID”)
}
catch( ComException e ) {}
}
}
You can use low-level COM interface binding in Visual Basic 5.0 by adding the appropriate type library into the references in the project. The names of the type libraries are listed in the reference section for each COM class. Alternately, you can use late binding through the dispinterfaces for each object. In this case, no type information is required before run time.
Example
Vtable (early) binding: (IUserObjects)
Dim IUserObjects as UserObjects
Set IUserObjects = New UserObjects
or do late binding: (IDispatch)
Dim IUserObjects as Object
Set IUserObjects = CreateObject("Membership.UserObjects")
The first example requires the reference to the type library and will do compile-time type checking. The second example proceeds directory through the IDispatch interface and type mismatch errors can only by found at run time.
VBScript does only late binding through the IDispatch interface, so you can access the services of the classes by creating an instance and calling methods on the dispinterface in the standard way.
Using VBScript requires some sort of Active Scripting Host, such as the Active Server Pages (ASP) or the Windows Scripting Host (WSH). Of course, any Active Scripting Host that can load the appropriate VBScript parsing engine will do.
Example
Set IUserObjects = CreateObject("Membership.UserObjects")
Call IUserObjects.Init(1,"JohnS")
You could then run the script in an ASP page or with the WSH using a command such as: cscript myscript.vbs.
In this case, the appropriate scripting engine is identified by the extension on the file name.
JavaScript also does only late binding through the dispinterfaces. An example is shoen below.
Example
var IUserObj = new ActiveXObject("Membership.UserObjects");
var arg1 = 1;
var arg2 = "JohnS";
IUserObj.Init(arg1,arg2);You could then run the script in an ASP page or with the Windows Scripting Host using a command such as: cscript myscript.js.
In this case, the appropriate scripting engine is identified by the extension on the file name: .js loads the JavaScript engine.