Naming Convention only works in single project (views in same project as viewmodels)

[savaged]

Rather than having to create my own custom Dialog Locator, it would be good to have the NamingConventionDialogTypeLocator find a separate views project in referenced assemblies.

Suggested additions to NamingConventionDialogTypeLocator.cs:

1. In Locate below string dialogName = GetDialogName(viewModelType);

Add...

dialogType = GetAssemblyFromType(viewModelType).GetType(dialogName) ?? GetReferencedAssembly().GetType(dialogName);

2. Add the method:

        private static Assembly GetReferencedAssembly()
        {

            Assembly assembly = null;

            foreach (var a in AppDomain.CurrentDomain.GetAssemblies())
            {

                if (a.FullName.Contains("Views"))
                {
                    assembly = a;
                }

            }
            return assembly;
        }

[FantasticFiasco]

For some projects this would be a fantastic idea, for other projects it would be a waste of CPU cycles. That's why the default implementation often fit when you need it the most, i.e. when you are new to WPF and copy/paste the project structure from sample applications.

Is the default implementation covering all project structures? Certainly not! But the idea is that when you've grown into setting your own structure, you also know enough to write your own locator. And if you don't have any clue where to start there is even a tutorial in the wiki.

I know this probably isn't the answer you are hoping for, but the default implementation is probably good enough, and replacing or bundling more than one implementation will probably confuse more than it helps.

But never the less, thank you for your input, it helps me understand the developers using the framework.

[Hylndr]

Hey savaged,
I think I'm in the same situation with a solution with the Views and the ViewModels in seperate projects within the same solution. Would you code changes work for that? Here is a puesdo diagram of our solution:

MyApplication
├── Company.Views
│ ├── MyApplication
│ │ ├── MainWindowView.xaml
│ │ ├── MainWindowView.cs
│ │ ├── ApprovedProgramsView.xaml
│ │ ├── ApprovedProgramsView.cs
│ │ ├── AdminConfigSettingsView.xaml
│ │ ├── AdminConfigSettingsView.cs
│ │ ├── CSVGenerationView.xaml
│ │ ├── CSVGenerationView.cs
│ │ ├── MyDialogView.xaml
│ │ └── MyDialogView.cs
│ ├── AnotherApplication
│ │ ├── AAMainWindowView.xaml
│ │ └── AAMainWindowView.cs
│ └── AndOneMoreApplication
│ ├── AOMAMainWindowView.xaml
│ └── AOMAMainWindowView.cs
├── Company.ViewModels
│ ├── MyApplication
│ │ ├── MainWindowViewModel.cs
│ │ ├── ApprovedProgramsViewModel.cs
│ │ ├── AdminConfigSettingsViewModel.cs
│ │ ├── CSVGenerationViewModel.cs
│ │ └── MyDialogViewModel.cs
│ ├── AnotherApplication
│ │ └── AAMainWindowViewModel.cs
│ └── AnotherApplication
│ └── AOMAMainWindowViewModel.cs
└── App.xaml

And what about using datatemplates to find the view for a particular ViewModel... We're using that in our apps:
`

<DataTemplate DataType="{x:Type vmMyApp:ApprovedProgramsViewModel}">
     <vMyApp:ApprovedProgramsView />
</DataTemplate>
<DataTemplate DataType="{x:Type vmMyApp:AdminConfigSettingsViewModel}">
    <vMyApp:AdminConfigSettingsView />
</DataTemplate>
<DataTemplate DataType="{x:Type vmMyApp:CSVGenerationViewModel}">
    <vMyApp:CSVGenerationView />
</DataTemplate>`

[Hylndr]

Well the indentation didn't come out exactly, but I think you'll get the idea... :-)

[savaged]

Impressive ASCII ;)
The xaml solution looks good too.
I've had my mvvmdialogs fork working for some weeks now so you could say it's a working version.
It was just a few lines of code changed from FantasicFiasco's original.

[FantasticFiasco]

What do you think about creating a MvvmDialogs.Contrib repository that would contain functionality not fitting the main repository, but still hold value for some developers?

[savaged]

Much better than my fork ;)

[FantasticFiasco]

@savaged I've created a repo here and you've been invited as a collaborator.

I'll make sure you have the correct permissions to the repository. I've also setup AppVeyor to push NuGet packages on git tags, i.e. if you create a GitHub release, AppVeyor will build the code and publish the package to nuget.org.

Treat the repository as your own, I am not sure how much time I will be able to invest in it.

[savaged]

Thanks, I think ;)

Please can you add [assembly: InternalsVisibleTo("MvvmDialogs.Contrib")] to MvvmDialogs?

[FantasticFiasco]

lol, yea, you just got hired, eventually it will dawn on you :-D

I'll publish a new version either today or tomorrow the latest

[FantasticFiasco]

A new version has been published

[FantasticFiasco]

I'm closing this issue.

I have no idea of the progress, but any further conversation can take place on MvvmDialogs.Contrib.