%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
