Sector 7G

Review: Scrum y XP desde las Trincheras

Pedroafa — Wed, 08 Jul 2009 06:44:00 GMT

Título: Scrum and XP from the Trenches
Autor: Henrik Kniberg
Nº Páginas: 140

En Scrum and XP from the Trenches su autor Henrik Kniberg habla sobre su experiencia con estas metodologías. Cuenta como ha aplicado y combinado estas dos metodologías los equipos de desarrollo de su empresa. Esto hace que se trate de un libro muy práctico, ameno y de fácil lectura.

Henrik no profundiza mucho en los conceptos, pero sí que hace una descripción breve sobre ellos. Se centra más en explicar cómo ha aplicado las diferentes herramientas de Scrum y cuáles han sido sus conclusiones después de ver cómo funcionaban. Además habla de cómo ha combinado Scrum con XP y de los resultados obtenidos de ello.

Lo interesante de este libro es justo el enfoque dado por el autor. Ver Scrum desde la práctica y la experiencia y no solamente desde el papel y la teoría.

A lo largo del libro, Henrik habla de cómo realizar las pilas de producto, de cómo planificar los Sprints, cómo hacer retrospectivas del sprint, de cómo hacer pruebas, etc.… Concretamente el índice es el siguiente:

Introducción
Cómo hacemos pilas de producto
Cómo nos preparamos para la planificación de Sprint
Cómo hacemos la planificación de Sprint
Cómo comunicamos los Sprints
Cómo hacemos pilas de Sprint
Cómo distribuimos la sala del equipo
Cómo hacemos Scrum diarios
Cómo hacemos la demo de sprint
Cómo hacemos retrospectivas de sprint
Descansos entre Sprints
Cómo combinamos Scrum con XP
Cómo hacemos pruebas
Cómo manejar múltiples equipos Scrum
Cómo gestionamos equipos distribuidos geográficamente
Lista de comprobación del Scrum Master

Además al final de libro, el propio autor recomienda una serie de lecturas bastante interesantes sobre el tema:

El libro lo podréis contra en varios idiomas, también en español, aunque personalmente os recomiendo la versión en inglés.

Localización de una Aplicación Basada en PRISM

Pedroafa — Wed, 01 Jul 2009 19:57:00 GMT

Es difícil localizar una aplicación WPF con las herramientas proporcionadas en el .Net Framework 3.5. El proceso para realizarlo sería el siguiente:

Generar un diccionario de recursos.
Enlazar el diccionario a la aplicación en el App.xaml.
Ejecutar el MSBuild script para generar un Id único para cada control localizable en la aplicación.
Ejecutar la herramienta LocBaml (incluida en el SDK) para extraer todos los Aid en un archivo separado por comas.
Copiar el archivo generado por LocBaml a una carpeta (una para cada lenguaje).
Volver a ejecutar la herramienta LocBaml para importas todas las entradas dentro del diccionario.
Compilar.

Esta forma de hacerlo tiene algunos problemas:

Sólo puedes tener un archivo de diccionario de recursos por aplicación. Cada módulo no podrá tener el suyo propio.
El proceso es difícil y propenso a los errores. Lo que hace que sea costoso de mantener.
No puedes cambiar el lenguaje de la aplicación en tiempo de ejecución. Es necesario reiniciar la aplicación para poder reflejar el cambio de idioma.

Para arquitecturas como PRISM (Composite Application Guidance for WPF), que se basan en módulos, es muy importante que cada módulo pueda tener sus propios archivos de recursos. Puede que estos módulos sean desarrollados por separado y equipos diferentes. Además es interesante que el proceso de localización sea sencillo y fácilmente mantenible. Normalmente los textos de las traducciones suelen cambiar bastante.

Para solucionar esto, y solventar todos los problemas existe WPFLocalizeExtension. Se trata de un framework open source. Este framework ha sido modificado para soportar localización de assemblies (plug-in) cargados dinámicamente.

Este framework se basa en archivos de recursos lo que hace que sea bastante sencillo mantener las traducciones de los diferentes idiomas. Así que cada módulo puede tener su propio archivo de recursos con sus traducciones. Además, permite cambios de idioma en caliente.

Ahora el proceso de localización es más sencillo:

Modificar el archivo de proyecto .csproj añadiendo <UICulture>en-US</UICulture> en el primer tag PropertyGroup. Este será el lenguaje neutral de la aplicación.
Crear un archivo de recursos para el Lenguaje Neutral (Shell.resx) y añadir una entrada por cada control que se necesite localizar:
- Para añadir otro idioma copiar y pegar el archivo de recursos (Shell.resx) y renombrarlo a Shell.es-ES.resx. Traducir todas las etiquetas a español, en este caso.
- Para localizar una vista (un archivo .xaml):
  - Añadir una referencia a la librería de WPFLocalizeExtension. xmlns:loc="clr-namespace:LocalizeExtension.Localization;assembly=LocalizeExtension".
  - Para la propiedad que haya que traducir utilizar: {loc:LocText loc:Key=CustomerLabel, loc:Dict=Shell, loc:Assembly=MyAssembly.Shell}.
  - Key: Es el nombre del texto a mostrar.
  - Dict: Es el nombre del archivo de recursos.
  - Assembly: Es la dll donde se encuentra el archivo de recursos.
Compilar.

Este proceso es mucho menos complejo que el estándar y facilita bastante las cosas como se puede ver.

A program on your computer has corrupted your default search provider setting for Internet Explorer

Pedroafa — Mon, 29 Jun 2009 21:59:17 GMT

Hace unas semanas el Windows Update decidió actualizar mi versión de Explorer de la versión 7 a la 8 en mi Windows XP. Desde entonces al abrir el explorer ha estado apareciendo el siguiente mensaje de error:

“A program on your computer has corrupted your default search provider setting for Internet Explorer.

Internet Explorer has reset this setting to your original search provider, Live Search (search.live.com).

Internet Explorer will now open Search Settings, where you can change this setting or install more search providers.”

La solución al problema es bastante sencilla:

Con el IE 8 cerrado ir a esta clave de registro: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer\User Shell Folders.
Añadir una nueva clave de registro del tipo Expandable String value. Con la key AppData y el campo value %USERPROFILE%\Application Data.
Abrir el IE 8 y verificar que no vuelve a salir el mensaje.

Desarrollando Aplicaciones Cliente y Web con WFP y Silverlight

Pedroafa — Wed, 24 Jun 2009 07:54:00 GMT

El otro día a raíz de un post de Juan, Windows Presentation Foundation. El final de Windows Forms…, alguien preguntaba si era posible desarrollar la misma aplicación para ejecutarla en un cliente Windows y un cliente web. Posible sí que es y además hay varias opciones para conseguirlo, aunque habrá que tener en cuenta las limitaciones que existen.

La primera opción que se presenta es crear una aplicación WPF y XBAP. Esto se puede conseguir usando el Template para Visual Studio, Flexible Application. Este template lo que hace es proveer en un solo proyecto la capacidad de compilar en exe y xbap. Dependiendo del tipo de compilación utilizado se generará la aplicación para que corra bajo Windows o se ejecute en el Explorer.

Evidentemente esta práctica tiene sus ventajas e inconvenientes.

Ventajas:

Con un solo desarrollo tiene las dos aplicaciones. El código va a ser el mismo para los dos entornos, simplemente va a cambiar el tipo de compilación realizada.

Desventajas:

Sólo para plataforma Windows. Cómo XBAP se ejecuta en el cliente, el cliente debe tener instalado el .Net Framework. Esto limita los entornos en los que la aplicación puede ser utilizada.
XBAP se encuentra limitado al ejecutarse en un Sandbox. Esto hace que haya que tener en cuenta estas restricciones de seguridad a la hora de plantear el desarrollo.

Referencias sobre el Template de Flexible Application:

La segunda opción sería realizar dos desarrollos paralelos: uno en WPF y otro en Silverlight. Para llevar esto acabo habría que realizar un desarrollo específico para cada tecnología. Probablemente las aplicaciones no serían iguales. Silverlight no es igual de potente que WPF, así que habría que tener en cuenta las limitaciones de esta.

El New York Times recientemente se ha encontrado con esta problemática. Se veían obligados a tener que mantener dos aplicaciones diferentes y que además realmente no ofrecían la misma funcionalidad a los diferentes usuarios. Un usuario de MAC, que sólo puede utilizar la aplicación Silverlight, no contaba con las mismas opciones que uno de Windows con la aplicación WPF. Por este motivo, el New York Times opto por Adobe Air. Abode Air si permite ejecutar sus aplicaciones tanto en entornos Windows como Web.

