Unity DI Container now supports Windows Phone

Upon numerous requests from Unity users, we have ported Unity DI Container to Windows Phone 8. The Unity NuGet package has been updated as follows:

  • The .NET version of Unity remains intact.
  • The NetCore version (for Windows Store apps) was recompiled, because there was a small change needed to have code parity with Windows Phone - we rebuilt it for the symbols to match the source code.
  • The WP8 version is new.


Happy coding!

- Grigori

Comments (9)
  1. jfc says:

    Really appreciate you guys getting this done.

  2. @jfc

    Glad you are finding this useful. Please keep engaging with my team (Microsoft patterns & practices) on other things you need help with.


  3. David Hayes says:

    Ahhh, might have to switch over from Castle Windsor. How is performance on WP8?

  4. David, hi

    We ran our perf tests and are pretty happy with the results.


  5. Damien says:

    cool, any code examples?

    greetings Damien

  6. Jono says:

    This is great. In general I tend to use the SimpleContainer in Caliburn Micro as I don't usually have a need for anything much more complex, however I do like Unity, so I may make the jump.

    What I would love to see is a Nuget package containing a PCL version. I'm still targetting WP7.5 for some customers and I would love to have a central container in a common bootstrapping assembly that I can use across all platforms.

  7. Now we have one part support from prism in windows phone,

    Question1 – Can we use the same for windows 8 store apps?

    Question2 – Can we have some performance results comparing with other containers like autofac, nijnect?

  8. @Kasi3

    1) Yes, you can now use both Unity and Prism for Windows 8 store apps – prismwindowsruntime.codeplex.com.

    2) We don't publish results of our tests. I can assure we do them as a part of our development & release lifecycle and our results gave us enough confidence to move on with a public release. When it comes to perf, my recommendation is always to do your own perf assessments since they very much depend on specific scenarios. Be watchful when reviewing other people's perf numbers – the empirical testing methodologies often suffer from validity threats. One common mistake, for example, is discarding and configuring a new container for every resolve operation.

Comments are closed.

Skip to main content