locked
Windows Runtime Component with XAML resources incorrectly built.

    General discussion

  • 1) Create a (C++/CX) "Windows Runtime Component" (let's say "MyComponent") add a namespace call it "XamlStuff" with a "UserControl";

    2) Create a (C++/CX) "Blank App (XAML)" Windows Store app and add the "UserControl" to your "MainPage";

    3) Build it.  And surprise, it doesn't.

    The result is that (for some reason) it creates a directory for you XAML called "../Debug/XamlStuff/zzz" in where you will find your XAML stuff.  Still while building it will try to find the needed XAML (zzz) IN "../Debug/MyComponent/XamlStuff/...".

    What should I do?

    1) Just create a directory "../Debug/MyComponent";

    2) copy the "zzz" into this new folder;

    3) Build it.  It just works!

    I couldn't find a way to influence the compile/build process to place the XAML resources where it is expecting to find those. 

    It is OK to do it by hand and once or twice, but every time I do an update, it is annoying.  Please fix this thing, else tell me how I influence the compiler/linker/builder to do right thing! (hopefully it will be an easy task...)

    Ed.

    Thursday, March 14, 2013 9:53 AM

All replies

  • Did you set a reference to your WRC library MyComponent?   Below I followed your steps minus the copying steps (1-3). 

    source:  http://www.global-webnet.com/files/MyComponent.zip for your reference.


    MCAD.NET C# - http://www.Global-webnet.com/Blog


    • Edited by BillKrat1 Thursday, March 14, 2013 4:33 PM clarity
    Thursday, March 14, 2013 4:31 PM
  • Thanks for you reply!

    I over simplify the real scenario and didn't test the simplify case I presented.  In this mickey mouse sample following my instructions all works fine, still as soon as you build-up a library it is not that simple.  The issue that I do have is that I don't use the default output projects folders where all (for small solutions) or a couple of components things work great, instead I use a common output assemblies repository that don't require the use of separate debug / release directories per project and there is where the build gets bad.

    Anyways, thanks for the reply and the time to put the sample together.

    Ed.

    Thursday, March 14, 2013 10:22 PM