Así que la tercera, y última opción, es Silverlight 3. Silverlight 3 nace con la idea de competir con Adobe Air. Ya que esta nueva versión si permite que la aplicación viva “out of browser”.

Con Silverlight 3, una aplicación podrá ser ejecutada en un cliente Windows y en un cliente Web. Así que con un solo desarrollo la aplicación podrá correr bajo ambos entornos. Además la aplicación será multiplataforma ya que Silverlight si puede ser utilizado en MAC, por ejemplo. Al ser la misma aplicación también contara con la misma funcionalidad para todos los usuarios de los diferentes entornos.

El único problema que presenta esta solución es que es necesario conocer las limitaciones de la tecnología. Silverlight 3 todavía no es WPF, aunque empieza a estar cerca. Además hay que tener en cuenta que se ejecuta dentro de un Sandbox de seguridad. Cosa que limitará la funcionalidad de la misma.

WPF Blogger

Pedroafa — Sat, 20 Jun 2009 09:54:00 GMT

WPF Blogger es una comunidad de desarrolladores que se dedican a escribir sobre temas relacionados con WPF y Silverlight. No es una comunidad solamente española, sino que también cuentan con un grupo inglés, francés y alemán. Así que recientemente he unido mi blog (sectorsieteg.net) a dicha comunidad.

Aquí os dejo el feed en español, por si alguno os interesa agregarlo al lector de rss. Feed WPF Bloggers Español.

Crear una Regla para el Analizador de Código de Visual Studio 2008

Pedroafa — Sun, 08 Feb 2009 16:22:00 GMT

El analizador de código del Visual Studio 2008 es una herramienta que permite comprobar si el código cumple una serie de reglas. Funciona exactamente igual que FxCop, sólo que se encuentra integrado dentro del propio IDE.

El propio Visual Studio ya cuenta con un gran número de reglas predefinidas. Aunque este número puede ser aumentado por medio de la creación de nuevas reglas. Esto puede ser muy útil para equipos de trabajo que utilicen una guía de estilos específica. De esta forma, se puede comprobar que todos los miembros del equipo cumplen con los estándares fijados.

Creando una Regla

Cómo ejemplo vamos a definir una regla que permita comprobar los nombres de las pruebas unitarias. Según esta regla, el nombre de un test debe de tener este formato: NombreDelMetodoAProbar_DescripcionDeLaPruebas_ResultadoEsperado. Ej: GetCustomersById_NullParameter_ArgumentException.

Para ello habrá que crear un proyecto de tipo librería. Este proyecto debe de tener una referencia a estas tres dlls: FxCopSdk.dll, FxCopCommon.dll, Microsoft.Cci.dll. Estas dlls se pueden encontrar en la carpeta: %ProgramFiles%\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\.

Para que el analizador de código pueda determinar que clases son reglas. Las clases deben de heredar de la clase abstracta BaseIntrospectionRule. Esta clase se encuentra dentro del namespace Microsoft.FxCop.Sdk.

public abstract class BaseRule : BaseIntrospectionRule
{
    protected BaseRule(string name)
        : base(name, "Sector7G.VisualStudio.CodeAnalysisRules.Rules", 
        typeof(BaseRule).Assembly)
    {
    }

    public override TargetVisibilities TargetVisibility
    {
        get
        {
            return TargetVisibilities.All;
        }
    }
}

Nota: En este caso he creado una clase base de la cual heredarán todas mis reglas.

Al constructor de la clase BaseIntrospectionRule hay que pasarle como argumentos: El nombre de la regla, el namespace del archivo xml con la definición de la regla, y el ensamblado que tiene la regla.

Para crear la regla hay que sobre escribir el método Check de la clase BaseIntrospectionRule. Dentro de este método deberemos escribir el código de verifique si el nombre de un test es correcto.

public sealed class TestMethodsNamesMustHaveThreePartsRule : BaseRule
{
    public TestMethodsNamesMustHaveThreePartsRule()
        : base("TestMethodsNamesMustHaveThreePartsRule")
    {
    }

