Nuget package with WP7.1 Mango SDK support

Jan 4, 2012 at 10:29 PM

Any chance of this any time soon? I'm assuming there's nothing in there that's not compatible, it's just a matter of updating a manifest of some type?

Coordinator
Jan 5, 2012 at 6:27 AM

Hi Mark,

I've got no Windows Phone experience what so ever. What flavor of .NET runs on WP7? Is that CF?

Jan 5, 2012 at 8:03 AM

It is Silverlight 4. The existing assemblies work fine, as far as I can tell, it's just the Nuget package doesn't specify windows phone as a valid target.

http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package has info on the required SL4/Windows Phone target. There are two, one for windows phone 7.0 and one for 7.1 (mango) The targets are sl3-wp and sl4-windowsphone71.

If you want to test this yourself, you can download the windows phone SDK, which is free, and run up a simple app in the emulator.

Coordinator
Jan 5, 2012 at 5:19 PM
Edited Aug 6, 2012 at 1:59 PM

Simple Injector will currently not run on WP7. Simple Injector relies heavily on expression tree compilation, which is not supported in Silverlight for Windows Phone.

I will do some research to find out how to get Simple Injector to run on this constraint platform, but don't expect anything soon.

Coordinator
Jan 15, 2012 at 2:03 PM

After doing some research, I decided not to support .NET Compact Framework and Silverlight for Windows Phone.

The reason Simple Injector is so fast is because it uses Reflection.Emit under the covers (through expression tree compilation). Since CF and WP don't support Reflection.Emit, building a version for those platforms would mean that the framework should use reflection, and it would perform much slower than what users can expect from the .NET and Silverlight versions. This would surprise developers, which is a bad thing.

Because of this I decided it is better to not support those frameworks. I will probably reconsider when newer versions of CF and WP do support Expression trees compilation and Reflection.Emit.

Jan 15, 2012 at 2:14 PM

Fair enough - thanks for looking into it for me.

Jan 30, 2013 at 1:16 PM

What would the performance impact be with not using Reflection.Emit? How hard would it be to have a #define#undefine for replacing reflection.emit to increase the number of supported platforms?

Coordinator
Jan 30, 2013 at 3:06 PM

It's much more than a few simple #define statements. Not only is Simple Injector internally based on building Expression trees, the API itself is Expression based. For instance, the InstanceProducer class has a BuildExpression method, both ExpressionBuiltEventArgs and UnregisteredTypeEventArgs have an Expression property to fiddle with the creation of types and the IConstructorInjectionBehavior contains a BuildParameterExpression that returns an expression. And to make things worse, v2 will add an ExpressionBuildingEventArgs.Expression and Registration.BuildExpression.

While most of the features can be implemented without using Expressions, it will be much harder to do so. Besides this, removing Expression trees will disallow certain extensibility points. For instance, the Expression based API allows context based injection with is implemented by changing existing Expressions.

So while it is possible to remove the need for Reflection.Emit (which means removing the use of Expression trees), it is a lot of work, and it means the framework needs to make use of reflection instead, and we lose some of the expressiveness and flexibility of the framework. In other words, such trimmed down version of Simple Injector will really be a different framework (the API will be different and trimmed). We must question whether this would be worth the trouble, since in that case such Simple Injector 'Mobile' framework would possibly not have any competitive feature. Developers could simply pick  one of the existing frameworks.

Oct 4, 2013 at 7:54 AM
Edited Oct 4, 2013 at 7:55 AM
Not sure why it says it doesn't run on Windows Phone 7.1 + on the project home page. While the nuget package won't install, you can reference the dlls in the bin\Silverlight directory directly. The only library that won't add is Microsoft.Practices.ServiceLocation.dll but you can grab the Silverlight/WP profile version of it from nuget:

install-package CommonServiceLocator.Silverlight

You'll also get warnings that referencing Silverlight libraries might cause unexpected behavior but so far I had no problems using this library in my windows phone projects.
Coordinator
Oct 5, 2013 at 1:23 PM
Hi alaa_m,

I'm a bit dazzled by your comment. Are you sure that this runs? Perhaps your DI configuration and tests are limited to some simple cases. Have you tried the following:
  • Making registrations using Register instead of RegisterSingle.
  • Making registrations with dependencies.
  • Running Simple Injector on the actual phone instead of in a VS simulator.
  • Calling Verify() to make sure all registrations can be created successfully.
