问题
I'm a limited user, and I need to write an Outlook macro that exposes a C# library in Outlook 2003 and 2007.
I do not have any admin privilges at all, not even at install time, so I can't run RegAsm and I can't (I assume) write a managed add-in.
Is there any way to call .Net code from VBA in this scenario, or are there any other solutions?
This is for personal use only, so an ugly hack is perfectly acceptable (so long as it works)
回答1:
I solved this by running regasm with the /regfile option, and replacing HKLM with HKCU in the resulting .reg file.
回答2:
There's RegistrationServices.RegisterAssembly .NET API (which I believe is used by RegAsm.exe).
There's also RegOverridePredefKey Win32 API, inconspicuous but quite useful, which allows to remap HKEY_CLASSES_ROOT (used by RegisterAssembly) to HKEY_CURRENT_USER\Software\Classes.
A clever program can use both RegistrationServices.RegisterAssembly and RegOverridePredefKey to register an assembly for COM clients under HKEY_CURRENT_USER.
I haven't tried this myself, but I believe it's quite doable.
Updated, apparently this approach does works.
回答3:
Registering a COM object (ex. ActiveX control) and making it visible to all users in the system requires administrative rights.
BUT, if visibility to all users is not needed (or not possible due to limited user restriction) then the COM object can be registered only for the particular user.
This generally done by registering the object in HKCU instead of HKLM. This will apply for "regular" COM objects and the ones exposed through .NET COM Interop.
Other more fine grained approaches also exits, the already mentioned RegFree COM which addresses a particular executable.
So, given all of the above the solution to capture all info into reg file and replace HKLM with HKCU shall work (not nice, but so are the tools).
回答4:
I found a possible solution, but I haven't have time to try it yet.
回答5:
Unfortunately due to the way that COM works it would be impossible to install a COM object (interop or otherwise) without admin privileges.
When you register a com objects it writes several entries to HKEY_CLASSES_ROOT which is a machine level key and therefore requires admin privileges.
Now because you did say that a hackish solution is acceptable here are some possible steps you could take to get it to work; however if you do not have admin rights I am assuming that this is not your machine and most likely a work machine. Taking these steps could very well get you fired. Standard disclaimer and whatnot: It isn't my fault if you are a moron and get yourself sued/fired/shot/mugged/etc.
First you need to find out what registry keys need to be added. Make sure you are doing this on a 'clean' machine that host not seen your component before (or one you know that doesn't have the reg keys). Install a machine monitoring program to capture the keys. Here is a link to a [unrelated] MS article where they recommend some apps that do just that.
Now with the monitor running install you addin. You should now be able to get a log of what keys need to be created. Using your log create registry export files.
Now here is where it gets tricky. Basically what you will do is boot the machine from a BartPE image and mount the registry and run your scripts; however the key paths will be incorrect so the scripts will not work 'out of the box'.
MS has a TechNet article (but the link has parens in it so it doesn't play nice here) so Google it, it should be the first result.
After you have read that article you will see that the machines registry will be mounted as a subkey of HKEY_LOCAL_MACHINE. What you need to do is change your registry exports to match the new path. As soon as this step is complete you should be able to boot from your BartPE image, mount the registry, and then import your scripts, unmount the hive and then reboot. Assuming you copied the files to the correct path then it 'should' work.
Good luck.
来源：https://stackoverflow.com/questions/1354581/com-interop-without-regasm