Discussion:
regsvr32 und keine Adminrechte weit und breit ...
(zu alt für eine Antwort)
Martin Bauer
2006-07-06 13:40:58 UTC
Permalink
zu sehen. :-)
Der gepfelgte Wahnsinn meldet sich zu Wort.

Hallo erstmal,
2010 wird zurückgeweltmeistert.

Mir fehlen die Schlagworte um google zu bemühen.
Ein Benutzer soll per Programm ein vom Programm benötigtes OCX registrieren
können sollen.

Selbst wenn dieser nicht mit Adminrechten ausgestattet ist. Wie ist es
möglich temporär nach
Eingabeaufforderung des Benutzername / Adminpasswort den Account zu
wechseln, so daß
die Registrierung erfolgen kann. Danach soll zurückgewechselt werden.

Normalerweise erfolgt die Registrierung bei Installation, die DAUs die hier
anrufen bekommen
alles aber alles hin, wechseln Festplatten und kopieren die Installation aus
ner Sicherung usw.

Grüße
Martin, der mit Sowjet-Fahne am Proleten-Benz ...
Jochen Kalmbach [MVP]
2006-07-06 17:38:16 UTC
Permalink
Hallo Martin!
Post by Martin Bauer
Selbst wenn dieser nicht mit Adminrechten ausgestattet ist. Wie ist es
möglich temporär nach
Eingabeaufforderung des Benutzername / Adminpasswort den Account zu
wechseln, so daß
die Registrierung erfolgen kann. Danach soll zurückgewechselt werden.
Das einfachste ist, wenn Du ein Programm (cmd oder exe) machst, welche
die Registrierung durchführt. Dies dann einfach im Explorer per
Rechts-Klick und "Ausführen als..." wählen. Dann den Admin-Account
eingeben und schwups, ist es registriert.

Alternativ könntest Du Dir überlegen die OCX/DLLs einfach App-Local
laufen zu lassen und ganz ohne Registrierung dies zu machen.
Kann gerade nur den 100%igen Link nicht finden...
http://windowssdk.msdn.microsoft.com/ms235532
--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Jochen Kalmbach [MVP]
2006-07-07 05:17:33 UTC
Permalink
Post by Jochen Kalmbach [MVP]
Alternativ könntest Du Dir überlegen die OCX/DLLs einfach App-Local
laufen zu lassen und ganz ohne Registrierung dies zu machen.
Kann gerade nur den 100%igen Link nicht finden...
http://windowssdk.msdn.microsoft.com/ms235532
Das Stichwort heisst RegFreeCom:
http://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/
http://msdn2.microsoft.com/en-us/library/ms165432.aspx

Greetings
Jochen
Martin Bauer
2006-07-07 06:41:37 UTC
Permalink
Post by Jochen Kalmbach [MVP]
Post by Jochen Kalmbach [MVP]
Alternativ könntest Du Dir überlegen die OCX/DLLs einfach App-Local
laufen zu lassen und ganz ohne Registrierung dies zu machen.
Kann gerade nur den 100%igen Link nicht finden...
http://windowssdk.msdn.microsoft.com/ms235532
http://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/
http://msdn2.microsoft.com/en-us/library/ms165432.aspx
Greetings
Jochen
Andreas Heyer
2006-07-07 08:20:11 UTC
Permalink
Hallo Martin,

es ist ohne Probleme möglich, die Registrierung unter
HKCU\Software\Classes durchzuführen. Damit kann nur der
installierende User das COM-Objekt nutzen. Über ein MSI-Paket
geht das automatisch, für regsvr32 muss man wohl
DllRegisterServer selbst anpassen. Man könnte z.B. testen, ob man
unter HKCR Schreibrechte besitzt, sonst HKCU wählen.

MfG
Andreas
Martin Bauer
2006-07-07 11:14:28 UTC
Permalink
Post by Andreas Heyer
Hallo Martin,
es ist ohne Probleme möglich, die Registrierung unter
HKCU\Software\Classes durchzuführen. Damit kann nur der
installierende User das COM-Objekt nutzen. Über ein MSI-Paket
geht das automatisch, für regsvr32 muss man wohl
DllRegisterServer selbst anpassen. Man könnte z.B. testen, ob man
unter HKCR Schreibrechte besitzt, sonst HKCU wählen.
MfG
Andreas
naja, wie geschrieben, DAU kopiert wild seine Verzeichnisse ( nicht der
Regelfall aber wenn es vorkommt ist das Geheule groß ).
DllRegisterServer anpassen, gute Idee, aber leider nicht mein COM-Objekt :-)
habe aber beim googeln nun auch noch das gefunden.

http://support.microsoft.com/kb/165194/

Gebe nur zu es sieht bissel blöd aus wenn die App nach dem Admin-PWD fragt,
aber warscheinlich weiß das der DAU auch nicht in
unserem Fall und das Geheule höre ich jetzt schon.