    public override ProblemCollection Check(Member member)
    {
        if (member == null || member.NodeType != NodeType.Method)
            return Problems;

        if (member.HasAttribute("TestMethodAttribute"))
        {
            if (!member.Name.Name.IsCorrectTestMethodName())
            {
                Problems.Add(new Problem(GetResolution(member.Name.Name)));
                return Problems;
            }
        }

        return Problems;
    }
}

En este código se puede ver como se comprueba que método este decorado con el atributo TestMethodAttribute. De esta forma podemos identificar si el método se trata de una prueba. Seguidamente se comprueba si el nombre cumple con la especificación establecida.

El código del método HasAttribute es:

public static class RuleHelper
{
    public static bool HasAttribute(this Member member, string type)
    {
        var info = member.Attributes.Where(a => a.Type.Name.Name == type);
        return info != null && info.Count() != 0;
    }
}

El códigio de método IsCorrectTestMethodName es:

public static class NamingHelper
{
    public static bool IsCorrectTestMethodName(this string name)
    {
        if (String.IsNullOrEmpty(name))
            return false;

        string[] parts = name.Split(new[] { '_'});
        return parts.Length == 3;
    }
}

Ya sólo queda incluir un archivo xml con la información de la regla. Este archivo debe incluirse como recurso dentro de la dll, es decir, su propiedad Build Action debe de ser Embedded Resource. El nombre de este archivo debe de ser el mismo que declaro en el parámetro resourceName del constructor de la clase BaseIntrospectionRule. En el caso del ejemplo se llama Rules.xml y tiene el siguiente formato:

<?xml version="1.0" encoding="utf-8" ?>
<Rules FriendlyName="Sector7G Code Analysis Rules">
  <Rule TypeName="TestMethodsNamesMustHaveThreePartsRule" 
        Category="Sector7G.Naming" CheckId="S7G0001">
    <Name>The name of a test method must have three parts</Name>
    <Description>A test method name must have three parts.</Description>
    <Resolution>
      The name "'{0}'" does not have three parts. 
      The correct format of a test method name is: 
      name of the method to test, a description and an expected result. Sample: 
      GetCustomerById_NullParameter_ArgumentException
    </Resolution>
    <MessageLevel Certainty="95">Error</MessageLevel>
    <FixCategories>NonBreaking</FixCategories>
    <Owner>Pedro Alvarez Fernandez</Owner>
    <Email></Email>
    <Url>http://www.sectorsieteg.net</Url>
  </Rule>
</Rules>

Una vez terminado el desarrollo, la regla debe de ser desplegada para poder ser utilizada desde el Visual Studio. Para ello, la dll debe de ser copiada a la carpeta: C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules. En esta carpeta encontraras las dlls del resto de reglas que utiliza el Visual Studio.

Ribbon Control y Prims

Pedroafa — Sun, 08 Feb 2009 12:16:00 GMT

Prism o Composite for WPF se basa en la construcción de una aplicación modular. Esto quiere decir, que cada funcionalidad de la aplicación constará de su propio módulo. Así que por ejemplo, si queremos que nuestra aplicación tenga un lugar donde se puedan configurar diferentes valores de la misma, tendremos un módulo de “configuración de la aplicación”.

Lo que intenta este post es explicar cómo dar la posibilidad a cada módulo de la aplicación de cargar sus propias opciones en el menú. Cómo menú se utilizará un control Ribbon, así que cada módulo debe de ser capaz de añadir un RibbonTab cuando éste sea cargado. De esta manera, cada vez que se agregue más funcionalidad a la aplicación, más módulos, estos irán enriqueciendo las opciones del menú presentadas en el Ribbon.

La mejor aproximación para hacer esto, es utilizar un RegionAdapter. Los RegionAdapter permiten asociar una región con un control. De esta manera, cuando un RibbonTab sea añadido en una región específica, el RegionAdaptar añadirá este RibbonTab al Ribbon.

El primer paso es añadir el control Ribbon a la aplicación y asociarlo a una región. En este caso es asociado a la región “RibbonRegion”:

<r:Ribbon DockPanel.Dock="Top"  Title="Sector7G Sample App" 
          cal:RegionManager.RegionName="RibbonRegion" />

Nota: Aquí puedes obtener toda la información para obtener el control Ribbon.