If that all works, that would be cool, but as far as I know, the Windows Phone version of .NET lacks possibility to emit code which is something Expression.Compile depends upon. Simple Injector heavily depends on Expression.Compile and thus on Reflection.Emit.
Oct 5, 2013 at 7:59 PM
Edited Oct 5, 2013 at 8:02 PM
Hi dot_NET_Junkie,

I can verify that all my code using Simple Injector did actually run on the actual device (Windows Phone 8). I mostly use Register() instead of RegisterSingle(). I also have used registration with constructor dependencies and Verify() works fine.

I am not exactly sure if I am hitting code that isn't available for windows phone by using the above so far I haven't encountered any unexpected behavior.

For example, I always have this warning when I reference Simple Injector
Warning 1 Reference to type 'System.Reflection.Emit.ModuleBuilder' claims it is defined in 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\WindowsPhone\v8.0\mscorlib.dll', but it could not be found
ModuleBuilder class isn't available in Windows Phone but I checked this morning and I can see that instance was created.
Coordinator
Oct 6, 2013 at 4:11 PM
I'm still dazzled, but it's great that Simple Injector seems to work on WP8. Does it run on WP7.1 as well? I'll make sure that the ModuleBuilder isn't referenced in the Silverlight dll in the coming v2.4 version. Althoguh the ModuleBuilder type is referenced in code, but never actually used in Silverlight.

To be able to officially support WP though, I need to run the unit tests in the emulator to verify new features don't break anything on WP. What's your experience in unit testing WP code? Another question, can the Silverlight assembly simply be placed in the WP folder of the NuGet package, or do we need a custom WP-specific build of Simple Injector?
Oct 6, 2013 at 7:15 PM
I tried testing while targeting WP7.1 and it worked. I am not sure if it worked because the emulator is actually running WP8 OS or not.

For NuGet package to be successfully imported into WP projects, it has to either target WP specifically or use PCL with the .net 4/wp7.1 profile. However, none of this is necessary, I made WP specific projects for SimpleInjector.WindowsPhone (linking from SimpleInjector.NET), CommonServiceLocator.SimpleInjectorAdapter.WindowsPhone (linking from CommonServiceLocator.SimpleInjectorAdapter) and SimpleInjector.Extensions.WindowsPhone (linking from SimpleInjector.Extensions)

First attempt was to target WP7.1, unfortunately I got tons of errors with many unresolved types like ThreadLocal<T>, ExpressionVisitor, HashSet<T>, Lazy<T>, Tuple<T>, ...

Next, I tried targeting WP8. I only had to remove ModuleBuilder references with compiler directives and all 3 projects built successfully and I can target it from WP8 apps and use the library with no problems and no warnings.

Next I tried creating the unit test project linking from SimpleInjector.NET.Tests.Unit. I got 600 compiler errors. At first I though it was the using statement since for WP unit testing namespace is Microsoft.VisualStudio.TestPlatform.UnitTestFramework instead of Microsoft.VisualStudio.TestTools.UnitTesting. After a quick #if #else #endif another problem occurred. ExpectedException attribute is not available to windows store/wp apps. We use Assert.ThrowsException<TException>(() =>SomethingThatThrows()); instead. Similarly the latter isn't available in Microsoft.VisualStudio.TestTools.UnitTesting.

I am not sure if the best way is to make over 1000 #if #else #endif to fix these compiler errors but I don't see any alternative. Let me know if you do.

For now, I will try and figure out a quick way to add these directives and see how the unit tests go and will post back here once done.
Oct 7, 2013 at 6:09 PM
I ended up implementing my own ThrowsException<>() and used that instead of ExpectedException attribute with regex find/replace. It provided the easiest, fastest and cleanest solution with little manual work.

Overall, 708 tests were run and all succeeded on both emulator and actual device. I think it's looking good to add support for WP8.

I will be happy to assist with anything to make this work. I can also upload the solution for you to look at if you like.
Coordinator
Nov 5, 2013 at 6:23 PM
Hi guys!

We just pushed Simple Injector v2.4 beta2 to NuGet. This release contains a PCL version of Simple Injector with support for Windows Phone 8. It would be great if you could give the beta a try and let me know if it works for you. We really need the feedback to determine whether we should keep WP8 support in the final version or not.

Thanks
Coordinator
Mar 26, 2014 at 9:47 AM
Windows Phone 8 is supported by Simple Injector 2.4 and up.
Marked as answer by dot_NET_Junkie on 3/26/2014 at 2:47 AM