Following the recent discussions about making the installation experience as friendly as possible for visitors to your site who don't already have Silverlight, I've been trying to do this with my app by defining static HTML content for the DIV hosting my control, with a preview of the available content and a hint about the need to refresh/restart the browser. But, try as I might, I can't get this content to display when the content is streamed and hosted by Windows Live. It all works fine from my local machine, but when uploaded to the streaming server I always get a white background for the canvas and/or the control, so the static HTML is hidden. I also can't get the 'Install InPlace' button to display; it always shows the smaller 'Get Silverlight' button. I've seen some discussion about this, and tried all the suggested fixes (making the canvas and control backgrounds transparent etc) but nothing seems to work. Does anyone know if this is a limitation with Live hosted streaming, or have any other suggestions? Thanks in advance for any help.

The problem you have is with silverlight.js file, this checks if silverlight is installed on the computer and if not shows that "Get Silverlight" option. Unfortunetely you can't modify Silverlight.js in accordance with Silverlight License Terms.

However, Get Silverlight option is shown only when you try to open Silverlight App on a computer which doesn't have a Silverlight plug-in installed. If you dont want this to happen don't show your app until you have checked if Silverlight is installed on the computer and then do what you want to do, if the plug-in is installed then redirect to the silverlight app page.  

--
Imran Shaik
If this answers your question please select "Mark as Answered"
Old Blog | Silverlight 2.0 Quintessential Rambling |My Feed

Thanks for the response, Cass. I still don't understand why the following HTML behaves differently depending on whether Silverlight.createObject() or Silverlight.createHostedObjectEx() is called:

<DIV id="Silverlight_wrapper" style="background-image:url(images/sl_install_bkg)">

<DIV id="mySilverlightControlHost">

</DIV>

<SCRIPT type="text/javascript>

var parentElement = document.getElementById("mySilverlightControlHost");

createMySilverlightControl(); <%-- calls Silverlight.createObject() or Silverlight.createHostedObjectEx() --%>

</SCRIPT>

</DIV>

When this HTML is run locally, calling createObject(), the background image (images/sl_install_bkg) is displayed properly underneath the "InstallInPlace" button, but when it calls createHostedObjectEx(), with the same XAML and the createObject() parameters duplicated in the Manifest, the background image is not visible and only the small "GetSilverlight" button is displayed.

Any ideas?

Sorry for the rubbish formatting in my last post. Haven't quite got to grips with it!

I am not really going to be much help in solving this, but I do know why you are getting the symptom you report. It is all to do with the fact that when you use the createHostedObjectEx() it "spits" out the Silverlight object in an IFrame. See "You've been IFramed" here http://msdn2.microsoft.com/en-us/library/bb851600.aspx.

If you use a tool like Fiddler to take a look at the code in http://agappdom.net/h/silverlight.js you will see how this frame is built. There appears no way (without hijacking this code, which I believe is not allowed under the license terms) to control what gets put into the frame. Only workaround (read: fudge) I can think of is having a simple "dummy" silverlight app that you load up using the conventional Silverlight.js method (including all your HTML for the "not installed" scenario), then once this is launched creating the hosted application. Perhaps others with more knowledge can suggest alternatives.

I myself am just getting round to making the install experience better, and will give this some detailed thought soon.

Thanks for that, IanA, it's a lot clearer now. Do you think that might also explain why I can't get the large 'Install InPlace" prompt button (i.e. only the small 'Get Silverlight' off-page prompt)? Maybe there are cross-domain issues and the agappdom Silverlight.js doesn't allow it?

