Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Windows Store test projects #214

Closed
keichinger opened this issue Dec 19, 2013 · 25 comments
Closed

Support for Windows Store test projects #214

keichinger opened this issue Dec 19, 2013 · 25 comments

Comments

@keichinger
Copy link

Hello,

I'd like to ask if there are plans to officially support the WinRT and Windows Phone platforms?

At the moment I'm already using FakeItEasy within my Windows Store App (in an Portable Class Library and Windows Store Library) by adding a reference to the FakeItEasy.SL40 assembly.

So far I haven't had any problems using FakeItEasy on WinRT, however, I'd like to make use of NuGet, which obviously doesn't work right now :)

If there's something you want me to (extensively) test then I'd like to offer my resources and time :)

Cheers~

@adamralph
Copy link
Contributor

At the moment there are no plans to do this. FakeItEasy (as well as Moq, NSubstiture, RhinoMocks, etc.) is based on Castle.Core which is only built for .NET 3.5, .NET 4.0 client profile, .NET 4.5, Silverlight 4 and Silverlight 5.

The general approach is to build all the core logic for your application in a PCL which supports both your target platform (e.g. Windows Store or WP) and .NET 4.0/4.5. Your test project can then be built for .NET 4.0/4.5 and can use the FakeItEasy .NET 4.0 build. More details at http://www.planetgeek.ch/2013/02/01/fakeiteasy-and-windows-store-apps-are-becoming-friends.

/cc @philippdolder

@keichinger
Copy link
Author

Most of my business logic are in PCLs already though there is still some logic in Windows Store Libraries due to the fact that you can't do everything in PCLs (like navigation or working on UI). This is the reason why I want to test my Store Libraries as well.

Can't you just modify the NuGet package to use the SL40 version for PCLs and Store Apps? This is what I do right now and it's working since forever :P
This way people like me could make use of NuGet.

@adamralph
Copy link
Contributor

I'm not sure I follow, but there is already an SL40 build in the current FakeItEasy NuGet package. Would that do?

@keichinger
Copy link
Author

That said SL40 version should be used for WinRT :)

I'm already using FakeItEasy with WinRT and PCLs, I just added a manual reference to the SL40 assembly which is working fine so far.

Now, if FakeItEasy's NuGet package would get configured to use the SL40 assembly for WinRT and PCLs people like me could use the NuGet package instead of a manual downloaded (and maintained) version of FakeItEasy.

@adamralph
Copy link
Contributor

Wow, you're right! it does indeed work. I just created a pure Windows Store project (not PCL) and added a reference to the Silverlight FIE lib and executed some FIE code and all just works. I totally didn't expect that.

However, I'm a little reluctant to package up the SL lib and lie about what it is, i.e. advertise it as a Windows Store lib when it's actually an SL4 lib. Do you have any information which explains why this happens to work? I'm just a little worried that things might blow up a little later for some reason, e.g. perhaps a subsequent version of Windows Store might throw a spanner in the works.

@keichinger
Copy link
Author

Heh, I had the very same first expression when it worked, but to answer your question: No, I have no real technical explanation why it's working. I could imagine that both Silverlight and Windows Store Apps are using a subset of .NET which are (more or less?) compatible.

@adamralph
Copy link
Contributor

Well, I guess if it works now there's no real harm in releasing it. It can always be withdrawn in a later release if it becomes problematic.

@FakeItEasy/owners any opinions on this?

To summarise, it seems that the SL4 assembly is usable from a Windows Store (non-PCL) project (at least for version 8.1, perhaps 8.0 too). The proposal is to replicate the SL4 assembly in a win81 folder in the nuget package, and potentially for any other target frameworks for which might find it works e.g. win8, wp7, monotouch, monodroid, etc.

@blairconrad
Copy link
Member

I don't know enough about SL4 or Windows Store. Or PCL to offer much of an opinion. In spite of that, I'm going to opine.

I say "why not try to help people out?", so I'd go for releasing it. I wonder, though, if the feature shouldn't be marked as "beta" or "experimental" or something so users have fair warning that it may not be completely solid. It also protects the project—less embarrassment if we have to pull it back.

