Silverlight 4 COM+ Features

[Justin Angel]

Hi folks,

 

Just blogged about some full trust features enabled using Silverlight 4 COM+ support.

 

http://JustinAngel.net/CuttingEdgeSilverlight4ComFeatures

 

Among the features listed are Full file system access, CMD access, full operating system access, external devices access, Win7 API access, etc.

 

-- Justin

[Jeremiah Morrill]

Great post man!  You summed it up quite well.  I also like how you stressed that COM interop is suggested to be only used with well-known COM registered components.

-Jer

[Shawn Wildermuth]

Hate to be a broken horse, can you please not call it FullTrust since its not. I personally want to keep the idea that MS decided not to do FullTrust as a feature, but Elevated Trust instead.

 

Thanks,

Shawn Wildermuth

http://wildermuth.com

[Jeremiah Morrill]

Shawn I agree that it can be confusing, but I think what Justin was getting at is that anything you do via COM interop is full trust.

[Justin Angel]

I have not referred to these features as full trust in the blog post.

And in the blog post, I did stress that it’s elevated privileges.

 

However, this is an expert environment, so we can talk about things as they are.

 

Using COM+ you do get de-facto full trust access on Windows.

Which includes: File execution, file storage access, O/S access, networking, etc.

If you feel that’s not an accurate depiction of the situation, feel free to call out which full trust features of are missing.

 

From my point of view COM+ enables full-trust scenarios, while is not in fact full-trust.

 

-- Justin

[Shawn Wildermuth]

I can’t argue with that logic.  I understand why MS did this, but I still think it’s a mess.  COM being Windows only is a bad idea to the platform IMHO.

[Justin Angel]

And I also covered in the blog post how MS can easily enable similar scenarios on Mac. J

[Pavan Podila]

Great post Justin. Very "feature complete" :). I am sure it will be hot-linked heavily ...

/Pavan

--
Pavan Podila, MVP - Client App Dev
Author of WPF Control Development Unleashed
--| http://blog.pixelingene.com |--

[Corrado Cavalli]

Great post man!

 

.Corrado

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Justin Angel
Sent: mercoledì 20 gennaio 2010 00:45
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Silverlight 4 COM+ Features

 

Hi folks,

[Marlon Grech]

awesome post dude
Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App

[Dr. WPF]

+1 Fantastic article!

 

Although I do agree with Shawn that adding COM+ to SL was a slap in the face to the cross-platform, write once run everywhere proposition.  Even if they do add support for AppleScript, you’ll still have a spaghetti code nightmare.  On the other hand… guns aren’t bad, it’s the people who use them. Right? ;-)

[Josh Smith]

Or perhaps the society in which civilians are granted access to guns is the culprit...

[Jeremiah Morrill]

Doc,

Well at least with this gun, people can only shoot themselves in the foot ;)

I've been trying to soak in all the controversy surrounding the COM interop and so far, I see it as a good thing.  I will go as far to say that maybe they should of went even further...of course, depending on perspective.

If you consider SL as a AIR competitor, Microsoft has a leg up on Adobe with COM support.  In AIR, if folks want to do p/invoke, they'd create some sort of local tcp service and send messages for communication for their service to execute.

If you were a hardware OEM running SL running inside a toaster oven, you'd be glad Microsoft added some sort of p/invoke so you could talk to your toaster oven's hardware.  I suppose this would be the same idea behind Silverlight on a mobile phone.

If you just spent a zillion hours/dollars on a SL project, then after release you get a requirement that would be satisfied by something that COM interop gives you...well you just saved yourself having to rewrite your app in desktop .NET.

Write-once-run-everywhere is good in theory..and was great marketing material for Java, but a more honest phrase would be "Write once, run everywhere.  You are free to do anything you want...just as long as you do it in your 8x10 [web] cell."  We might like to think SL gives us a 100% consistent cross-platform runtime, but hw acceleration on the Mac is an example of this being untrue.  In my eyes, write-once-cross-platform means, "I don't do much particularly well...but at least you only wrote it once!"  Microsoft can't possibly give us everything under the sun in a trusted environment, so I'm glad they have an escape hatch.

The bottom line to me is COM is only supported in OOB + Elevated Permissions.  If a dev has gone that far, they should know what the limitations of their application are.

Just my take on it,

-Jer

