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.FileSystemObjectand 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 registryand 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?
MSBuild has native ways of accessing registry http://blogs.msdn.com/msbuild/archive/2007/05/04/new-registry-syntax-in-msbuild-v3-5.aspx