无头无阻地运行一个地铁应用程序 [英] Running a metro app headlessly

问题描述

我碰到了一些障碍，我希望有人可以帮忙！

我写了一个metro应用程序作为单元测试亚军，我现在需要能够无头调用这个应用程序，以便它可以用于生成过程中的验证。地铁应用程序的工作方式是运行一堆单元测试，生成一个包含测试结果的XML文件，并将结果显示给用户。

理想情况下，我将有一个简单的脚本来运行metro应用程序，执行测试，退出应用程序，然后有能力读取生成的XML文件中的结果。这是可能的，如果是的话，最好的办法是什么？

以下是一些更具体的问题：

1. 如何无恶意地启动metro应用程序，并且在metro应用程序中有一种方法可以检测到这种情况，使其不会等待用户输入？




2. 是否可以从外部进程访问metro应用程序包中的文件？

编辑 - 解决方法是创建一个自定义的Visual Studio测试运行器，然后找到一种方法来自动运行与每个版本的测试。我知道这可以在IDE中完成，但是我不确定是否有一种方法可以用脚本来完成。

解决方案

<我想你早已解决了这个问题，但为了别人的目的，我没有太多的麻烦。要以自动/无头的方式执行Metro应用程序，我编写了一个简单的桌面命令行实用程序，它采用metro应用程序的名称，并使用 IApplicationActivationManager 界面启动它。然后我可以从脚本调用该实用程序。

该接口的第二个参数 ActivateApplication 方法是一个字符串，被传递到激活的应用程序，有点像命令行参数。它显示为应用程序 OnLaunched 所接收的 LaunchActivatedEventArgs 的参数 / code>处理程序。 Visual Studio模板项目中的 OnLaunched 的默认实现在第一次导航到它时将这个值传递给 MainPage 它通过 OnNavigatedTo 处理程序进入参数属性 NavigationEventArgs 。您可以在任何地方更方便地捕捉它。

我的启动程序实用程序会传递一个硬编码的标志，并转发它自己的命令行参数。这允许顶层脚本将任意数据传递到Metro应用程序。该应用程序可以使用这些数据来实现它的无头运行并运行测试。它可以将任何类型的结果数据吐出到其中的一个文件夹中（如 LocalFolder ），然后桌面应用程序可以从％LOCALAPPDATA％\Packages\APPNAME\LocalState 中读取。我设置我的启动程序实用程序等待结果文件出现后启动应用程序，然后使用它们来确定自己的退出代码。启动工具不能杀死应用程序，但应用程序可以通过 CoreApplication.Exit 。

这个设置工作很好，但是一个问题是我现在运行的是，应用程序并不总是被启动到前台，运行时将暂停/终止该应用程序，它已经不是前台应用程序一段时间（目前约10-15秒）。所以任何花费太长时间的测试都不能用这种方法，除非我还没有发现一些解决方法（当我遇到这个问题的时候我正在寻找）。

I've hit a bit of a roadblock, and I'm hoping someone can help!

I've written a metro application that serves as a unit test runner, and I now need to be able to call this application headlessly so that it can be used for validation in the build process. The way the metro app works is it runs a bunch of unit tests, generates an XML file that contains the test results, and displays the results to the user.

Ideally, I would have a simple script that would run the metro app, execute the tests, exit the app, and then have the ability to read the results in the generated XML file. Is this possible, and if so, what's the best way to do it?

Here are some more specific questions:

1. How can one start a metro app headlessly, and in the metro app is there a way to detect this so that it does not wait for user input?

2. Is it possible to access files within the package of a metro app from an outside process?

EDIT - A workaround would be to create a custom Visual Studio test runner and then find a way to run the tests automatically with each build. I know this can be done within the IDE, but I'm not sure if there's a way to do this with a script.

解决方案

I imagine you've long since moved past this problem, but for the sake of anyone else looking to do this, I got it to work without too much hassle. To execute a Metro app in an automated/headless fashion, I wrote a simple desktop command-line utility that takes the name of a metro app and makes use of the IApplicationActivationManager interface to launch it. I can then call that utility from a script.

The second argument to that inteface's ActivateApplication method is a string that gets passed in to the activated app, kind of like command-line arguments. It shows up as the Arguments property of the LaunchActivatedEventArgs that is received by the app's OnLaunched handler. The default implementation of OnLaunched in the Visual Studio template projects passes this value to the MainPage when it first navigates to it, where it comes through into the OnNavigatedTo handler as the Parameter property of the NavigationEventArgs. You could catch it in whichever place is more convenient.

My launcher utility passes a hard-coded flag through there, as well as forwarding its own command-line arguments. That allows the top-level script to pass arbitrary data down into the Metro app. The app can use that data to realize that it's running headless and run its tests. It can spit out whatever kind of result data you like into one of its folders (like its LocalFolder), which a desktop app can then read from %LOCALAPPDATA%\Packages\APPNAME\LocalState. I setup my launcher utility to wait for the result files to appear after launching the app, and then use them to determine its own exit code. The launcher utility can't kill the app afterward, but the app can kill itself when it's done via CoreApplication.Exit.

That setup worked great for a while, but a problem that I'm running into now is that the app isn't always launched to the foreground, and the runtime will suspend/terminate the app after it hasn't been the foreground app for some amount of time (currently ~10-15 seconds). So any tests that take too long won't work with this approach, barring some workaround that I haven't discovered yet (which I was searching for when I came across this question).

这篇关于无头无阻地运行一个地铁应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！