Avoiding Locator Bloat - mvvm-light

Question

Just starting a new project with MVVM light after a few years hiatus. I am wiring up my first VM using the ViewModelLocator and I see that for each new view model we need to create a new property. I am just wondering how to avoid this as the app may end up having quite a few view models (50+). I have gotten it to work using a value converter but then I loose intellisence in the XAML editor.
Any examples from those who may have a solution to this is appreciated.
Note - here is a solution using a value converter, so I can then just pass the parameter into some IoC and get the VM, but then I loose intellisense (WelcomeTitle gets the squiggle).
<Window x:Class="My.MainWindow"
DataContext="{Binding Source={StaticResource Locator},
Converter={StaticResource Locator}, ConverterParameter='foo'}">
<Window.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="Skins/MainSkin.xaml" />
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Window.Resources>
<Grid x:Name="LayoutRoot">
<TextBlock FontSize="36"
FontWeight="Bold"
Foreground="Purple"
Text="{Binding WelcomeTitle}"
VerticalAlignment="Center"
HorizontalAlignment="Center"
TextWrapping="Wrap" />
</Grid>
</Window>
Update:
Here is another approach, better than using a converter, but still suffers from WelcomeTitle squiggle because the XAML editor does not know the type. I wonder if this effects "blendability"? (I do not have blend handy.)
http://maartendewilde.blogspot.com/2011/01/auto-viewmodel-binding-with-ninject.html
Thanks

Answer 1

For the intellisense, you can try yet more boilerplate on the resources?
/// <summary>
/// Class to contain things
/// </summary>
/// <typeparam name="T">UserID</typeparam>
/// <typeparam name="TK">UserName</typeparam>
public class MyDictionary<T,TK> : Dictionary<T,TK>
or what about using a shared resource dictionary to make intellisense happy?
Dependency injection is a good way to reduce redundant locator code. It involves a generic way of registering service or model providers. From the MSDN.
If you have to create a new property for each view model, it may indicate a weakness in your actual model. When working with VMs I usually find that they are reductive, in that the model contains all pertinent data, and view models get constructed as a subset of properties important to that view.
It is not uncommon for a large project to have 50+ view models.