Related to another question on Superuser, I'm trying to run a Metro based application from the command-line. According to a comment on my superuser question, I could maybe find an answear on a PowerShell command or script. I already tried but found anything on any internet reference about PowerShell and Windows 8...
So, there is some specific way/command to call and run a Metro-style application from a PowerShell command on Windows 8?
There is no direct way to do this but there are a couple indirect ways.
vsdebuglaunchnotify, which comes with Visual Studio, can be called from PowerShell.
You could create your own exe that uses IApplicationActivationManager.
If the app is associated with any file types you could launch an associated file.
More information is covered in this thread on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/8d1b0861-5903-4289-8cb8-541ddaa012fb
Here's a blog post by Powertoe that uses the IApplicationActivationManager way of doing it:
http://powertoe.wordpress.com/2012/11/02/get-a-list-of-metro-apps-and-launch-them-in-windows-8-using-powershell/
He provides code here http://poshcode.org/3740 that provides a Start-MetroApp commandlet for powershell.
Alternatively: I think some Metro Apps have protocol handlers, so that you can talk to them via a URI (e.g. "appname:dosomething") but I'm not sure how widely used this is.
Related
Where can I find the limitations/differences between running Azure Cloud Shell from the browser and Windows Terminal? For example, the "code xxx" command works differently when ran in the browser (opens up the editor) and Terminal (does nothing). Or am I looking at this the wrong way?
#Ziv Rivkis - Apologies for delay in getting back to this thread. Post validation with our internal team it has been called out that we have Cloud Shell entry point limitation, which has been documented here now.
Cloud Shell entry points beside the Azure portal, such as Visual
Studio Code & Windows Terminal, do not support the use of commands
that modify UX components in Cloud Shell, such as Code.
Hope the above information helps, please let us know if you have any further queries. Thank you
Can someone tell me how to properly install this program to run with admin privileges at startup on Windows 10 using WiX?
All the help I've seen via Google has been old ones saying to use the Startup folder. Now, although the Startup folder still seems to work, I don't think it's the preferred way to do it anymore.
I also need think the need to run as admin adds a wrinkle in the process.
I can see few ways to do it:
Set registry values using WIX:
in this case you should add your app install path to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (x86) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run (x64). Problem is to get windows version. I guess it's possible to do by WIX (using few RegistryKey elements with condition) but I haven't tried.
Use custom action to set registry values: the same as previous, but using C#. Also in this case it will be easy to determine windows version and add your app to the right key.
Using custom actions and Task Scheduler. For example you can use this library to add task to run after startup.
Run cmd using WIX to set up Task Scheduler (or via custom actions). The same as previous but without any libs.
A program requesting or requiring admin is a function of the EXE not WiX. The EXE should be manifested to request elevation.
MSFT has said it is not a best practice to have things in startup request admin. It's a horrible user experience.
The better approach is to do what you said you do in your comment. Have a component running as a service that the non-priv UI can communicate with.
I need to (force) reboot Windows from inside a Windows Service written in C#.
The ordinary way of doing it, from a desktop application, shutdown.exe, will probably not work at all? I assume I cannot run an EXE file from inside a service..
Look at the Win32 API InitiateSystemShutdown() and/or InitiateSystemShutdownEx() function.
Also refer to this MSDN article: Shutting Down.
I have tested it, but it does not work inside a Windows Service, it seems..
I am distributing an installer and it will open and run a PowerShell script. The installer will be used by people who have Windows XP and up.
Am I guaranteed that this script will run/execute on all these versions of Windows? I'm looking for the similar Cross-Windows-Platform interoperability that Batch files provide.
I've heard of the error: "File cannot be loaded because the execution of scripts is disabled on this system" what can I do in this scenario? If a user has disabled scripts does that mean I will need to use a different language(maybe just Batch)?
The error you're quoting is due to the default execution policy of PowerShell when it's installed. The message indicates that PowerShell is installed,but by default it's very restricted about what scripts may run for security purposes.
See this article for more on the subject.
If you're going to use PowerShell in your installer, make it part of the system requirements for your software. I can't find anything that definitively says you can redistribute PowerShell with your application, but it's worth asking Microsoft about it.
PowerShell isn't "guaranteed" to be on any desktop OS older than Win7, but it is distributed via Microsoft Update and there's no compelling reason for users to not have it installed.
If you manage this environment, then make sure that powershell is installed on the XP workstations before deploying the script. There is also the option of configuring group policy for powershell to enable script execution and what type of scripts to allow, but that's outside the scope of this question.
If you don't go the group policy route, and instead want to just run the script directly, then in your installer, call powershell.exe directly and pass in the following parameters:
powershell.exe -executionpolicy bypass -file \\path\to\script
The script path doesn't have to be a unc path if it's local, that was just an example.
No, PowerShell scripts are not guaranteed to run on Windows XP or Windows Server 2003. Although PowerShell is available for these platforms, it's not installed by default.
No, PowerShell scripts may not work, because the PowerShell isn't pre-installed on Win XP/2003.
It is included in the Management Framework for XP/2003.
For me, I suggest to use the .bat instead.
Is is possible to install a gadget to a user's desktop somehow? I believe I need to copy all the files to a the user's gadget folder, e.g.
C:\Users\curusername\AppData\Local\Microsoft\Windows Sidebar\Gadgets\test.gadget
But copying the files here doesn't run the gadget. How can I register/activate it?
Is it enough to shell execute test.gadget?
Late answer, I know, but the other answer is talking about Windows Sideshow Gadgets, and your question is related to Windows Desktop Gadgets.
It's possible to run the gadget on Windows 7 without shell executing the archive, you need to use the IDesktopGadget interface method RunGadget. Call RunGadget on a folder containing your gadget's files and it will appear on the user's desktop.
A description of the RunGadget method and sample code for C++ is offered here:
http://msdn.microsoft.com/en-us/library/dd378390(VS.85).aspx
If you're using .NET, refer to a previous question I asked for how to implement the IDesktopGadget interface:
Stack Overflow - C#: Referencing a windows shell interface
For backwards compatibility (Vista), I would recommend you fall back to the shell execute method.
The following MSDN Article covers this:
http://msdn.microsoft.com/en-us/library/cc982277(VS.85).aspx