The Application.LoadComponent(component, uri) is no longer working if the component and the resource pointed by the uri live in different assemblies.

Unfortunately this change makes it impossible to have components from one assembly to inherit from components from another assembly.

Say you have a custom MyWindow control that lives in a Common.dll assembly. Its generated InitializeComponent() code contains a call to Application.LoadComponent(this, new Uri("/Common;component/mywindow.xaml"). So far so good. Now in the Application.dll assembly you have another class AppWindow that extends MyWindow. When it loads it calls MyWindow constructor which in turn calls MyWindow InitializeComponent. The result is a System.Exception : The component 'AppWindow' does not have a resource identified by the URI '/Common;component/mywindow.xaml'.

Looking at the Reflector output for the Application.LoadComponent(component, uri) method it is easy to notice the following code at the end (which wasn't there in June CTP)

IStreamInfo info2 = stream1 as IStreamInfo;
if ((info2 == null) || (info2.Assembly != component.GetType().Assembly))
{
throw new Exception(SR.Get(SRID.UriNotMatchWithRootType, new object[] { component.GetType(), resourceLocator }));
}

I guess there was a valid reason to add this code, it just seems that the limitation imposed is a little bit too extreme. Please let me know if there are any workarounds for this problem.

Thanks,

Dmitry.

Does anyone know a better place to ask this question? Is there a way to open a bug report ?

Thanks,

Dmitry.

I resolved the bug on Connect with this note:

At this stage, we aren't doing any more feature work for this version and are only taking the highest value (and low risk) fixes. In short, we're close to being done. We have this item on our radar for the next version.

I encounter the same problem, too.

The procedure for working of me is presented.

1. The project that makes MyDll.Dll is made, and MyControl is added as UserControl.
2. The project that makes MyExe.exe is made, and MyDll.Dll is added to the reference.
3. MyControl is made in MyExe, and it derives and MyControlEx is made.
4. MyControlEx is used with Window1 of MyExe.
5. The exception is generated if it executes it.

If not MyControlEx but MyControl is used, the exception is not generated.

Please teach the evasion method to this problem.

MyDll : MyControl.xaml
<UserControl x:Class="MyDll.UserControl1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid/>
</UserControl>

MyDll : MyControl.cs
public partial class MyControl : UserControl
{
public MyControl()
{
InitializeComponent();
}
}

MyExe : MyControlEx.cs
public class MyControlEx : MyControl
{
}

MyExe : Window1.xaml
<Window x:Class="MyExe.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:MyExe"
xmlns:mydll="clr-namespace:MyDll;assembly=MyDll"
Title="MyExe" Height="300" Width="300">
<Grid>
<local:MyControlEx/>
<!--<mydll:MyControl/> -->
</Grid>
</Window>

You can extend controls as long as you aren't extending from markup subclassed classes. There's that difference.

The team realizes this is must be fixed. But they are being disciplined about not introducing churn at this stage or destabilize the platform when it is stable and ready to ship. We owe that to the community as well.

There are 3 primary types of subclassing of Controls or Windows done.

1) Have a Window or Page at the root of a XAML page, building Window1, Page1, etc...
2) Building a user control - usually done with a UserControl at the root of a xaml page.
3) Building a subclass of a control - using a programming language.  This is the ideal way to build a reusable control ... it allows you to specify a default look and feel in a xaml file (look up generic.xaml), but that can be overridden by users or subclassers.

I believe the scenario you mention -

"a third party using markup develops a control by inheriting from a built-in control such as ListView"

 - would be best handled by #3.

In VS, use the following Item templates for those scenarios:

1) WPF Page or Window
2) WPF UserControl
3) WPF CustomControl

Hope that works for you.  If not, please give me the specific scenario where it falls down with code/markup examples and we'll examine the scenario.

Thanks, Rob Relyea
Program Manager, WPF Team

Hi Rob,

This issue occurrs when inheriting again from an inherited control that uses markup.

Here are the repro steps:

1) A custom control called "MyFirstControl " is created using the "WPF CustomControl" template.

2) Then another project is created using exactly the same template. In this project there's a new control that inherit from MyFirstControl. This new control is called MySecondControl.

3) Then an application project is created that will try to instantiate each type of control.

4) Result: MyFirstControl can be instantiated but MySecondControl generates an exception.

I am sending the whole solution to you by e-mail, since I can't find a way to attach a file in this forum.

Regards,

-Makutaku

I am one person who wants you to return the specification.
It is a very important matter in the project thought that it will make
the library.

How did the answer to Mr. Makutaku's story become it?