-
-
Notifications
You must be signed in to change notification settings - Fork 803
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
[NuGET] Some packages are not compatible with UAP,Version=v10.0 (win10-x64-aot) #195
Comments
It is because UAP platform can't using ProxyGenerator and Moq is not compatible with WinRT, WinPhone and Windows Universal Platform. |
The project isn't dead. Anyone can contribute :P. |
Oh, and the last commit is from less than a month ago: 061ed36 |
And @kzu how about UWP support? |
Read above. Moq4 won't support UWP unless DynamicProxy does. |
@kzu Is there any indication of Dynamic Proxy support coming on the horizon? |
No idea. @kkozmic? On Tue, Oct 20, 2015, 1:45 PM Schenry notifications@github.com wrote:
|
Hi. I am the author of the LightInject Ioc framework and I have recently been working with bringing LightInject and its extensions ready for the future by enabling support for the CoreCLR. One of the extensions to LightInject is LightInject.Interception that enables the AOP capabilities of LightInject. It is basically a proxy library much like DynamicProxy. This is not really tied to the LightInject IoC container apart from a couple of extension methods that can easily be removed. That being said I have been playing around with the Moq code this last week to replace DynamicProxy with LightInject.Interception. So far I am down to just a few failing tests that I am sure I can work out if there is anybody wanting to see Moq available on the CoreCLR. The question is what @kzu thinks of such an idea? Should I fork Moq and create an entirely new NuGet package or should I go for a pull request in this repository? Bottom line is that I do have a solution to Moq and the CoreCLR. How do we bring this forward? |
There is a pending PR already that I'm in the process of reviewing, that On Sat, Dec 12, 2015, 5:06 PM Bernhard Richter notifications@github.com
|
That is great news. Would love to see Moq make the transition to the On Saturday, 12 December 2015, Daniel Cazzulino notifications@github.com
|
I'm waiting for it.. |
Any news on this?
|
There is no nuget of Castle DynamicProxy for UWP On Tue, Dec 22, 2015, 9:38 AM Bernhard Richter notifications@github.com
|
@kzu - if DynamicProxy for UWP is not on the way, perhaps its worth considering if @seesharper's approach using LightInject would work? |
I could create a fork for you all to take a look at. Just let me know. I just did not want to spend too much time on this unless it is going somewhere :) As I said earlier, I got almost all the tests passing (6, maybe 7 tests still failing). But that is based on the CoreCLR. I don't know how that would work with regards to UWP though |
Just to clear things up a little. When it comes to running Moq under the CoreCLR it is certainly possible since the CoreCLR provides pretty much the same API as the full .Net framework. When it comes to Universal Windows Applications (UWA), it is not possible to port Moq at all since the Reflection.Emit namespace lacks the possibility to dynamically create new types at runtime. You can still do code generation using the DynamicMethod, but you cannot create new types which is the very foundation for proxy libraries. If you are looking for a mocking framework that works in such constrained runtimes, you might want to check out https://github.com/seesharper/LightMock. I created this little framework since I needed to support mocking even when running on iOS which pretty much is as constrained as it gets. Bottom line is that CoreCLR support is possible (that is what I tried to get working with LightInject.Interception), but when it comes to UWA it is not possible. |
@seesharper Just wondering, do you think MS limiting UWP access to .NET Emit due to security concern or just a precaution? My point is if in theory having what we want is not going to break the sandbox, maybe we just need to voice that in the proper channel. Also do you think Roslyn can be used instead? |
I think that the reason Microsoft limits the ways we can do dynamic code generation is most certainly of security reasons. You can still generate code at runtime using compiled expression trees. The limitation is that we can not create new types which is needed to create a proxy library. UWP is also a mobile platform and if we compare to iOS and Android, UWP is actually pretty flexible. On iOS and Android you cannot really do anything at runtime. Everything needs to be known at compile time. This is also known as the AOT (Ahead of time) model. And this restriction is why it is extremely hard to get any malicious code into say an iPhone. My guess is that Microsoft, understandably, want the same level of control in mobile app based on UWP. That being said you can still do Expression.Compile on iOS and Android (Xamarin), but that is just an illusion. Behind the scenes, the expression tree is interpreted at runtime which is very different from compiling. Still works, but the performance is abysmal. These limitations are actually the reason I created LightMock since I wanted a mocking library that could work across all platforms. |
Closing due to inactivity, and given the above information and the fact that after almost a year, there is still no indication that DynamicProxy will be supported on UWP (probably impossible), it seems like there is nothing at all that can be done towards supporting UWP at the moment. |
I am trying to install Moq 4.2.1507.118 on Windows 10 VS 2015 using NuGET. However, I get this error:
Some packages are not compatible with UAP,Version=v10.0 (win10-x64-aot)
I even tried to install using package manager console. Still the same issue. Any pointers on how to solve the issue?
Thanks!
The text was updated successfully, but these errors were encountered: