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

Allow mono samples to build and run again #54089

Merged
merged 6 commits into from
Jun 21, 2021

Conversation

lambdageek
Copy link
Member

Copied from src/libraries/Directory.Build.props

Evidently this is sufficient for the console samples to build again:

$ make run MONO_CONFIG=Release MONO_ENV_OPTIONS=
../../../.././dotnet.sh publish -c Release -r linux-x64
Microsoft (R) Build Engine version 16.11.0-preview-21254-21+e73d08c28 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  Used runtime pack: /home/aleksey/working/dotnet-runtime/artifacts/bin/microsoft.netcore.app.runtime.linux-x64/Release/
  Used runtime pack: /home/aleksey/.nuget/packages/microsoft.aspnetcore.app.runtime.linux-x64/6.0.0-preview.4.21253.5
  HelloWorld -> /home/aleksey/working/dotnet-runtime/artifacts/bin/HelloWorld/x64/Release/linux-x64/HelloWorld.dll
  HelloWorld -> /home/aleksey/working/dotnet-runtime/artifacts/bin/HelloWorld/x64/Release/linux-x64/publish/
COMPlus_DebugWriteToStdErr=1 \
MONO_ENV_OPTIONS="" \
../../../../artifacts/bin/HelloWorld/x64/Release/linux-x64/publish/HelloWorld
Hello World from Mono!
System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
HelloWorld, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
.NET 6.0.0-dev

@ghost
Copy link

ghost commented Jun 12, 2021

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

Copied from src/libraries/Directory.Build.props

Evidently this is sufficient for the console samples to build again:

$ make run MONO_CONFIG=Release MONO_ENV_OPTIONS=
../../../.././dotnet.sh publish -c Release -r linux-x64
Microsoft (R) Build Engine version 16.11.0-preview-21254-21+e73d08c28 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  Used runtime pack: /home/aleksey/working/dotnet-runtime/artifacts/bin/microsoft.netcore.app.runtime.linux-x64/Release/
  Used runtime pack: /home/aleksey/.nuget/packages/microsoft.aspnetcore.app.runtime.linux-x64/6.0.0-preview.4.21253.5
  HelloWorld -> /home/aleksey/working/dotnet-runtime/artifacts/bin/HelloWorld/x64/Release/linux-x64/HelloWorld.dll
  HelloWorld -> /home/aleksey/working/dotnet-runtime/artifacts/bin/HelloWorld/x64/Release/linux-x64/publish/
COMPlus_DebugWriteToStdErr=1 \
MONO_ENV_OPTIONS="" \
../../../../artifacts/bin/HelloWorld/x64/Release/linux-x64/publish/HelloWorld
Hello World from Mono!
System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
HelloWorld, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
.NET 6.0.0-dev
Author: lambdageek
Assignees: -
Labels:

area-Infrastructure-mono

Milestone: -

@ghost ghost added this to In Progress in Infrastructure Backlog Jun 12, 2021
@lambdageek
Copy link
Member Author

@akoeplinger @ViktorHofer once again I don't really know what I'm doing... How wrong is this?

Copy link
Member

@akoeplinger akoeplinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, though we should probably look at moving these properties from src/librares/Directory.Build.props to some common location so we don't need to duplicate them.

Copy link
Member

@ViktorHofer ViktorHofer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix. Can you please avoid the duplication and move the properties into the root's Directory.Build.props file after the block in which PackageRID and $(NetCoreAppCurrent) is defined?

Also when doing so, please remove this block:

<MicrosoftNetCoreAppRefPackDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'microsoft.netcore.app.ref'))</MicrosoftNetCoreAppRefPackDir>
<MicrosoftNetCoreAppRefPackRefDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRefPackDir)', 'ref', '$(NetCoreAppCurrent)'))</MicrosoftNetCoreAppRefPackRefDir>
<MicrosoftNetCoreAppRefPackDataDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRefPackDir)', 'data'))</MicrosoftNetCoreAppRefPackDataDir>
<MicrosoftNetCoreAppRuntimePackDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'microsoft.netcore.app.runtime.$(PackageRID)', '$(Configuration)'))</MicrosoftNetCoreAppRuntimePackDir>
<MicrosoftNetCoreAppRuntimePackRidDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackDir)', 'runtimes', '$(PackageRID)'))</MicrosoftNetCoreAppRuntimePackRidDir>
<MicrosoftNetCoreAppRuntimePackRidLibTfmDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackRidDir)', 'lib', '$(NetCoreAppCurrent)'))</MicrosoftNetCoreAppRuntimePackRidLibTfmDir>
<MicrosoftNetCoreAppRuntimePackNativeDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackRidDir)', 'native'))</MicrosoftNetCoreAppRuntimePackNativeDir>

@lambdageek
Copy link
Member Author

@ViktorHofer Done, thanks!

@ViktorHofer
Copy link
Member

I believe this code block is now dead:

<MicrosoftNetCoreAppRuntimePackDir Condition="'$(MicrosoftNetCoreAppRuntimePackDir)' == ''">$([MSBuild]::NormalizeDirectory($(NuGetPackageRoot), 'microsoft.netcore.app.runtime.mono.browser-wasm', '$(BundledNETCoreAppPackageVersion)'))</MicrosoftNetCoreAppRuntimePackDir>
<MicrosoftNetCoreAppRuntimePackRidDir Condition="'$(MicrosoftNetCoreAppRuntimePackRidDir)' == ''">$([MSBuild]::NormalizeDirectory($(MicrosoftNetCoreAppRuntimePackDir), 'runtimes', 'browser-wasm'))</MicrosoftNetCoreAppRuntimePackRidDir>
<MicrosoftNetCoreAppRuntimePackRidDir>$([MSBuild]::NormalizeDirectory($(MicrosoftNetCoreAppRuntimePackRidDir)))</MicrosoftNetCoreAppRuntimePackRidDir>
<MicrosoftNetCoreAppRuntimePackRidNativeDir>$([MSBuild]::NormalizeDirectory($(MicrosoftNetCoreAppRuntimePackRidDir), 'native'))</MicrosoftNetCoreAppRuntimePackRidNativeDir>

@ViktorHofer
Copy link
Member

And a few more that should also be removed. Would be great if you could do that as well in the PR:

  • <MicrosoftNetCoreAppRuntimePackDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'microsoft.netcore.app.runtime.$(PackageRID)', '$(Configuration)'))</MicrosoftNetCoreAppRuntimePackDir>
    <MicrosoftNetCoreAppRuntimePackRidDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackDir)', 'runtimes', '$(PackageRID)'))</MicrosoftNetCoreAppRuntimePackRidDir>
    <MicrosoftNetCoreAppRuntimePackNativeDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackRidDir)', 'native'))</MicrosoftNetCoreAppRuntimePackNativeDir>
  • <MicrosoftNetCoreAppRuntimePackDir>$(ArtifactsBinDir)microsoft.netcore.app.runtime.android-$(TargetArchitecture)\$(Configuration)\runtimes\android-$(TargetArchitecture)\</MicrosoftNetCoreAppRuntimePackDir>
  • <MicrosoftNetCoreAppRuntimePackDir Condition="'$(MicrosoftNetCoreAppRuntimePackDir)' == ''">$([MSBuild]::NormalizeDirectory($(NuGetPackageRoot), 'microsoft.netcore.app.runtime.mono.browser-wasm', '$(BundledNETCoreAppPackageVersion)'))</MicrosoftNetCoreAppRuntimePackDir>
    <MicrosoftNetCoreAppRuntimePackRidDir Condition="'$(MicrosoftNetCoreAppRuntimePackRidDir)' == ''">$([MSBuild]::NormalizeDirectory($(MicrosoftNetCoreAppRuntimePackDir), 'runtimes', 'browser-wasm'))</MicrosoftNetCoreAppRuntimePackRidDir>
    <MicrosoftNetCoreAppRuntimePackRidDir>$([MSBuild]::NormalizeDirectory($(MicrosoftNetCoreAppRuntimePackRidDir)))</MicrosoftNetCoreAppRuntimePackRidDir>
    <MicrosoftNetCoreAppRuntimePackRidNativeDir>$([MSBuild]::NormalizeDirectory($(MicrosoftNetCoreAppRuntimePackRidDir), 'native'))</MicrosoftNetCoreAppRuntimePackRidNativeDir>
  • <MicrosoftNetCoreAppRuntimePackDir>$(ArtifactsBinDir)microsoft.netcore.app.runtime.$(RuntimeIdentifier)\$(Configuration)\</MicrosoftNetCoreAppRuntimePackDir>
  • <MicrosoftNetCoreAppRuntimePackDir>$(ArtifactsBinDir)microsoft.netcore.app.runtime.$(TargetOS.ToLower())-$(TargetArchitecture)\$(Configuration)\</MicrosoftNetCoreAppRuntimePackDir>
  • <MicrosoftNetCoreAppRuntimePackDir>$(ArtifactsBinDir)microsoft.netcore.app.runtime.$(TargetOS.ToLower())-$(TargetArchitecture)\$(Configuration)\</MicrosoftNetCoreAppRuntimePackDir>

@radical
Copy link
Member

radical commented Jun 17, 2021

Copy link
Member

@radical radical left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than removing the entry from src/mono/wasm/build/WasmApp.InTree.props, LGTM!

@lambdageek lambdageek dismissed ViktorHofer’s stale review June 17, 2021 03:14

Applied all the suggested changes, aside from ones that made the tests fail

@ViktorHofer
Copy link
Member

Any idea why tests started failing when removing the properties from the two wasm files? I thought those are dead anyway.

@lambdageek
Copy link
Member Author

Any idea why tests started failing when removing the properties from the two wasm files? I thought those are dead anyway.