@adamralph
Copy link
Contributor

Thanks, and I agree.

I think your idea of marking it experimental is wise. Perhaps we should add a 'compatible with' paragraph to the NuGet package description as I've done with LiteGuard (https://www.nuget.org/packages/LiteGuard/) and mark the experimental targets there.

@adamralph
Copy link
Contributor

Marked as Ready

@adamralph
Copy link
Contributor

This tweet from @jjrdk https://twitter.com/jjrdk/status/418758246665834496 points out the possibility of our assembly actually being a PCL and just referencing the Castle.Core SL assembly.

@ghost ghost assigned adamralph Jan 5, 2014
@adamralph
Copy link
Contributor

@cH40z-Lord have you also tried this for WIndows Phone?

When I try and add a reference to the SL assembly from a Windows Phone 8 project, I get:

A reference to a higher version or incompatible assembly cannot be added to the project.

Windows Store 8 is fine though.

@adamralph
Copy link
Contributor

I've removed Windows Phone from the issue title. The stated workaround does not seem to work for Windows Phone. Windows Store is looking fine though.

blairconrad added a commit that referenced this issue Jan 9, 2014
fix for #214 - added win8 to nuget package
@adamralph
Copy link
Contributor

@cH40z-Lord this will be in the 1.16 release

@adamralph
Copy link
Contributor

Added a wiki page for platform support https://github.com/FakeItEasy/FakeItEasy/wiki/Platform-support

@adamralph
Copy link
Contributor

This has been released, see https://www.nuget.org/packages/FakeItEasy/1.16.0 and https://github.com/FakeItEasy/FakeItEasy/releases/tag/1.16.0

@cH40z-Lord thanks very much for your contribution. look out for your name in the release notes 🏆

@keichinger
Copy link
Author

Thanks for your hard work! I'm sorry for not responding earlier =)
Gonna test it as soon as possible =) This is exciting, feels like another X-mas! :D

@prasannavl
Copy link

Okay, I just ran into this, and skimmed through the conversation. Its quite old. Perhaps, everyone has better understanding of this issue. Regardless, I'll summarize this briefly, since the wiki for platform support is also not up-to-date.

WP8 / W8 Store: Both of these platform actually almost entirely support the Silverlight runtime. WP8 is fully based on Silverlight, and although, W8 is based on WinRT, both have full support (in reference to the API surfaces used here. Obviously, there are Silverlight components that doesn't makes sense in the RT world, but its irrelevant to the project) for the Silverlight runtime underneath.

Starting 8.1, both WP, as well as Store is entirely based on RT, and not silverlight. So, I guess, you can safely remove the experimental tag on the platform support for WP8/W8. But not for WP8.1/W8.1

Cheers,
PVL

@adamralph
Copy link
Contributor

@prasannavl thanks, that's interesting info. So I guess the upshot is that we do support win8 and wp8 but not any later.

I think I'd prefer to leave win8/wp8 marked as experimental for now since we don't have a full test suite replica for that runtime. I will, however, make it clear that later versions are not supported.

@prasannavl
Copy link

Makes sense. And yes, unfortunately, no WP8.1/W8.1 without explicitly porting it, or PCL one.

@adamralph
Copy link
Contributor

Unfortunately FakeItEasy won't support PCL, win81 or wpa81 until Castle.Core does, or if we switch to another dynamic proxy provider which does. Realistically I don't see either of these things happening soon 😉. See castleproject/Core#41

@prasannavl
Copy link

Let's see how things work out.

PS: Just edited the above statement referring to Silverlight runtime support on WinRT, just for technical accuracy :)

@adamralph
Copy link
Contributor

Thanks again for the detailed info. Much appreciated.

@prasannavl
Copy link

No problem. And here's the link I was trying to find, for precise difference in platforms.

http://firstfloorsoftware.com/labs/difflists

@adamralph
Copy link
Contributor

Nice link! Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants