Good question, Todd. And unfortunately I don’t know the details enough to give you a precise answer. But I will say that no matter what Windows Server 2012 has in it, it isn’t a supported platform for the current RTM (Release to Manufacturing) version of System Center 2012.
“Why not?”
‘cause it’s in beta – that’s why not. So Server 2012 can’t a supported platform, and can’t be supported as a managed platform, either.
“Really? I can’t manage Windows Server 2012 beta with System Center 2012?”
I didn’t say you can’t. Some things will be manageable, just not supported. And features and functions that are brand-new to Server 2012 (live storage migrations and “Shared Nothing” migrations in Hyper-V come to mind) won’t be manageable at all.
“So.. that will change when Server 2012 finally comes out, right?”
No. Not immediately. There will have to be an update of System Center 2012 to make that happen. At the time of the writing of this blog post, no announcements of the timing of the release of Server 2012 or the next update of System Center 2012 have been made. But it has been announced that an update of System Center 2012 will be required to support Server 2012. In fact, early test releases of updates to System Center 2012 components are already available in CTP (Community Technology Preview) form on the Microsoft Connect site.
But back to your question on why an older version of the .NET framework might be required for a released product: It’s because that framework was the current broadly available framework when development of the product was underway. At some point in every product’s lifecycle, the requirements of the platform need to be decided upon and locked down, never to change. So in that light it’s easy to see why Microsoft (or any development organization) might come out with a product that requires older tooling than what is more recently available at the time of launch.
—
Does that make sense? Do any of you in the product team want to comment more specifically on any .NET framework differences?