Ich kann nur sagen, schaut Euch eure Kunden ...

MfG
Martin, der auch nicht immer alles weiß und Fehler macht, Bierfrei !
Andreas Heyer
2006-07-07 14:15:17 UTC
Permalink
Hallo Martin!
Post by Martin Bauer
Gebe nur zu es sieht bissel blöd aus wenn die App nach dem Admin-PWD fragt,
aber warscheinlich weiß das der DAU auch nicht in
unserem Fall und das Geheule höre ich jetzt schon.
Es gibt auch Programme, die bei jedem Start die Registrywerte checken
und ggf. schreiben. Macht das die MFC nicht auch bei Doc/View mit den
Dateiverknüpfungen so? Na ja, auf jeden Fall könntest du so die nötigen
Daten entweder unter HKCR (falls Schreibrechte vorhanden) oder
HKCU\Software\Classes unterbringen.

MfG
Andreas
Johannes Passing
2006-07-09 09:53:11 UTC
Permalink
Kann man DllRegisterServer nicht anfassen, kann man jedoch im Programm,
das DllRegisterServer aufruft (selbstgebautes regsvr32), zuvor mittels
RegOverridePredefKey eine Umleitung von HKCR nach HKCU\Classes
einrichten. DllRegisterServer schreibt dann weiterhin nach HKCR, die
Werte werden aber nach HKCU umgeleitet.

Damit die nach HKCU\Classes geschriebenen Werte dann auch unter HKCR
auftauchen, ist es jedoch wichtig, dass unter HKLM keine Registrierung
vorliegt - ansonsten "ueberstimmen" die HKLM-Werte die HKCR-Werte und
die Registrierung war umsonst.

/Johannes
Post by Andreas Heyer
Hallo Martin,
es ist ohne Probleme möglich, die Registrierung unter
HKCU\Software\Classes durchzuführen. Damit kann nur der installierende
User das COM-Objekt nutzen. Über ein MSI-Paket geht das automatisch, für
regsvr32 muss man wohl DllRegisterServer selbst anpassen. Man könnte
z.B. testen, ob man unter HKCR Schreibrechte besitzt, sonst HKCU wählen.
MfG
Andreas
--
Johannes Passing - http://int3.de/
Andreas Heyer
2006-07-11 11:22:30 UTC
Permalink
Hallo!
Post by Johannes Passing
Kann man DllRegisterServer nicht anfassen, kann man jedoch im
Programm, das DllRegisterServer aufruft (selbstgebautes regsvr32),
zuvor mittels RegOverridePredefKey eine Umleitung von HKCR nach
HKCU\Classes einrichten. DllRegisterServer schreibt dann weiterhin
nach HKCR, die Werte werden aber nach HKCU umgeleitet.
Cool, die Funktion kannte ich noch gar nicht. Gibt es leider erst ab XP.
Wie macht es dann MSI auf W2k, wenn man eine User-Installation
durchführt?

MfG
Andreas
Andre Stille [MVP]
2006-07-11 12:20:45 UTC
Permalink
Hallo!
Post by Andreas Heyer
Cool, die Funktion kannte ich noch gar nicht. Gibt es leider erst ab XP.
Wie macht es dann MSI auf W2k, wenn man eine User-Installation durchführt?
Kurz: Bei MSI sollte man gar keine selbstregistrienden Module mehr ver-
wenden, da die Selbstregistrierung einige MSI-Funktionalitäten ein-
schränken bzw. unbrauchbar machen.

Was die Frage der User-Installation angeht: In der Registry-Tabelle der
MSI gibt es zu einem spezielle Werte, die bei einer Machine-Installation
auf HKLM und bei einer User-Installation auf HKCU zeigen. Darüber hinaus
können auch MSI-Dateien mit erhöhten Rechten installiert werden (Stich-
wort: Advertising).

MfG
Andre Stille
Andreas Heyer
2006-07-11 13:04:15 UTC
Permalink
Hallo Andre!
Post by Andre Stille [MVP]
Kurz: Bei MSI sollte man gar keine selbstregistrienden Module mehr ver-
wenden, da die Selbstregistrierung einige MSI-Funktionalitäten ein-
schränken bzw. unbrauchbar machen.
Ja, ist bekannt.
Post by Andre Stille [MVP]
Was die Frage der User-Installation angeht: In der Registry-Tabelle der
MSI gibt es zu einem spezielle Werte, die bei einer
Machine-Installation
auf HKLM und bei einer User-Installation auf HKCU zeigen. Darüber hinaus
können auch MSI-Dateien mit erhöhten Rechten installiert werden (Stich-
wort: Advertising).
Auch das ist mir bekannt.
Nur leider kann ich bei einem MSI-Projekt im VS 2003 keinerlei Tabellen
für die Registrywerte von COM-Objekten erkennen! Ein eingebundenes
COM-Server-Projekt steht bei mir immer mit "vsdrpCOMSelfReg" in den
Eigenschaften (im Wiederspruch zur 1. Antwort ;-) ). Muss ich bei
"vsdrpCOM" die Werte selbst in die Tabellen eintragen, oder kann das VS
selbst übernehmen? Aber wie sollte das gehen?

