wpf UriFormatException:无效的 URI:指定的端口无效

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/6005398/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-08 22:51:25  来源:igfitidea点击:

UriFormatException : Invalid URI: Invalid port specified

wpfxamlresourcesuri

提问by Berryl

The assembly qualified string used as a parameter below for a Uri works in XAML, but gives me the error shown when used in code.

下面用作 Uri 参数的程序集限定字符串在 XAML 中工作,但在代码中使用时给了我显示的错误。

I tried every kind of UriKind with the same result. How can I fix this?

我尝试了各种 UriKind,结果都一样。我怎样才能解决这个问题?

[Test]
public void LargeImageSource_IsKnown()
{
var uri = new Uri(
        "pack://application:,,,/" + 
        "MyAssembly.Core.Presentation.Wpf;component/" + 
        "Images/Delete.png", UriKind.RelativeOrAbsolute);

Assert.That(
        _pickerActivityCollectionVm.DeleteActivityCommand.LargeImageSource,
        Is.EqualTo(uri));
}

System.UriFormatException : Invalid URI: Invalid port specified.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString, UriKind uriKind)

UPDATE

更新

Based on Thomas' superb answer and my own comments about readability, I wound up using the following in my BaseTestFixture class. Hope this helps someone else.

基于 Thomas 出色的回答和我自己对可读性的评论,我最终在 BaseTestFixture 类中使用了以下内容。希望这对其他人有帮助。

    protected virtual void OnFixtureSetUp() {
        // logging, other one time setup stuff...

        const string scheme = "pack";
        if (!UriParser.IsKnownScheme(scheme)) {
            Assert.That(PackUriHelper.UriSchemePack, Is.EqualTo(scheme));
        }
    }

回答by Thomas Levesque

That's because you're executing this code while the pack://scheme is not yet registered. This scheme is registered when you create the Applicationobject. You can add this code in the setup of your test fixture:

那是因为您在pack://方案尚未注册时执行此代码。该方案在您创建Application对象时注册。您可以在测试装置的设置中添加此代码:

[SetUp]
public void Setup()
{
    if (!UriParser.IsKnownScheme("pack"))
        new System.Windows.Application();
}


EDIT: actually it seems the pack://scheme is registered in the type initializer of the PackUriHelperclass (which happens to be used by the Applicationclass). So actually you don't need to create an instance of Application, you only need to access a static member of PackUriHelperto ensure the type initializer has run:

编辑:实际上,该pack://方案似乎已在类的类型初始值设定项中注册PackUriHelper(恰好由Application类使用)。所以实际上您不需要创建 的实例Application,您只需要访问 的静态成员 PackUriHelper以确保类型初始值设定项已运行:

[SetUp]
public void Setup()
{
    string s = System.IO.Packaging.PackUriHelper.UriSchemePack;
}

回答by Mathieu Frenette

It appears that accessing PackUriHelper.UriSchemePackonly registers the packscheme, notthe applicationscheme, which I needed to use the pack://application:,,,/syntax in my unit tests. I therefore had to use the new Application()approach, which worked fine for registering both schemes.

看来,访问PackUriHelper.UriSchemePack只有注册pack方案,不是application方案,我需要使用pack://application:,,,/语法在我的单元测试。因此,我不得不使用这种new Application()方法,它可以很好地注册这两种方案。

回答by Daniel S.

If you're seeing this error in a Windows Store / WinRT project:

如果您在 Windows 应用商店/WinRT 项目中看到此错误:

I wasn't able to use the "pack://" syntax at all when trying to load a resource in my C# app. What worked was ms-appx:// syntax of this kind:

尝试在我的 C# 应用程序中加载资源时,我根本无法使用“pack://”语法。有效的是 ms-appx:// 这种语法:

ms-appx://[project folder]/[resource path]

For example, I wanted to load a resource dictionary named "styles.xaml" from a folder "core". This URI ended up working for me:

例如,我想从文件夹“core”加载名为“styles.xaml”的资源字典。这个 URI 最终对我有用:

dictionary.Source = new System.Uri("ms-appx:///core/styles.xaml");

Even though the question specified WPF, the problem seemed extremely similar but ended up having a completely different solution, which took a while to find, and existing answers didn't help at all.

尽管问题指定了 WPF,但问题似乎非常相似,但最终得到了完全不同的解决方案,需要一段时间才能找到,现有的答案根本没有帮助。

Again, this solution does not apply to WPF

同样,此解决方案不适用于 WPF