A while back in the C++ days, there were class libraries doing things like
sending mail, opening/reading cert store, event log writing reading, etc. These were written in C++ to encapsulate some of the pain associated with
routine tasks. Great Idea!!

MFC's CReg CSocket and a bumch of classes started with C made things easier. If you need to do stuff
you would use one of those reusable libraries or you would write one of those reusable classes.

Then came COM. Once again there are COM components that did read/write registry, read/write to event log.
you can see the ATL's incarnation of Registry classes as an example.

Then came ASP/VbScript. You need to read write the file system and registry from ASP files. Enter the Scripting.FileSystemObject
and its cousins. Due the popularity of ASP and web development, great amount of functionality needed to be cast through
IDispatch interfaces to make it available for VBScript programmers.

Human beings want to make progress. So .NET arrived. So there are new way to read  / write registry
and read write event log and read write files. OK

What about powershell? The world then needs to be packaged in Cmdlets to be consumed from the
powershell. great.

Well how about MSBuild? How can I read write registry from MSBUILD? Of course you need to
have the MSBuild tasks. Custom or not custom, you need to view the world through the MSBUILD Tasks.
There are community libraries that help you read registry and do great things like send mail, etc.

I wonder. How many ways do we need to read/write the registry?