1

Closed

DisplayRootViewFor not working in Version 1.4.1 on WinRT

description

Hi @all,

I'm implementing a WinRT using caliburn.mico. Installed Ver.1.4.1 via nuget and get a NullReferenceException in LocateForModelType. As far a I could figure out, it seems that PrepareViewFirst is not called during initialisation. When changing back to Ver. 1.4.0 ist works as expected. To illustrate this I attach a sample Project.

file attachments

Closed Jan 23 at 9:14 PM by NigelSampson
Not a bug, but a change in behaviour of WinRT container from 1.4 to 1.4.1 ...

comments

NigelSampson wrote Jan 23 at 8:14 AM

Previously WinRTContainer was instantiating unregistered objects if that object was concrete (not abstract or an interface). It appears that behavior has changed in 1.4.1.

If you register your view models in the Configure method with the container
container.PerRequest<MainPageViewModel>();
then it will work correctly.

tibel wrote Jan 23 at 7:43 PM

Maybe it would be best, if SimpleContainer.GetInstance() will throw an exception if no handler is registered. As it already throws an exception if more than one instance was found.

NigelSampson wrote Jan 23 at 9:14 PM

Potentially, though I'm loathe to change behaviour of the container now. You could add this yourself in the container override of GetInstance, if the container returns null throw an exception.

bigtlb wrote Feb 11 at 11:28 PM

Do you have a reference as to why concrete types are no longer created by GetInstance in version 1.4.1? I can see the code that was taken out between versions, but can't think of a reason why you would cripple an IoC like that.

I realize I could add the code back into my own application GetInstance override, but I might as well use Unity preview or make a custom build of Ninject. Which will remove my concerns about future SimpleContainer breakage.

NigelSampson wrote Feb 12 at 12:00 AM

Originally the container didn't self register concrete types, while doing the WinRT port early last year I added it to the container to simplify the large amount of testing that I was doing of the port. It wasn't my intention for it to be in the main trunk as this is large change in behaviour.

Mistakenly (I believe) it was merged into the main trunk from my fork, I'm not sure it was removed later on though.

Sign in to add a comment