ich hoffe damit bei WinAPI richtig zu sein:

In meiner Anwendung registriere ich eine DLL mit

typedef int (__stdcall* fDllRegisterServer) (); 
    HINSTANCE hInst; 
    hInst = LoadLibrary("C:\\Debug\\split.dll"); 
    fDllRegisterServer fdreg = GetProcAddress(hInst, "DllRegisterServer");     
    int res = fdreg (); 

    FreeLibrary(hInst);

Nun habe ich das Problem, dass in meiner Anwendung der Zugriff auf
diese vermeintlich registrierte DLL nicht funktioniert. Soll heißen
ich habe nicht die nötigen Rechte (Fehler 0x80070005).

Unter "run as" und dann als Administrator funktioniert alles bestens.
Aber ich kann den normalen User schlecht so vor dem Problem stehen
lassen. Ich verwende VS2008 und das Programm läuft momentan auf
Win2003 RC2/SP2 Standard Edition.

Welche Möglichkeiten habe ich noch, das Problem anzupacken?
regsvr32 als Benutzer bringt den o.g. Fehler, wobei ich als Admin
ja schon erfolgreich die DLL registriert habe

Zugriff auf HKLM ist nicht erforderlich. Es handelt sich um eine
gekapselte Lib zur Bearbeitung von PDF-Dokumenten deren Zugriff über ein
ActiveX ermöglicht wird. Ich habe lediglich eine Headerdatei:

http://www.c-plusplus.net/forum/viewtopic-var-t-is-227566-and-highlight-is-split.html

Mein Test hat aber gezeigt, dass es auch für den normalen User geht, sofern
man die Programmdateien alle z.B. in "Eigene Dateien" oder unter c:\programme
ablegt. Vom Desktop aus will es allerdings aus einem dort abgeworfenen Ordner nicht
gehen Ich hoffe die ganze Sache wird von einem gemappten Laufwerk im Netz funktionieren.

Oder sollte man solche Nutzerübergreifenden Dateien währen der Installation
im Systemordner abwerfen und (ähnlich regsvr32) wie oben beschrieben im
System bekannt machen?

Entweder legst du deinem Programm ein Setup bei, dann ist klar, dass Administratorenrechte benötigt werden, da normlerweise nur Administratoren Programme installieren können sollten oder du weißt den Benutzer daraufhin, dass beim ersten Start Administratorenrechte nötig sind und weißt auch daraufhin warum diese nötig sind.

Aber nochmal um Klarheit zu bekommen und noch mehr dazu zu lernen:
Sollte ich die DLL im Systemverzeichnis abwerfen und vom Admin dort registrieren lassen?
So hätte doch jeder Zugriff darauf oder?

Denn meine Anwendung hat gerade den Sinn überall hin verschiebbar zu sein
und dennoch zu funktionieren (sofern auf dem selben PC verschoben).

Aber nochmal um Klarheit zu bekommen und noch mehr dazu zu lernen:
Sollte ich die DLL im Systemverzeichnis abwerfen und vom Admin dort registrieren lassen?
So hätte doch jeder Zugriff darauf oder?

Denn meine Anwendung hat gerade den Sinn überall hin verschiebbar zu sein
und dennoch zu funktionieren (sofern auf dem selben PC verschoben).

1. Wenn es ein sich um ein COM Objekt handelt muss es normalerweise vom Admin registriert werden.
2. Sofern das COM Objekt selbst nicht Dinge benötigt, die nur ein Admin kann (Schreibzugriff auf HKLM) dann solle es funktionieren. Will die DLL also z.B. Daten in das Verzeichnis schreiben, in dem sie selbst leigt, dann wirst Du in Probleme laufen...
3. Ein COM Modul ist nicht verschiebbar ohne das man es neu registriert.

Du musst uns schon mehr sagen was diese DLL tut.

Link zum Anbieter

PDF Split Merge ActiveX Component can split and merge PDF files for you easily.
It is a standalone component and does not depend on Adobe Acrobat, or even Acrobat Reader.

Die Komponente nutzt zudem eine DLL von http://www.pdfkit.com.

Detailliertere Infos kann ich vermutlich erst morgen geben.

Die DLL-Funktionen Rufe ich, wenn das CreateDispatch("PDFSplitMerge.PDFSplitMerge.1");
bereits besteht einfach mit:

<membervar>.Split("syntax")

auf. Split die ist eine Funktion der DLL.

Nimmt also die ClassID der Registry die Verbidnung zur DLL auf, oder?

Ist die Rückgabe von CreateDispatch negativ, rufe ich:

typedef int (__stdcall* fDllRegisterServer) (); 
    HINSTANCE hInst; 
    hInst = LoadLibrary("C:\\Debug\\split.dll"); 
    fDllRegisterServer fdreg = GetProcAddress(hInst, "DllRegisterServer");     
    int res = fdreg (); 

    FreeLibrary(hInst);

Du kannst nicht einfach DllRegisterServer aufrufen weil dies eben Einträge in die HKLM macht! Und das geht nur als Admin!
COM Objekte müssen installiert und registriert werden. Die kannst DU nicht einfach als Benutzer durch die Gegend kopieren.

Schau Dich mal nach ClickOnce um...
http://msdn.microsoft.com/en-us/magazine/cc188708.aspx

Nur lief es wohl nicht auf dem Useraccount, weil ich vermutlich die
DLL in einem Ort (auf dem Adminacc.) registriert habe, auf den der
normale User keinen Zugriff hat. Daher meine Frage betreffend System32-Folder.

Was ich vom Hersteller der Dll, oder allgemein, noch nicht verstehe:

Er wird mit einem ActiveX-Element geworben. Haben tue ich doch nur eine DLL,
die registriert wird und dann über die Registry (ClassID) global
verfügbar ist. In den installierten ActiveX-Komponenten des PC ist die
DLL nicht zu sehen. Ich spare mir ja irgendwie jetzt das explizite Laden via
LoadLibrary oder?

Verstanden habe ich das Konzept noch nicht
Vielleicht erklärt es der von dir gepostete Link ja auch, ich mach mich mal ans lesen

Ich bin um jede Erleuchtung dankbar

Jupp

OK! Dan versuche mal die Basics zu verstehen. Dann wirst Du auch merken, warum und wieso was wie geht...

http://www.c-plusplus.net/forum/viewtopic-var-t-is-214710.html

Martin