Changes required to use newGenfacadeModel

[Anipik]

Related PR dotnet/arcade#2221

[Anipik]

cc @tannergooding

[ericstj]

Looks like there are some problems with the aliases in manual mscorlib shim. Getting close.

[ericstj]

References for manual shims are here:

corefx/src/shims/manual/Directory.Build.props

Lines 33 to 35 in 15680bb

	<ReferencePath
	Include="$(_RuntimePath)System.*.dll;$(_RuntimePath)Microsoft.Win32.*.dll;$(_RuntimePath)netstandard.dll"
	Exclude="$(_RuntimePath)System.dll;$(_RuntimePath)System.Data.dll" />

None have aliases. You'll need to add references with aliases.

[ericstj]

@Anipik and I looked at this. It's happening because System.Private.CoreLib had InternalsVisibleTo mscorlib in 2.0, but the GenFacades source isn't considering InternalsVisibleTo when detecting seed preferences (nor did genfacades, but it didn't try to run typeforwards through the compiler).

To fix this he can flow assembly name into the task (simple name only to avoid cracking the SNK), then check the seed assembly for an InternalsVisibleTo attribute containing that assembly name.

[Anipik]

@ericstj i looked at the failure

D:\a\1\s\artifacts\obj\mscorlib\uap-Release\mscorlib.Forwards.cs(73,97): error CS0012: The type 'Enum' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'. [D:\a\1\s\src\shims\manual\mscorlib.csproj]
D:\a\1\s\artifacts\obj\mscorlib\uap-Release\mscorlib.Forwards.cs(73,12): error CS0012: The type 'Enum' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'. [D:\a\1\s\src\shims\manual\mscorlib.csproj]
    0 Warning(s)

The public key token for the system.private.corelib(one getting passed in reference paths) is b03f5f7f11d50a3a and it needs 7cec85d7bea7798e

any idea what should we do here ?

[ericstj]

7cec is the silverlight key. I wouldn’t expect that to show up at all. You may want to see where that’s coming from by scanning the references of all assemblies being passed to the compiler. I have a tool that does this and can help later tonight.

[ericstj]

The type 'System.Reflection.Emit.ParameterBuilder' is defined in multiple seed assemblies. If this is intentional, specify the alias for this type and project reference

This message should list the assemblies which contain the duplicate type.

[ericstj]

You shouldn't be emitting the source file when errors are encountered. This is causing subsequent builds to skip the target which results in different errors upon incremental build.

[ericstj]

Ok, so I've found the issue with the UAPAOT build. The problem here is that we have facades that are building against the coerclr System.Private.CoreLib and running against the .NETNative System.Private.CoreLib and the two have different keys. .NETNative corelib is b03f5f7f11d50a3a, CoreCLR is 7cec85d7bea7798e

The following are the problem projects:

System.Collections.Concurrent.dll
System.Diagnostics.TraceSource.dll
System.Globalization.Calendars.dll
System.Memory.dll
System.Text.Encoding.Extensions.dll
System.Threading.Tasks.Extensions.dll

We should add uap-aot configurations to these projects to fix this issue.

@jkotas are you aware of this difference? Seems like it could be something we'd want to better share forelimb surface area (eg: a System.Private.CoreLib contract between the runtimes).

[jkotas]

It is left over from days when ProjectN CoreLib was very different from CoreCLR CoreLib. IIRC, the different strong name was intentional so that it is harder to mix one and the other by accident. I agree that it would be nice to fix. The workaround you have suggested sounds fine to me.

[ericstj]

The workaround you have suggested sounds fine to me.

Yeah, I almost want to write validation to catch this issue. VerifyClosure ignores pkt today because the coeclr binder does, but maybe I should change that.

[Anipik]

You shouldn't be emitting the source file when errors are encountered. This is causing subsequent builds to skip the target which results in different errors upon incremental build.

I am working on adding a new pr in arcade to add this as well all other features mentioned in the pr and discussed offline

[ericstj]

Sounds good. Maybe we can work together next week to push this change in so we don't have to keep undoing the arcade insertions.

[Anipik]

Sounds good. Maybe we can work together next week to push this change in so we don't have to keep undoing the arcade insertions.

sure :)

[Anipik]

@ericstj @safern
when we are targeting the build of the corefx against uapaot, the TargetGroup property is getting reassigned to uap and targetsAot is always false. is this a bug or am i missing something here ?

[ericstj]

LGTM. Thanks for pushing this feature through!

[Anipik]

LGTM. Thanks for pushing this feature through!

Thanks for the help :)

[ericstj]

when we are targeting the build of the corefx against uapaot, the TargetGroup property is getting reassigned to uap and targetsAot is always false. is this a bug or am i missing something here ?

Not a bug. It sounds like you are missing a configuration for uapaot. In that case the config system will find closest compatible configuration which is uap.

[ericstj]

This is OK to merge once green. Please be sure we have an issue tracking the cleanup of the manual facades build.