I think that the fear of Microsoft trying to make Perl "extensions" is a valid one given Microsofts history, but the .NET framework is much different than past situations.

All of the things they've "extended" to make propriarity were in an attempt to lock people into using just their platform. I belive that the .NET framework does this, not any language. From my initial impressions on what they're doing, they are no longer trying to make the development language or a client side scripting language their leverage. The implementation on .NET is just too different for things to be portable no matter what they are written in.

It looks like you're going to use Perl/C/C#/etc.. to manipulate and define your .NET environment in a sense. So it's not going to be at all portable since I don't think Microsoft is ever going port this platform to *NIX systems. It will still probably be Perl as we know it, but the actual code will have no use outside the .NET framework.

Anyway, that's my $0.02
Rich

Addition: I think it will be similar to how Perl is used in ASP and .wsh files. Example

You could use Win32::OLE or use objects that are pre-defined to ASP and WSH like so..(WSH version)

<job>
  <SCRIPT LANGUAGE="PerlScript">
    $x = $WScript->CreateObject('Excel.Application');
    $x->Workbooks->Add;
    $x->{Visible} = 1;
  </SCRIPT>
</job>
[download]

So it's Perl, but Perl using methods that are specific to the environment. Though you could do it using Win32::OLE, I'd assume that anyone working with ASP and WSH would use the built-in functinoality.