I am building a PowerShell script that uses a few user32.dll functions, and a few gdi32.dll functions. I've had to do this several times in the past.
I'm tired of looking at these huge blocks of C# code in a string in my PowerShell code. I am also tired of having to find the PInvoke code for each individual function I intend to use. I would like to have a single DLL that wraps all (known) user32.dll functions so that I can once and for all have them available to me.
I've googled around and don't seem to be able to find any prebuilt PInvoke wrapper DLLs for all known functions in user32.dll, win32.dll, or other popular unmanaged dlls. Why is this? I understand that perhaps they would not be stable and would constantly need updating - is that the reason?
I have also noticed that http://pinvoke.net/ provides a Visual Studio plugin that autogenerates signatures... does that mean that there is a pinvoke.net web service that I can use to automatically generate a dll based on the latest state of their database?
The reason there are no pre-built DLLs on the Internet, and why no one uses PInvoke.net's web service to automate this, is that most of the data there is fine for a human to understand and interpret but not fine for consumption by an automated script. If it were cleaned up a ton, it might be possible however.
A lot of this information is still stored on msdn, but it would take time to create such wrapper DLLs that encompass all known functions. AFAIK, no one has done this yet. I would love to take the time to go through the 586 known functions in user32.dll and create a wrapper DLL that could be used by others, but I just don't have the time, as with most people who would do this I suppose. I assume Microsoft has not done this simply because they don't feel it would be worth their time.
In addition, it seems that some of these functions are built in such a way that may not even have a proper way to translate into managed code with certainty that they would work. In particular, interpreting which C# types should be used for C pointers seems to be an issue.