El siguiente paso debe de ser crear el RegionAdapter. El RegionAdapter va a ser el que nos permita añadir el RibbonTab de un módulo, al Ribbon de la aplicación.

public class RibbonControlRegionAdapter : RegionAdapterBase<Ribbon>
{
    private Ribbon _regionTarget;

    protected override void Adapt(IRegion region, Ribbon regionTarget)
    {
        _regionTarget = regionTarget;
        region.ActiveViews.CollectionChanged += OnActiveViewsChanged;
    }

    private void OnActiveViewsChanged(object sender, NotifyCollectionChangedEventArgs e)
    {
        switch (e.Action)
        {
            case NotifyCollectionChangedAction.Add:

                foreach (RibbonTab tab in e.NewItems)
                    _regionTarget.Tabs.Add(tab);
                break;

            case NotifyCollectionChangedAction.Remove:

                foreach (RibbonTab v in e.NewItems)
                    _regionTarget.Tabs.Remove(v);
                break;
        }
    }

    protected override IRegion CreateRegion()
    {
        return new AllActiveRegion();
    }
}

Nota: Aquí puedes encontrar un How To que explica cómo crear un RegionAdapter.

Para finalizar con la parte del Shell, ya sólo queda registrar el nuevo RegionAdapter dentro del Bootstrapper. Para ello, hay que sobre escribir el método ConfigureRegionAdapterMappings. Ello permitirá que al cargar un módulo, el RegionAdapter se ejecute.

protected override RegionAdapterMappings ConfigureRegionAdapterMappings()
{
    RegionAdapterMappings mappings = base.ConfigureRegionAdapterMappings();
    mappings.RegisterMapping(typeof(Ribbon), new RibbonControlRegionAdapter());
    return mappings;
}

Una vez llegado a este punto, es necesario crear un módulo. En este caso concreto el módulo de configuración. En este módulo se puede crear una clase que sirva de ayuda para crear el RibbonTab.

public class ToolBarPresenter : IToolBarPresenter
{
    #region IToolBar Members

    public RibbonTab CreateModuleToolBar()
    {
        var tab = new RibbonTab();
        var group = new RibbonGroup();
        var btn = new RibbonButton();

        tab.Label = "Configuration";
        
        var cmd = new RibbonCommand { LabelTitle = "Configuration" };
        cmd.Executed += new ExecutedRoutedEventHandler(cmd_Executed);
        cmd.CanExecute += new CanExecuteRoutedEventHandler(cmd_CanExecute);

        btn.Command = cmd;
        group.Controls.Add(btn);            
        tab.Groups.Add(group);
      
        return tab;
    }

    private void cmd_CanExecute(object sender, CanExecuteRoutedEventArgs e)
    {
        e.CanExecute = true;
    }

    private void cmd_Executed(object sender, ExecutedRoutedEventArgs e)
    {
        //Do something
    }

    #endregion
}

Una vez creado el RibbonTab simplemente hay que asociarlo a la región específica para el RegionAdapter actué al cargar el módulo en la aplicación.

IRegion ribbom = _regionManager.Regions[RegionNames.RibbonRegion];
var toolbar = _container.Resolve<IToolBarPresenter>();

RibbonTab tab = toolbar.CreateModuleToolBar();
ribbom.Add(tab);
ribbom.Activate(tab);

Probando tipos internos

Pedroafa — Wed, 04 Feb 2009 21:53:00 GMT

Internal es un operador utilizado para modificar la visibilidad de una tipo en .Net. El operador indica que tipo al que es aplicado sólo será visible dentro de ese ensamblado, es decir, dentro de ese proyecto.

El uso de este modificador puede suponer un problema a la hora de realizar un test. Ya que su utilización impide que desde el proyecto pueda ser visto el tipo.

Para permitir que el tipo pueda ser utilizado desde un test, y por lo tanto, poder probar toda la funcionalidad del tipo. El ensamblado del test debe de ser declarado como “amigo”. Para conseguir esto, se debe decorar la dll a probar con el atributo InternalsVisibleToAttribute. Este atributo especifica que los tipos solamente son visibles dentro del propio ensamblado y visibles desde el ensamblado marcado en el atributo.

