Enable Assembly.Load(Byte[]) in UWP/Appx

[danmoseley]

This is currently blocked. We should enable all NS2.0 API's in UWP that we can possibly enable. This should be able to work. It's also being requested.

https://github.com/dotnet/coreclr/blob/68f72dd2587c3365a9fe74d1991f93612c3bc62a/src/mscorlib/src/System/AppDomain.cs#L556

@rahku @gkhanna79

[gkhanna79]

CC @rahku @kouvel

[MichalStrehovsky]

What's the expected use case for this? Load an IL assembly and start running code from it?

We will not be able to support that in a usable way on Project N without a JIT or an interpreter, neither of which are planned for UWP. Making something work in Debug configuration (when CoreCLR is used), but throw PlatformNotSupportedException on Retail (when we compile to native with Project N) doesn't seem like a win for anyone.

[danmoseley]

@gkhanna79 I was wondering htis myself actually.

[gkhanna79]

Correct - this is the point I raised over email as well.

[ViktorHofer]

We have way to many issues for this. Dan closed my dup and I just closed another dup here in coreclr. Let's disucss this here on this one please.

@MichalStrehovsky:

UWP doesn't allow a JIT. The only thing we could get to work for UWP here is that you could load types and inspect them, and then we would throw whenever you wanted to do anything interesting with them (invoking a method, creating an instance of a type, etc.). I can't come up with a customer scenario where that would be even remotely useful and it's a bunch of code bloat and test cost. It's better to just throw.

As we are also running our tests on UAP (without Project N), would it be possible to support it there? I'm not sure what's the strategy for 2.1. Will it still be UAP in some scenarios or will everything be UAPAOT?

[jkotas]

Making something work in Debug configuration (when CoreCLR is used), but throw PlatformNotSupportedException on Retail (when we compile to native with Project N) doesn't seem like a win for anyone.

It can be win for side-loaded UWP applications that do not need to pass Windows Store restrictions. We have heard asks from developers of enterprise apps who are perfectly happy to ship the "developer experience" to not artificially prohibit things like this.

[MichalStrehovsky]

We have heard asks from developers of enterprise apps who are perfectly happy to ship the "developer experience" to not artificially prohibit things like this

I would be okay with that, but only if it's behind a switch that is off by default. A great deal of .NET Native issues we have dealt with in the past are for customers who turned on .NET Native for the first time the moment they were about to ship. I would rather not see this on the list of issues customer encounter at the last minute that causes them to slip schedules. Behavioral differences between Debug and Release builds are frustrating to deal with.

[ViktorHofer]

Exactly for these reasons we do have compiler warnings / static analysis tools. E.g. when building in Debug it could emit a warning that this API is not available in Release Mode.

[ViktorHofer]

cc @atsushikan @danmosemsft

[jkotas]

Exactly for these reasons we do have compiler warnings / static analysis tools

Agree - http://github.com/terrajobst/platform-compat.

A great deal of .NET Native issues we have dealt with in the past are for customers who turned on .NET Native for the first time

There are number of other differences between .NET Native and CoreCLR. We have tried to conditionally mimic the .NET Native behavior in CoreCLR by adding similar roadblocks like this one in the past. We have given up on it and got rid most of them. I see the LoadFrom/LoadFile checks as last few leftovers from the abandoned effort.

[danmoseley]

There are quite a few other #if FEATURE_APPX in corelib but in a quick look they seem legitimate eg related to PRI's, different unhandled error behavior, ... @jkotas are there any others you think we should remove?

[MichalStrehovsky]

Agree - http://github.com/terrajobst/platform-compat.

That's a Roslyn analyzer - it won't give me anything if I download a NuGet package targeting NetStandard 2.0 and relying on the API, do my development on Debug, then switch to Release just before uploading to the Store, and find myself having to throw out everything that depends on the missing functionality. It was a really unfortunate choice putting APIs to NetStandard that we can't support everywhere, but we did it and now we need to engineer around it in a way that gives people an experience that is not completely miserable.

If we have been disabling these check, @MattWhilden would definitely want to know.

[jkotas]

@jkotas are there any others you think we should remove?

The few checks around Assembly.Load are the only ones left that I am aware of.