Not sure - I didn't have a chance to look into it yet. If I had to guess - the wasm runtime build is different from other platforms because there's a step that runs after the libraries are built. So perhaps the final runtime artifacts for testing are in a slightly different location.

@radical
Copy link
Member

radical commented Jun 17, 2021

Any idea why tests started failing when removing the properties from the two wasm files? I thought those are dead anyway.

Which files? And where are these failing?

@lambdageek
Copy link
Member Author

@radical WasmApp.targets and WasmApp.Native.targets

This is what I did initially after adding the properties to the root Directory.Build.props: 3a6c7bc#diff-9aef04edc740c7aadf146f6890e8316ec4e65030186727ea6286411efea20d02

I don't recall what was failing specifically, but it was the general wasm app building for the libraries tests, I believe. (don't seem to have AzDO links to the oldest CI runs)

@radical
Copy link
Member

radical commented Jun 17, 2021

@radical WasmApp.targets and WasmApp.Native.targets

Those files are used outside the tree too, like in workloads. So, we can't depend on runtime repo's Directory.Build.props providing the values.

@lambdageek
Copy link
Member Author

There's one failure still that I can't explain: "runtime (CoreCLR Pri0 Runtime Tests Run windows arm64 checked)"

##[error].packages\microsoft.dotnet.helix.sdk\6.0.0-beta.21311.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : (NETCORE_ENGINEERING_TELEMETRY=Test) Work item JIT.IL_Conformance in job 54ff2c22-c6df-4b58-8d1b-fe28a368448a has failed.
Failure log: https://helix.dot.net/api/2019-06-17/jobs/54ff2c22-c6df-4b58-8d1b-fe28a368448a/workitems/JIT.IL_Conformance/console
D:\workspace\_work\1\s\.packages\microsoft.dotnet.helix.sdk\6.0.0-beta.21311.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : Work item JIT.jit64 in job 54ff2c22-c6df-4b58-8d1b-fe28a368448a has failed. [D:\workspace\_work\1\s\src\tests\Common\helixpublishwitharcade.proj]
D:\workspace\_work\1\s\.packages\microsoft.dotnet.helix.sdk\6.0.0-beta.21311.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : Failure log: https://helix.dot.net/api/2019-06-17/jobs/54ff2c22-c6df-4b58-8d1b-fe28a368448a/workitems/JIT.jit64/console [D:\workspace\_work\1\s\src\tests\Common\helixpublishwitharcade.proj]
##[error].packages\microsoft.dotnet.helix.sdk\6.0.0-beta.21311.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : (NETCORE_ENGINEERING_TELEMETRY=Test) Work item JIT.jit64 in job 54ff2c22-c6df-4b58-8d1b-fe28a368448a has failed.
Failure log: https://helix.dot.net/api/2019-06-17/jobs/54ff2c22-c6df-4b58-8d1b-fe28a368448a/workitems/JIT.jit64/console

The consoles are empty https://helix.dot.net/api/2019-06-17/jobs/54ff2c22-c6df-4b58-8d1b-fe28a368448a/workitems/JIT.IL_Conformance/console

{"Message":"NotFound","ActivityId":"ed4d27eef51d024bb9c5b5a78855025b"}

and https://helix.dot.net/api/2019-06-17/jobs/54ff2c22-c6df-4b58-8d1b-fe28a368448a/workitems/JIT.jit64/console

{"Message":"NotFound","ActivityId":"6f884237d396f94496fdfcb8581f0336"}

Not sure if that could be related to the changes here.

Copied from src/libraries/Directory.Build.props

Evidently this is sufficient for the console samples to build again:

```
$ make run MONO_CONFIG=Release MONO_ENV_OPTIONS=
../../../.././dotnet.sh publish -c Release -r linux-x64
Microsoft (R) Build Engine version 16.11.0-preview-21254-21+e73d08c28 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  Used runtime pack: /home/aleksey/working/dotnet-runtime/artifacts/bin/microsoft.netcore.app.runtime.linux-x64/Release/
  Used runtime pack: /home/aleksey/.nuget/packages/microsoft.aspnetcore.app.runtime.linux-x64/6.0.0-preview.4.21253.5
  HelloWorld -> /home/aleksey/working/dotnet-runtime/artifacts/bin/HelloWorld/x64/Release/linux-x64/HelloWorld.dll
  HelloWorld -> /home/aleksey/working/dotnet-runtime/artifacts/bin/HelloWorld/x64/Release/linux-x64/publish/
COMPlus_DebugWriteToStdErr=1 \
MONO_ENV_OPTIONS="" \
../../../../artifacts/bin/HelloWorld/x64/Release/linux-x64/publish/HelloWorld
Hello World from Mono!
System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
HelloWorld, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
.NET 6.0.0-dev
```
They are not based on the ArtifactsBinDir property
The tests seem to otherwise look in a coreclr directory for libmono
@marek-safar marek-safar merged commit 30f4269 into dotnet:main Jun 21, 2021
Infrastructure Backlog automation moved this from In Progress to Done Jun 21, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Jul 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants