If SL ever becomes 64 bit, then %programfiles% will still resolve to the right folder.
On Wed, Oct 6, 2010 at 11:37 PM, Chris Anderson <[email protected]>wrote: > Ah yes, of course, Silverlight is 32 bit only - for the moment anyway. And > yep, you could install an app via sllauncher.exe if you have elevated trust > (I didn't think of that). As you say, the isolated storage solution to > passing parameters between instances has its fair share of issues :). > > Chris > > > On 6 October 2010 22:58, Miguel Madero <[email protected]> wrote: > >> You're right. You would just use %programfiles% >> Since Silverlight (hence any SL app and any SL host) is 32 bit that env >> variable will return either c:\program files in a 32 bit OS or c:\program >> files (x86) on a 64bit one. >> >> Too bad about the lack to pass params. In my case they're coming from the >> same domain and I was looking to do use the site store as the last resort, >> can get a bit messy since I might initiate multiple instances almost at the >> same time, so I would have to have some sort of queue, possible adding >> locks, etc... I'll have to think this through, but is far from ideal. >> >> About the installation. We can do it passing from sllauncher. My dream is >> to have an ApplicationManager that could perform this tasks for me, but if I >> want to write my own, I'll need Elevated Trust for any of these (start >> another app, install it, etc). >> >> >> >> On Wed, Oct 6, 2010 at 3:26 PM, Chris Anderson >> <[email protected]>wrote: >> >>> %programfiles(x86)% only works on Windows 64 bit unfortunately. As far >>> as I know, there's not an easy way to determine this path on both 32 and 64 >>> bit editions of Windows (unless someone has some tips for doing so). >>> >>> There's no way of passing parameters to an OOB app unfortunately (AFAIK). >>> The only way I know of is to write the parameters as settings in isolated >>> storage, or to a known location (like, dare I say, the registry if you >>> have elevated trust). If it is the same application being loaded, you can >>> write them to the application store, or if the application to be loaded is >>> from the same domain then you could use the site store. If the application >>> originates from a different domain you're somewhat out of luck, and would >>> need to use the known location method. >>> >>> As for your scenario to install another Silverlight application, I can't >>> see that being possible. You could always host another Silverlight >>> application within your application using the WebBrowser control (set up so >>> that if run within the browser it will only request to be installed, like >>> the Facebook application does). You could pass it parameters via the URL >>> query parameters. However, the user will always need to be involved in >>> initiating the actual installation process. The application will then >>> automatically launch once installed. >>> >>> Chris >>> >>> >>> >>> On 6 October 2010 09:57, Miguel Madero <[email protected]> wrote: >>> >>>> I don't have a blog anymore so I'll leave it on your capable hands. >>>> >>>> You don't have to guess the path, this should work, but still requires >>>> Elevated Trust: >>>> call "%programfiles(x86)%\Microsoft Silverlight\sllauncher.exe" >>>> >>>> I was thinking to start a second app. It would be nice to have >>>> something like: >>>> ApplicationManager.StartApp("SomeOtherAppInTheSamePathAsThisOne.xap"); >>>> ApplicationManager.StartApp(" >>>> http://anotherdomain.com/Something/CoolApp.xap";, >>>> "param1=value1;param2=MiguelsCool"); >>>> >>>> That option should check first if the app is installed (based on the >>>> origin), if not, install it, then start it. I should also be able to get a >>>> ref to it and communicate with it (using pipes?) or at least have a way to >>>> pass initparams. All of this without elevated trust. >>>> >>>> We should even be able to start another instance of the same OOB App >>>> with just diferent parameters. >>>> >>>> >>>> BTW, is there a way to send initparams to an OOB App? >>>> >>>> >>>> >>>> On Tue, Oct 5, 2010 at 6:41 PM, Chris Anderson <[email protected] >>>> > wrote: >>>> >>>>> Yep. Ideally you'd have an Application.Current.Restart() method, so >>>>> elevated trust wasn't necessary though :). You'd still have to use COM >>>>> Interop to find the user's Program Files folder though (the >>>>> System.Environment.GetFolderPath method won't return it), and then use COM >>>>> Interop to run sllauncher.exe. Whether it matters that the app is still >>>>> running when the new instance is loaded, I don't know, but I think it >>>>> would >>>>> be OK. I assume the new version (if doing immediately after an update has >>>>> been downloaded) will have already been put in the right place, and not >>>>> waiting for the current instance of the app to close. One of us might >>>>> have >>>>> to give it a go as a proof of concept exercise and blog the results :). >>>>> >>>>> Chris >>>>> >>>>> >>>>> On 5 October 2010 17:10, Miguel Madero <[email protected]> wrote: >>>>> >>>>>> All of the options we mentioned required full trust, but this one at >>>>>> least doesn't require COM Interop to inspect the file system :) >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Oct 5, 2010 at 4:09 PM, Chris Anderson < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Ah, nice. Will have to remember that one. Of course you'll need >>>>>>> elevated trust to be able to do that, but looks like a good solution. >>>>>>> Thanks for sharing Miguel. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>>> On 5 October 2010 15:26, Miguel Madero <[email protected]> wrote: >>>>>>> >>>>>>>> Everyone, >>>>>>>> >>>>>>>> I remember a few months ago at an SDDN meeting we were talking about >>>>>>>> options to start an OOB App like looking at the shortcuts in the start >>>>>>>> menu >>>>>>>> or trying to guess based on the random paths that the app might get >>>>>>>> installed on. I found a nice option. Essentially we use the 'origin' >>>>>>>> as the >>>>>>>> key instead of trying to find the path to the xap. >>>>>>>> >>>>>>>> >>>>>>>> From Tim Heuer >>>>>>>> blog<http://timheuer.com/blog/archive/2010/03/25/using-sllauncher-for-silent-install-silverlight-application.aspx> >>>>>>>> >>>>>>>> Automatically Launching the App >>>>>>>> >>>>>>>> So what if you wanted to also automatically launch the app after >>>>>>>> installing (i.e., the CD/DVD ‘autorun’ scenario). You again would use >>>>>>>> sllauncher.exe to do this for you *after you’ve installed the app*. >>>>>>>> Using our same sample above here would be the command: >>>>>>>> >>>>>>>> 1: "%ProgramFiles%\Microsoft Silverlight\sllauncher.exe" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2: /emulate:"Silverface.xap" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3: >>>>>>>> /origin:"http://www.silverlight.net/content/samples/apps/facebookclient/ClientBin/Silverface.xap"; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4: /overwrite >>>>>>>> >>>>>>>> Notice the *emulate* command. This is the launcher. Now you’ll >>>>>>>> notice that this isn’t the same command-line options if you looked at >>>>>>>> an >>>>>>>> installed applications’ created shortcuts. Because the folder where >>>>>>>> the XAP >>>>>>>> gets installed is pretty random, we use the origin as the hint to the >>>>>>>> sllauncher.exe program to find the right app for us and start it up. >>>>>>>> I’ve >>>>>>>> found that using /overwrite will also give a more consistent behavior. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Miguel A. Madero Reyes >>>>>>>> www.miguelmadero.com (blog) >>>>>>>> [email protected] >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> ozsilverlight mailing list >>>>>>>> [email protected] >>>>>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ozsilverlight mailing list >>>>>>> [email protected] >>>>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Miguel A. Madero Reyes >>>>>> www.miguelmadero.com (blog) >>>>>> [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> ozsilverlight mailing list >>>>>> [email protected] >>>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> ozsilverlight mailing list >>>>> [email protected] >>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight >>>>> >>>>> >>>> >>>> >>>> -- >>>> Miguel A. Madero Reyes >>>> www.miguelmadero.com (blog) >>>> [email protected] >>>> >>>> _______________________________________________ >>>> ozsilverlight mailing list >>>> [email protected] >>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight >>>> >>>> >>> >>> _______________________________________________ >>> ozsilverlight mailing list >>> [email protected] >>> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight >>> >>> >> >> >> -- >> Miguel A. Madero Reyes >> www.miguelmadero.com (blog) >> [email protected] >> >> _______________________________________________ >> ozsilverlight mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight >> >> > > _______________________________________________ > ozsilverlight mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight > > -- Miguel A. Madero Reyes www.miguelmadero.com (blog) [email protected]
_______________________________________________ ozsilverlight mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
