我想使用常规 .NET Framework类库中的源代码构建 Windows Store类库。理想情况下,我不想修改原始源代码文件。
在 .NET Framework库的一些源代码文件中,静态成员使用的是在常规 .NET Framework API中定义的类, .NET for Windows应用商店 API,但只有 .NET Framework 成员的一部分可用于 Windows应用商店。
一个具体示例是System.IO.Path,其中GetFullPath method不适用于 Windows应用商店应用。
在我的 Windows Store类库中合并此方法的替换是相当简单的,并且让原始源代码调用此方法。我的问题是,是否有任何方式我可以在不修改原始源代码文件的情况下执行此操作?
到目前为止,我还没有找到一个令人满意的解决方案来解决这个问题,但我已经通过实现例如我的 Windows Store类库解决了这个问题。另一个命名空间中的Path.GetFullPath(string)
方法:
namespace WindowsStoreLib.System.IO {
public static class Path {
public static string GetFullPath(string path) { ... }
}
}
然后在原始文件中添加预处理程序指令:
#if NETFX_CORE
using Path = WindowsStoreLib.System.IO.Path;
#endif
不是否需要修改原始源代码文件,是否存在此问题的替代解决方案?
答案 0 :(得分:5)
不,你不能,简单。
当我在做跨平台的事情时,我倾向于为不同的平台编写一个实用程序类,它具有不同的实现(通过#if
) - 然后我的核心代码只调用实用程序类。
答案 1 :(得分:0)
我最近在使用Entity Framework类做了类似的事情,因为我需要将2个字段的特定输出添加为1,并且每次更新时都会从designer.cs中删除它。但是它们不是静态类或静态方法,而是应该使用相同的。
使用要扩展的类的名称创建一个新的类文件,并使用部分限定符。
namespace WindowsStoreLib.System.IO {
public partial static class Path {
public static string GetFullPath(string path) { ... }
}
}
答案 2 :(得分:0)
正如Marc所说,预处理器指令似乎是唯一的解决方案。
但是当我读到“静态课程”和“现有课程”时,首先想到的是“扩展方法”。如果您在代码所在的同一名称空间中为Path创建了一个扩展方法,会发生什么?
namespace MyNamespace.WhereMyCodeIs
{
using System.IO;
public static class ExtensionMethods
{
public static string GetFullPath(this Path pathObject, string path)
{
// Implementation
}
}
}
我真的不确定这是否会成功,但也许我们可以找到解决方法。