I'm sorry Andy, but I can't really answer that question as I have only just got round to looking into how to code up install scenarios; but what you say sounds like it's on the right track. As for cross domain, well that's just the point I think: the IFrame source is set to your hosted content on the MS servers. All I can suggest (which is what I'm going to do myself) is look at the MS code in the hosted Silverlight.js.

The one that we all use in our "normal" apps is obfuscated and optimised, and hard to follow; but the hosted version is the same code with the extra functions to deal with the Streaming Service appended on to it. This "new" streaming code is human readable (or at least it was last time I looked a few weeks ago).

If nothing else, consider this a thread "bump", as I too would like know how we create "best practice" install experiences for hosted apps.

Hi,

I am sorry to say it is a known issue which is not due to the Silverlight runtime. It's because of the CreateHostedObjectEx code that is not yet on par with the CreateObjectEx code. We'll fix it in the Silverlight Streaming service. The committed fix date is MIX '08. It'll be very likely be fixed early enough that we'll refresh the service in production before then, but there is no precise ETA on this specific work item just yet. I will notify this forum of this update when it hits the live site.

Cheers.

Good to know you know, so to speak; thanks for the update.

Yes, thanks for the info, Frogs69. Looking forward to this being resolved. Meanwhile it's probably going to be best to generate the installation process from a separate, non-streamed app, as IanA suggested. Incidentally, thanks IanA for the Fiddler hint. I didn't realise such a thing existed. Very useful.

One more thing: while it is not the default experience, and even though the SLS version of Silverlight.js is not yet the latest and greatest, SLS supports in-place install. You can specify it in the manifest by using inPlaceInstallPrompt. Check out http://msdn2.microsoft.com/en-us/library/bb851612.aspx for the details.

Cheers.

In my streaming SL app I couldn't get the inPlaceInstallPrompt in the manifest to display the correct prompt. It would only display the smaller "Get Silverlight" prompt (without the licence terms and auto-update info), so that the SL installation would be done off-page. FWIW I've now changed to a separate install-prompt page, based on a dummy non-streaming SL app, so I can show the correct in-place prompt and some static content. I've also introduced some basic stats; I only count the number of SL-less visitors to the page with the prompt who actually install SL in-place and are then redirected to the correct content page. So far very few visitors are reacting to the prompt; most seem happier to ignore the prompt and continue without SL. Of course this may be because my design isn't good enough to tempt them... or, like me, they may just be reluctant to download additional clutter for their browsers.

Hi,

I too face the sample problem. That is while running ordinary silverlight application I am getting the screen with GetSilverLight Button.(Not Streaming).

Can anybody please help me to resolve that problem?

Thanks,

Praveena T N

 

Check this out for info on smooth install experience.

http://msdn2.microsoft.com/en-us/library/bb882214.aspx

I'm using this technique at http://www.oceanpinesforum.com

uninstall Silverlight, go to above and then click on the "Click to view video with Silverlight link." In IE you should get an auto install and immediate playing of video after SL install.

Unfortunately this technique doesn't seem to work for streamed apps. As I said in an earlier reply, I am using a version of this technique, but I've had to implement it by redirecting visitors to my streamed SL page who don't have SL to a dummy, non-streamed SL page containing similar logic to the above. Even then the "in-place installation" only works in IExplorer, and I suspect it only works reliably under XP (it doesn't seem to work consistently under Vista).

Hopefully this will be resolved with SL 2.0.

Andy, I've not seen any problems with the in-place install on Vista. On IE it is totally automatic, and on other browsers the user is given in-cintext info on what to do after the install.

Not sure exactly what you mean by not working on "streaming" but our video is streamed from a Windows Media Server 2003 box running Windows 2003 Server Enterprise and the in-place install is fine. Just io we are on the same page -- I'm not talking about an inline install.

Here's where you can download a samle project. It is what I used. Works great.

http://www.microsoft.com/downloads/details.aspx?FamilyId=F487DF43-1AFB-4F76-82C8-BB5ACBFFBA1B&displaylang=en

Here is another example to look at:

http://blog.offbeatmammal.com/post/2007/10/Silverlight-Inplace-Install.aspx

Thanks for the help, Joe. I can't quite pin down my Vista problem at the moment - unfortunately I don't have easy access to a Vista development machine - but in my app I've got two pages with streamed SL content. I've now implemented the SL prompt/install as a common, separate page with dummy, non-streamed SL, which correctly displays the inline, inplace install prompt when redirected from either of my live pages under XP. Under Vista though, only one of the pages redirects correctly; the other stays on the live page with a script error, even though both pages seem to have the same logic.

Further investigation required on my part. For what it's worth, I'm counting the number of SL-less visitors to my pages, and the number who take up the invitation to do the in-place install. It's difficult to track visitors who can't do the in-place install because they're running Firefox or whatever, or those who download SL to install later, but so far only about 0.3% of visitors are accepting the in-place install. Not a great take-up rate, but this may be a judgement on my content (which is audio-only).

BTW, just to keep the record straight, my slurs against Vista were scurrilous and ill-founded. As is often the case, there was a problem with my code.

Vista is a fine Operating System, and I won't hear a word said against it...