locked
Bug accessing XAML-based control from a class library

    Question

  • We are working on starting to develop UI control products for WinRT and have run into an issue we could use some help with.  Our setup for this issue is like this:

    A Class Library project that has a new UserControl in it, via UserControl1.xaml/.cs.

    An application project with a XAML file where we try to include the UserControl1 in.  At the top of this XAML file I have an xmlns defined like:

    xmlns:productsShared="using:ActiproSoftware.Products.Shared"

    And the code to include the control in the XAML is:

    <productsShared:UserControl1 />

    When I compile this, I get an error like this:

    "Error 1 Payload file 'S:\....\bin\Debug\MyWinRTClassLib\Products\Shared\UserControl1.xaml' does not exist. SampleApplication-CSharp.VS11"

    After some more playing around with things, we found something interesting.  Originally when we got this error, we had our app project reference the class library via a .dll reference to its bin/Debug folder.  As a test, we tried changing the reference to a project reference instead and everything started working right.

    Thus, it seems like this is likely a bug with how references work because in WPF/Silverlight we can reference .dlls that contain XAML file and they don't behave any differently from project references.

    Since we are component developers, we absolutely need the ability to distribute our products as a single .dll file for each product.  We need our customers to be able to reference our .dll files and have everything work without any external files needed, just like in all the other MS platforms (WPF, Silverlight, WinForms).

    We'd appreciate any explanation for what is going on in the above scenario and how to work around it.  I should note that we are making normal class libraries that will only be consumable in C#/VB here.  Thanks!


    actiprosoftware.com - Professional WPF, Silverlight, and WinForms UI controls and components

    Monday, March 12, 2012 3:36 PM

Answers

  • Bill and I have taken this offline - I am able to successfully compile using the technique Navit desacribed.  However we are talking off-line about the distribution model.  I am going to mark this as resolved since we've resolved the compilation issue.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator

    Tuesday, March 13, 2012 7:51 PM
    Moderator

All replies

  • Hi Bill - I am able to reproduce this and am researching it.  I will update you when I know more.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator

    Monday, March 12, 2012 5:03 PM
    Moderator
  • Thanks Matt, I'd also like to mention that VS seems to be copying our .xaml file to our bin folder, even though we have Do Not Copy set on the file properties. 

    In addition, it copies the .xaml file to the "bin\Debug\Products\Shared" folder instead of the "bin\Debug\MyWinRTClassLib\Products\Shared" folder that VS is apparently looking in.

    Regardless though, we definitely don't want to have to redistribute .xaml files separately from the .dll file.


    actiprosoftware.com - Professional WPF, Silverlight, and WinForms UI controls and components

    Monday, March 12, 2012 5:10 PM
  • Hey Bill,

    There are multiple issues here:

    1. Not respecting the "Copy to Output Directory" property is a known issue and we will be fixing it in next public release of Visual Studio.

    2. The issue you are running into with dll reference is because the resources (like XAML files) are not correctly laid-out in bin\output directory. In WinRT environment, the resources are no longer embedded in the assembly but are placed next to the dll as content.

    Example:

    If you have a class library (CL1) with a XAML file (UserControl1.xaml), after build the output layout should be:

    bin\Debug

      CL1.dll

      CL1.pri

      \CL1 [folder]

           UserControl1.xaml

    If you create this layout in bin\Debug, the dll reference should work. Also, is there any specific reason you want to do dll reference instead of P2P reference? I would also like to understand how your dlls are shipped to end users? You can contact me at navits at microsoft dot com and we can follow-up.

    -Navit Saxena

    Monday, March 12, 2012 6:33 PM
  • Navit - I changed my test app but it's not working for me.  Ping me directly if you like so we can discuss:  msmall


    Matt Small - Microsoft Escalation Engineer - Forum Moderator

    Monday, March 12, 2012 6:46 PM
    Moderator
  • I worked with Navit on this - you have to remove the UserControl1.xaml file from the debug folder, then it compiles fine.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator

    Monday, March 12, 2012 8:27 PM
    Moderator
  • Bill and I have taken this offline - I am able to successfully compile using the technique Navit desacribed.  However we are talking off-line about the distribution model.  I am going to mark this as resolved since we've resolved the compilation issue.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator

    Tuesday, March 13, 2012 7:51 PM
    Moderator
  • Matt,

    I am facing the similar issue and want to discuss about the distribution model. Please check my thread here. For Silverlight and WPF users I ship only the dlls with no external dependency. For Metro users, do I have to ship external files (Generic.xaml) also along with the dll?

    Monday, April 16, 2012 8:00 AM
  • Yes, you have to include the XAML files with the dll.  There will be no changes to this model between now and RTM.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator

    Monday, April 16, 2012 1:50 PM
    Moderator
  • Matt,

    Is there any way I can embed Generic.xaml file inside the dll itself?

    Tuesday, April 17, 2012 4:57 AM
  • No, that is not an option in Metro.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator

    Tuesday, April 17, 2012 1:16 PM
    Moderator
  • Matt, I know we talked offline on this last month and I saw recently that you posted in another thread that it wasn't going to be added.  This is very disappointing.  Can you provide some insight either here or offline again as to why not?  C# and VB developers expect to be able to deliver resources embedded in their .dlls.

    Having to redistribute all these loose files in addition to a .dll for each of our products is going to be a bit of a nightmare both for component developers like ourselves and for our customers (developers of Metro apps) that use our products.  Not only that, but it also forces us to fully expose a lot of code that normally would be proprietary and that we might not want competitors to see.


    actiprosoftware.com - Professional WPF, Silverlight, and WinForms UI controls and components

    Tuesday, April 17, 2012 1:21 PM
  • Bill - I've replied to you offline.  I'm going to lock this thread - all of the answers have been given, and I can't change the way it is.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator

    Tuesday, April 17, 2012 1:27 PM
    Moderator