[NuGET] Some packages are not compatible with UAP,Version=v10.0 (win10-x64-aot)

[falaksevak]

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!

[shersh]

It is because UAP platform can't using ProxyGenerator and Moq is not compatible with WinRT, WinPhone and Windows Universal Platform.
And more last commits was 8 months ago and I think this project is dead

[kzu]

The project isn't dead. Anyone can contribute :P.

[kzu]

Oh, and the last commit is from less than a month ago: 061ed36

[RafaelPlantard]

And @kzu how about UWP support?

[kzu]

Read above. Moq4 won't support UWP unless DynamicProxy does.

[Schenry]

@kzu Is there any indication of Dynamic Proxy support coming on the horizon?

[kzu]

No idea. @kkozmic?

On Tue, Oct 20, 2015, 1:45 PM Schenry notifications@github.com wrote:

@kzu https://github.com/kzu Is there any indication of Dynamic Proxy
support coming on the horizon?

—
Reply to this email directly or view it on GitHub
#195 (comment).

[seesharper]

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?

[kzu]

There is a pending PR already that I'm in the process of reviewing, that
switches to a coreclr compatible DynamicProxy, so I think that's the
direction we'll go

On Sat, Dec 12, 2015, 5:06 PM Bernhard Richter 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 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
https://github.com/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 i s that I do have a solution to Moq and
CoreCLR. How do we bring this forward?

—
Reply to this email directly or view it on GitHub
#195 (comment).

[seesharper]

That is great news. Would love to see Moq make the transition to the
CoreCLR. Let me know if you need a hand

On Saturday, 12 December 2015, Daniel Cazzulino notifications@github.com
wrote:

There is a pending PR already that I'm in the process of reviewing, that
switches to a coreclr compatible DynamicProxy, so I think that's the
direction we'll go

On Sat, Dec 12, 2015, 5:06 PM Bernhard Richter <notifications@github.com
javascript:_e(%7B%7D,'cvml','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 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
https://github.com/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 i s that I do have a solution to Moq and
CoreCLR. How do we bring this forward?

—
Reply to this email directly or view it on GitHub
#195 (comment).

—
Reply to this email directly or view it on GitHub
#195 (comment).

[RafaelPlantard]

I'm waiting for it..
Greatest news 👍

[seesharper]

Any news on this?
On tir. 22. des. 2015 at 13.15, Rafael da Silva Ferreira <
notifications@github.com> wrote:

I'm waiting for it..
Greatest news [image: 👍]

—
Reply to this email directly or view it on GitHub
#195 (comment).

[kzu]

There is no nuget of Castle DynamicProxy for UWP

On Tue, Dec 22, 2015, 9:38 AM Bernhard Richter notifications@github.com
wrote:

Any news on this?
On tir. 22. des. 2015 at 13.15, Rafael da Silva Ferreira <
notifications@github.com> wrote:

I'm waiting for it..
Greatest news [image: 👍]

—
Reply to this email directly or view it on GitHub
#195 (comment).

—
Reply to this email directly or view it on GitHub
#195 (comment).

[bitcrazed]

@kzu - if DynamicProxy for UWP is not on the way, perhaps its worth considering if @seesharper's approach using LightInject would work?

[seesharper]

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

[seesharper]

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.

[xied75]

@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?

[seesharper]

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.

[stakx]

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.