As per your request, I'm making an answer out of my comment.
The correct way to do this is to let your DLL's users handle the situation themselves. As an API developer it is definitely not your job to bother about things like a firewall: either the API user and/or end-user made sure it works, or you fail gracefully. As others have said, there are many reasons why the end-user couldn't be able to answer an UAC request (eg. on a headless server) so you mustn't rely on your DLL being used in an interactive context. It's simply not your responsibility.
If you really must go on with your original idea (which, I stress again, is a bad idea IMHO) my best bet would be to split your DLL in two:
- The DLL itself, without any manifest so it can run under any user,
- and a separate
.exe
with a manifest that requires admin privileges, that will be run by your DLL only when need arises.
Just make it a requirement that both are stored in the same directory so you can easily find your DLL's (and thus the .exe
's) directory with GetModuleFileName
.
Others have pointed out runas
or RunDll
(which are equally valid answers IMO) but I'm more of a Unix-y type hence my suggestion of a separate binary altogether. I find it much easier to maintain in the long run.
A solution "in-between" would be that your DLL doesn't bother with the firewall at all (as it should) but you provide a completely separate tool (.exe
with manifest) that helps your users setup the firewall correctly when they need to. This may be the best solution: clean design (separation of responsibility) and still you provide all the required tools to the users.