通过

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.

unity

Happy coding!

- Grigori

Comments

  • Anonymous
    August 29, 2013
    Really appreciate you guys getting this done.

  • Anonymous
    August 29, 2013
    The comment has been removed

  • Anonymous
    August 30, 2013
    Ahhh, might have to switch over from Castle Windsor. How is performance on WP8?

  • Anonymous
    August 30, 2013
    David, hi We ran our perf tests and are pretty happy with the results. Grigori

  • Anonymous
    September 05, 2013
    cool, any code examples? greetings Damien

  • Anonymous
    September 18, 2013
    @Damien, See the new Dev Guide (www.microsoft.com/.../details.aspx) and a set of Hands-on Labs (www.microsoft.com/.../details.aspx).

  • Anonymous
    September 23, 2013
    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.

  • Anonymous
    September 27, 2013
    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?

  • Anonymous
    September 27, 2013
    @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.