本地部署和从应用商店部署时的不同应用行为 [英] Different app behaviour when deployed locally and from Store

问题描述

从 Windows 应用商店(测试版)部署应用程序时，我遇到了奇怪的问题.该应用程序编写为 Windows Phone 8.1 RunTime.

I'm encountering strange issue when app is deployed from Windows Store (beta version). The app is written as Windows Phone 8.1 RunTime.

我有一个用 C++/C# 编写的小型 Windows 运行时组件，用于检查文件是否存在:

I've a small windows runtime component written in C++/C# which checks for file existence:

bool FileEx::FileExists(String^ path)
{
    std::wstring pathW(path->Begin());
    std::string myPath(pathW.begin(), pathW.end());
    FILE *file = NULL;
    if (fopen_s(&file, myPath.c_str(), "r") == 0)
    {
         fclose(file);
         return true;
    }
    else return false;
}

测试方法:

现在让我们用两个文件对其进行测试 - 一个在本地文件夹中创建，一个在 MusicLibrary 中的文件夹中.一切都在主项目中完成，该项目在 C++/C# 中使用上述方法引用了 WRC.

TESTING METHOD:

Now let's test it with two files - one created in local folder and one in folder in MusicLibrary. Everything is done in main project, which has a reference to WRC with above method in C++/C#.

const string localFileName = "local.txt";
const string musicFileName = "music.txt";
StorageFolder localFolder = ApplicationData.Current.LocalFolder;
StorageFolder musicFolder = await KnownFolders.MusicLibrary.CreateFolderAsync("MyFolder", CreationCollisionOption.OpenIfExists);
await localFolder.CreateFileAsync(localFileName, CreationCollisionOption.ReplaceExisting); // create local file
await musicFolder.CreateFileAsync(musicFileName, CreationCollisionOption.ReplaceExisting); // create file in MusicLibrary

a) 本地文件Fist - 用纯 C# 测试:

a) Local file Fist - test with pure C#:

// First check with C# if file exists - LOCAL FILE
StorageFile checkFile = null;
try { checkFile = await localFolder.GetFileAsync(localFileName); }
catch { checkFile = null; }
if (checkFile != null) await Trace.WriteLineAsync(false, "File exists with path = {0}", checkFile.Path);
else await Trace.WriteLineAsync(false, "File doesn't exist with path = {0}", checkFile.Path);

第二个带书面组件:

Exception exc = null;
bool check = false;
try
{
    string path = string.Format(@"{0}\{1}", localFolder.Path, localFileName);
    await Trace.WriteLineAsync(false, "Attempt with WRC path = {0}", path);
    check = FileEx.FileExists(path);
}
catch (Exception ex) { exc = ex; }
if (exc != null) await Trace.WriteLineAsync(false, "Exception WRC");
else await Trace.WriteLineAsync(false, "No exception WRC, file exists = {0}", check);

b) 与音乐库文件夹中的文件相同:

b) The same with file in music library folder:

Fist - 用纯 C# 测试:

Fist - test with pure C#:

checkFile = null;
try { checkFile = await musicFolder.GetFileAsync(musicFileName); }
catch { checkFile = null; }
if (checkFile != null) await Trace.WriteLineAsync(false, "File exists with path = {0}", checkFile.Path);
else await Trace.WriteLineAsync(false, "File doesn't exist with path = {0}", checkFile.Path);

第二个带书面组件:

check = false;
exc = null;
try
{
   string path = string.Format(@"{0}\{1}", musicFolder.Path, musicFileName);
   await Trace.WriteLineAsync(false, "Attempt with WRC path = {0}", path);
   check = FileEx.FileExists(path);
}
catch (Exception ex) { exc = ex; }
if (exc != null) await Trace.WriteLineAsync(false, "Exception WRC");
else await Trace.WriteLineAsync(false, "No exception WRC, file exists = {0}", check);

结果:

在任何情况下都不例外，正如纯 C# 方法所示，这两个文件在创建后都存在.正如你在下面的图片中看到的，当应用程序通过 Visual Studio 部署时，它可以正常工作，运行时组件显示这两个文件，但是当应用程序从商店下载时，情况就不一样了——WRC 方法适用于本地文件，但是不适用于 MusicLibrary 中的这些.

RESULTS:

There is no exception in any case, as pure C# methods show, both files exists after their creation. As you can see in the pictures attached below, when app is deployed via Visual Studio, it works properly, runtime component shows both files, but when app is download from store, the situation is different - the WRC method works for local files, but not for these in MusicLibrary.

在这两种情况下，文件路径相同，在两个部署中运行时组件都可以工作，因此第一个文件存在.尽管在 packageappx.manifest 文件中设置了所有必要的功能(本地部署有效)，但 Windows 运行时组件似乎无权访问 MusicLibrary.

In both cases file paths are the same, in both deployments runtime component works, hence the first file exists. It seems like windows runtime component doesn't have access to MusicLibrary, despite all necessary capabilities being set in packageappx.manifest file (local deployment works).

有谁知道为什么 Windows 运行时组件无法访问 MusicLibrary 中的文件?Windows 运行时组件是否需要一些额外的功能?
有什么办法让它工作吗?

Does anyone have an idea why the windows runtime component doesn't have access to a file in MusicLibrary? Does windows runtime component need some additional capabilities?
Any way to make it work?

推荐答案

应用商店的行为是正确的:应用没有对安装和应用数据文件夹之外的文件系统的权限.Win32 和 C 运行时函数直接访问文件，因此需要直接访问权限.

The behavior from the store is correct: the app doesn't have permissions to the file system outside of its installed and app data folders. Win32 and C runtime functions access the files directly and so need direct access permissions.

StorageFile 类与文件代理一起工作，因此可以利用声明的功能等.代理代表应用读取文件并通过 StorageFile 流式传输文件内容.

The StorageFile class works with the file broker and so gets the advantage of the declared capabilities, etc. The broker reads the file on the apps behalf and streams the file contents through the StorageFile.

应用必须使用 StorageFile 来读取或写入其应用数据和安装位置之外的文件

Apps must use StorageFile to read or write files outside their app data and installed location

我们已标记测试和生产之间的行为差​​异以供调查.

We've flagged the behavior difference between testing and production for investigation.

这篇关于本地部署和从应用商店部署时的不同应用行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！