2011-05-14 33 views
47

El ensamblado de cadena calificada utilizada como parámetro a continuación para un Uri funciona en XAML, pero me da el error que se muestra cuando se utiliza en el código.UriFormatException: URI no válido: puerto no válido especificado

Probé todo tipo de UriKind con el mismo resultado. ¿Cómo puedo arreglar esto?

[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) 

ACTUALIZACIÓN

Basado en respuesta excelente Thomas y mis propios comentarios acerca de la legibilidad, terminé usando el siguiente en mi clase BaseTestFixture. Espero que esto ayude a alguien más.

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)); 
     } 
    } 
+1

Como FYI Nota: Estoy frente al mismo problema utilizando una ventana de WPF alojada en un proceso nativo. –

Respuesta

68

Eso es porque estás ejecución de este código, mientras que el esquema de pack:// aún no se ha registrado. Este esquema se registra cuando crea el objeto Application. Puede agregar este código en la configuración de su dispositivo de prueba:

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

EDIT: En realidad parece que el esquema de pack:// se ha registrado en el inicializador de tipo de la clase PackUriHelper (que pasa a ser utilizado por la clase Application). Así que en realidad no es necesario crear una instancia de Application, sólo es necesario tener acceso a un miembro estático de PackUriHelper para asegurar el tipo de inicialización se ha quedado:

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

Sweet - gracias Thomas – Berryl

+1

Mejor aún, aunque me gustó la legibilidad de la primera versión. Cambié la cadena de 's' a 'ensurePackSchemeIsKnown', así que tengo la oportunidad de recordar por qué hice esto una semana más o menos a partir de ahora. Cheers – Berryl

+3

+1 La primera muestra de código funcionó para mí, pero la segunda no.Pude mejorar un poco la primera muestra al hacer esto: var current = Application.Current; el acceso a la clase de aplicación es suficiente para activar el constructor estático de la aplicación, que configura todas las cosas de Uri que necesito ... –

9

Parece que el acceso a PackUriHelper.UriSchemePack sólo registra la pack esquema, no el esquema application, que necesitaba usar la sintaxis pack://application:,,,/ en mis pruebas unitarias. Por lo tanto, tuve que usar el enfoque new Application(), que funcionó bien para registrar ambos esquemas.

+0

Alternativamente, solo haciendo referencia a la clase de la aplicación se ejecutará el constructor estático que inicializa lo que requirió. Simplemente use esto: var current = Application.Current; –

7

Si usted está viendo este error en un proyecto de Windows tienda/WinRT:

yo no era capaz de utilizar el "paquete: //" sintaxis en absoluto cuando se trata de cargar un recurso en mi Aplicación C#. Lo que funcionó fue ms-appx: // sintaxis de este tipo:

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

Por ejemplo, quería cargar un diccionario de recursos denominado "styles.xaml" de un "núcleo" carpeta. Este URI terminó trabajando para mí:

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

A pesar de que la pregunta especifica WPF, el problema parecía muy similar, pero llegó a tener una solución completamente diferente, que tomó un tiempo para encontrar y respuestas existentes no ayudó en absoluto.

Una vez más, esta solución no se aplica a WPF

Cuestiones relacionadas