Así que para probar los tipos Internals de mi ensamblado (Sector7G.Invertis.YahooService), deberé indicar que mi proyecto de test (Sector7G.Invertis.YahooService.Test) tiene acceso a estos tipos. Para ello, dentro del archivo AssemblyInfo.cs del ensamblado Sector7G.Invertis.YahooService añado la siguiente línea:

[assembly: InternalsVisibleTo("Sector7G.Invertis.YahooService.Test")]

Con esta decoración ya es posible probar, desde el proyecto de test, todos los tipos como si fueran públicos.

[Code-Snipped] Leer Un Tipo Enumerado De Un Xml Con LinQ To Xml

Pedroafa — Tue, 03 Feb 2009 21:49:00 GMT

El objetivo es cargar la entidad StockQuotes con los datos contenidos en el xml StockQuotes.xml. Para ello debemos de tener en cuenta que el tipo StockStates se trata de un enumerado.

<?xml version="1.0" encoding="utf-8"?>
<StockQuotes>
  <StockQuote>
    <Name>Santander</Name>
    <State>Green</State>
  </StockQuote>
  <StockQuote>
    <Name>Banesto</Name>
    <State>Red</State>
  </StockQuote>
</StockQuotes>

public class StockQuote
{
 public string Name {get; set;}
 public StockStates State {get; set;}
}

Leer el xml usando Linq To Xml resulta muy sencillo.

XDocument xml = XDocument.Load(@"C:\StockQuotes.xml");
var data = from s in xml.Descendants("StockQuote")
           select new StockQuote {
               Name = s.Element("Name").Value,
               State = s.Element("State").ParseToEnum<StockStates>()
           };

La gracia de este código reside en el método extendido ParseToEnum. Se trata de un método que permite convertir un elemento XElement en un enumerado.

public static class EnumExt
{
    public static T ParseToEnum<T>(this XElement node)
    {
        if (node == null)
            return default(T);

        try
        {
            return (T)Enum.Parse(typeof(T), node.Value);
        }
        catch(Exception)
        {
            return default(T);
        }
    }
}

Un ejemplo de la potencia del lenguaje combinando Genéricos con métodos extendidos.

El Nombre 'InitializeComponent' No Existe En El Contexto Actual

Pedroafa — Tue, 03 Feb 2009 21:43:00 GMT

Estábamos copiando unos UserControls de un proyecto a otro para unificarlos en un solo proyecto y cuando quisimos compilar nos encontramos con este error.

The name 'InitializeComponent' does not exist in the current context

Este error puede producirse por tres causas diferentes:

Primera Causa

Que dentro del archivo xaml no esté correctamente referenciado el archivo de code-behind del UserControl. Ya que el namespace donde se encuentra la clase, debe de ser el mismo que el declarado en el atributo x:Class del archivo xaml.

<UserControl x:Class="Sector7G.Invertis.Wpf.Module.StatusBar.Views.StatusBarControl"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

namespace Sector7G.Invertis.Wpf.Module.StatusBar.Views
{
    public partial class StatusBarControl : UserControl, IStatusBarView
    {
        public IStatusBarPresenter Presenter { get; set; }

        public StatusBarControl()
        {
            InitializeComponent();
        }
    }
}

Segunda Causa

También puede deberse porque falten algunas declaraciones de las propiedades del proyecto. Suele ocurrir cuando se intenta añadir un UserControl de WPF a una Librería de clases en .NET 2.0. El error es debido a que el proyecto no sabe cómo debe compilar este tipo de controles. Ya que en .NET 2.0 ni existía el concepto WPF, así que hay que convertirlo en un proyecto de tipo WPF.

Para solucionarlo hay que editar el proyecto (el archivo .csproj). En el archivo encontraras una línea como la siguiente:

<Import Project=“$(MSBuildBinPath)\Microsoft.CSharp.targets” />

Debajo de esta línea copia esta otra. Esta segunda línea indica al proyecto que es de tipo WPF.

<Import Project=“$(MSBuildBinPath)\Microsoft.WinFX.targets” />

Tercera Causa

En nuestro caso habíamos copiado el UserControl de un proyecto a otro. Así que por alguna razón o fuerza entraña, el tipo de compilación (la propiedad Build Action) del archivo xaml se estableció a “CodeAnalysisDictionary” en vez de quedarse como “Page”. El build Action de un archivo xaml debe de ser Page.