Reputation: 2813
I have compiled a project (custom WPF control) into dll and attached that dll as a reference into my main project, planning to use that custom control there.
The dll project itself has referenced other dll's, like System.Reactive.Linq and many others. I see no missing references there. The main project is not referencing to all of those dll's directly.
When I try to use the custom control in the main project XAML, it complains that the assembly could not be loaded:
<myControls:MyCustomControl> />
I thought that after compiling the custom control project into dll, I don't need to care anymore in my main project what references it uses. Is that right? Or do I have to have in this case the System.Reactive.Linq referenced also in the main project?
Upvotes: 2
Views: 1344
Reputation:
Let me try to put this all together. First of all, this problem has nothing to do with WPF, it's a more general thing. In my opinion we should talk about resolving both run-time & compile-time dependencies.
In case of run-time dependencies all required assemblies are located based on the Standard Search Order for Desktop Applications. If the search is unsuccessful you get an exception like above.
As for compile-time dependencies there are situations when it's not obvious at all why the compiler returns an error. Consider the following example with 2 projects:
Project #1: a Class library with a custom WPF UserControl -->
public partial class UserControl10 : UserControl, IClientChannel
{
//System.ServiceModel.IClientChannel from System.ServiceModel.dll
//basic implementation of IClientChannel comes here
}
The .xaml part is not relevant. A reference to System.ServiceModel.dll is added to this project.
Project #2: a WPF application with referencing Project #1 -->
<Window x:Class="WpfApplication1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:class1="clr-namespace:ClassLibrary1;assembly=ClassLibrary1"
Title="MainWindow" Height="350" Width="525">
<Grid>
<class1:UserControl10 x:Name="t"/>
</Grid>
</Window>
Try to build it, and guess what: you get a compile-time error stating that you need to add a reference to System.ServiceMode.dll. Removing x:Name="t" eliminates the problem. Why? Because of the automatically created *.g.[i.]cs files. Inside them you'll find internal data member definitions with type UserControl10. However, this type has a dependency of IClientChannel which resides in System.ServiceModel.dll.
The same error would blow in your face if your tried to use type UserControl10 anywhere in code-behind in project #2.
Hope I could help.
Upvotes: 0
Reputation: 1165
If an assembly has a dependency on external assemblies, you will absolutely need to include the external assemblies.
Think about it... Say that you have a Logging assembly that leverages Log4Net. If you use the Logging assembly, shouldn't you also need the Log4Net assembly? If you don't, then it is missing a requirement.
The best way to look for "dependent" assemblies is to check the bin folder of where they're built. For example of what I listed above, the Logging assembly SHOULD have a Log4Net assembly copied to its bin, in most cases. Anything that is in the GAC, though will not be copied (which can be a good or bad thing), unless marked to do such, per my knowledge.
Another way to think of it is... Say you need a translator (assembly) -- your primary language is English (also an assembly requirement). You need someone who can speak Russian (again, an assembly). The translator has to have that requirement of Russian, or how else do they speak Russian? So they have a dependency on Russian, much in the same way they YOU have a dependency on someone who can SPEAK Russian. Maybe not the best example, but hopefully it makes enough sense.
Upvotes: 1