MfG
Andreas
Johannes Passing
2006-07-11 13:14:42 UTC
Permalink
Ja, bei vsdrpCOM generiert VS die Inhalte der Class-Tabelle etc.
automatisch. Dabei wird es vermutlich auch RegOverridePredefKey
verwenden, um herauszufinden, was DllRegisterServer in die Registry
schreiben wuerde. All das wird es dann in die Class-Tabelle eintragen.

/Johannes
Post by Andreas Heyer
Hallo Andre!
Post by Andre Stille [MVP]
Kurz: Bei MSI sollte man gar keine selbstregistrienden Module mehr ver-
wenden, da die Selbstregistrierung einige MSI-Funktionalitäten ein-
schränken bzw. unbrauchbar machen.
Ja, ist bekannt.
Post by Andre Stille [MVP]
Was die Frage der User-Installation angeht: In der Registry-Tabelle der
MSI gibt es zu einem spezielle Werte, die bei einer
Machine-Installation
auf HKLM und bei einer User-Installation auf HKCU zeigen. Darüber hinaus
können auch MSI-Dateien mit erhöhten Rechten installiert werden (Stich-
wort: Advertising).
Auch das ist mir bekannt.
Nur leider kann ich bei einem MSI-Projekt im VS 2003 keinerlei Tabellen
für die Registrywerte von COM-Objekten erkennen! Ein eingebundenes
COM-Server-Projekt steht bei mir immer mit "vsdrpCOMSelfReg" in den
Eigenschaften (im Wiederspruch zur 1. Antwort ;-) ). Muss ich bei
"vsdrpCOM" die Werte selbst in die Tabellen eintragen, oder kann das VS
selbst übernehmen? Aber wie sollte das gehen?
MfG
Andreas
--
Johannes Passing - http://int3.de/
Andre Stille [MVP]
2006-07-11 13:25:07 UTC
Permalink
Hallo!
Post by Andreas Heyer
Auch das ist mir bekannt.
Nur leider kann ich bei einem MSI-Projekt im VS 2003 keinerlei Tabellen
für die Registrywerte von COM-Objekten erkennen! Ein eingebundenes
COM-Server-Projekt steht bei mir immer mit "vsdrpCOMSelfReg" in den
Eigenschaften (im Wiederspruch zur 1. Antwort ;-) ). Muss ich bei
"vsdrpCOM" die Werte selbst in die Tabellen eintragen, oder kann das VS
selbst übernehmen? Aber wie sollte das gehen?
Die Frage ist, was schreibt deine DllRegisterServer-Funktion in die
Registry?

Die einzelnen CLSID-Schlüssel übernimmt die Class Table, wenn man zusätzlich
zu den hier angegebenen Werten weitere Schlüssel generieren muss (z.B.
der ToolBox32-Schlüssel) kann man das über die Registry Table machen.

Die Typelibrary wird über die TypeLib Table eingetragen, die AppID-Einträge
übernimmt die AppID Table.

Damit hat man eigentlich schon alle wichtigen Sachen erschlagen, die
Interface-Keys werden durch die TypeLib erzeugt.

Ich habe hier meine MSI-Dateien immer über Orca erzeugt, diverse Author-
Programme können die Daten mehr oder weniger gut extrahieren, in dem sie
vor und nach dem DllRegisterServer einen Snapshot der Registry durchführen
und die Änderungen vergleichen.

MfG
Andre Stille

Martin Richter [MVP]
2006-07-11 12:28:43 UTC
Permalink
Hallo Andreas!
Post by Andreas Heyer
Cool, die Funktion kannte ich noch gar nicht. Gibt es leider erst ab XP.
Wie macht es dann MSI auf W2k, wenn man eine User-Installation
durchführt?
Nein! Das geht auch unter W2K!
--
Martin Richter [MVP] WWJD
"In C we had to code our own bugs. In C++ we can inherit them."
FAQ : http://www.mpdvc.de
Samples: http://www.codeguru.com http://www.codeproject.com
Andreas Heyer
2006-07-11 12:56:01 UTC
Permalink
Hallo Martin!
Post by Martin Richter [MVP]
Nein! Das geht auch unter W2K!
Jo, stimmt. Hatte das 2000 unter Client als 2003 gelesen, weil es nach
XP kam. ;-)

MfG
Andreas
Loading...