we have a WPF project, which uses third party librarys and a couple of internal packages. The wpf programm works fine on it's own, the assemblies get resolved correctly and the code works great.
The programm provides a possibilty to load data from different sources, depending on how you started it. As mentioned earlier, when called on it's own, it all works great, but if we call the programm from a different application, which is done by providing a controller and registering it as COM interop, we run into assembly reference issues.
[Guid("93BC7929-8A5F-43EA-AEAB-38B5034758E5")]
[ComVisible(true)]
public class ConnectionController : ControllerBase
{
public override void Run()
{
var viewModel = new MainWindowViewModel();
var view = new MainWindow {DataContext = viewModel};
view.Show();
}
}
Because the wpf programm is also provided as a standalone application, we moved the controller to a different project which does not reference a lot of the assemblys, for example somekind of wpf library.
The controller himself does not hold anymore logic, usually it passes somekind of data which is provided by the com object, but all in all, the only thing it does is trying to instantiate the MainWindowViewModel in a different project. The projects which are in the same solution as the controller are resolved correctly, but the third party stuff is not.
As soon as we call the wpf programm by the controller, the project, which references the third party librarys, cannot resolve it's references anymore and throws an exception.
What is the correct way to solve this kind of issue? Do we have to register the third party dlls in the GAC? Or is their somekind of property we have to adjust? We can't get our heads around it. Every information about references and how they are resolved is appreciated.
Thanks to @Hans Passant, we found a solution for our problem. For the first try, we just copied the needed dlls into the folder of the executing assembly and it worked like a charm. This won't be the final solution, most likely we will use codebase, but it would also be possible to use the god class, because the controller will always be created first. I think we'll try to keep the controller as small as possible and are going to let the application handle how it gets it's ressources.