On Wed, Jan 20, 2010 at 9:53 AM, Dr. WPF <a...@drwpf.com> wrote:

[a...@drwpf.com]

Well it's not called "Write once, run *well* everywhere" ;)

You make plenty of good points, Jer. I'm just not a fan of "Write once, test and rewrite everywhere"

Btw, if Windows is your target platform, there's a better option than both SL and AIR (but I'm not going to give you any hints on what it is).

And if you do need cross platform support, then I guess it's nice that you have a gun. (You don't really need two feet if you have good hopping skills! :-D)

-----Original Message-----
From: "Jeremiah Morrill" <jeremiah...@gmail.com>
Sent: Wednesday, January 20, 2010 2:31pm
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] Silverlight 4 COM+ Features

Doc,

Well at least with this gun, people can only shoot themselves in the foot ;)

I've been trying to soak in all the controversy surrounding the COM interop

and so far, I see it as a *good *thing. I will go as far to say that maybe

-Jer

> *From:* wpf-di...@googlegroups.com [mailto:
> wpf-di...@googlegroups.com] *On Behalf Of *Marlon Grech
> *Sent:* Wednesday, January 20, 2010 9:22 AM
>
> *To:* wpf-di...@googlegroups.com
> *Subject:* Re: [WPF Disciples] Silverlight 4 COM+ Features

>
>
>
> awesome post dude
> Regards
> Marlon
> WPF Blog - http://marlongrech.wordpress.com/
> Microsoft MVP for Client App
>
>
> On Wed, Jan 20, 2010 at 6:27 AM, Corrado Cavalli <
> corrado...@gmail.com> wrote:
>
> Great post man!
>
>
>
> .Corrado
>
>
>

> *From:* wpf-di...@googlegroups.com [mailto:
> wpf-di...@googlegroups.com] *On Behalf Of *Justin Angel
> *Sent:* mercoledì 20 gennaio 2010 00:45
>
>
> *To:* wpf-di...@googlegroups.com
> *Subject:* [WPF Disciples] Silverlight 4 COM+ Features

[Peter O'Hanlon]

It's a really good article, but - and I ask this not having tried the COM stuff yet - doesn't this represent a major potential security flaw. Unrestricted file system access?????

--
Peter O'Hanlon

[Jeremiah Morrill]

Peter,

I wouldn't classify this as any more security risk than downloading and installing another 3rd party application.  COM interop will only work in OOB _and_ with elevated permissions enabled.  The end user installing the OOB is warned and forced to wait for a few second "cool down" period before he/she initiates the OOB installation.

The main conceptual security issue I see is that this is a mixture of "trust levels".  The CoreCLR is still not in full trust mode, but any COM instance, by definition, runs outside the sandbox.  I think this can be confusing to both developers and users who expect/assume one thing, but get another...which generally isn't good when you are talking about security.

[Pavan Podila]

Jer,
          Here's one question for you: Does the elevated trust also require Admin rights on the machine on which you install ? In other words, can a regular non-admin user install an OOB app with elevated trust and run COM interop code ?

[Jeremiah Morrill]

Elevated trust does not require admin rights.  So a non-admin can install apps, but of course, all the install info goes into the HKCU, and files go inside folders off their home directory.  An elevated trust SL app (with COM) has the same rights as any other app running under your user.  So the OS still protects ya and you of course cannot register a COM component w/o admin rights.

[Pavan Podila]

Thanks Jer. I may hit you with a few more trust related questions soon :)

[Jeremiah Morrill]

No prob Pavan.

On a side note, I'm working on an experimental hack to allow execution of any desktop .NET assembly..without COM registration.  This isn't easy considering you can only instantiate COM objects that a) Have a ProgId b) Support IDispatch, so you can imagine how hacky my solution is ;).

To give an idea, I created a native dll, which gets executed by rundll32 via the wshell script (wshell script comes with windows, works with SL com out of the box).  I then inject the dll into the SL OOB process and do some method hooking on some ole32.dll methods.  When SL code requests a "Fake.ProgId", my hook injects a desktop .NET proxy and returns the IntPtr from Marshal.GetIUnknownForObject(clrProxy).  This gets returned back to silverlight and you can use the .NET object as you would any other COM object in Silverlight.  It's a damn dirty solution, but it works.  I'll let you guys know when I clean it up...so you guys can get a good laugh =P

-Jer