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

[wasm][hotreload] Cannot build ApplyUpdateReferencedAssembly with source link #62618

Closed
radical opened this issue Dec 10, 2021 · 11 comments · Fixed by #105758
Closed

[wasm][hotreload] Cannot build ApplyUpdateReferencedAssembly with source link #62618

radical opened this issue Dec 10, 2021 · 11 comments · Fixed by #105758
Assignees
Labels
arch-wasm WebAssembly architecture area-EnC-mono Hot Reload for WebAssembly, iOS/Android, etc in-pr There is an active PR which will close this issue when it is merged
Milestone

Comments

@radical
Copy link
Member

radical commented Dec 10, 2021

I can't build src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/ApplyUpdateReferencedAssembly.csproj with /p:ContinuousIntegrationBuild=true. It fails with:

 initializing ChangeMakerService with capabilities: Baseline, AddMethodToExistingType, AddStaticFieldToExistingType, AddInstanceFieldToExistingType, NewTypeDefinition, ChangeCustomAttributes
  baseline ready
  got a change
  parsing patch #1 from /__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/MethodBody1_v1.cs and creating delta
  Found changes in MethodBody1.cs
EXEC : error : Expected only one module in the delta, got 0 [/__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/ApplyUpdateReferencedAssembly.csproj]
##[error]EXEC(0,0): error : Expected only one module in the delta, got 0
/__w/1/s/.packages/microsoft.dotnet.hotreload.utils.generator.buildtool/1.0.2-alpha.0.21579.1/build/Microsoft.DotNet.HotReload.Utils.Generator.BuildTool.targets(56,5): error MSB3073: The command ""/__w/1/s/.dotnet/dotnet" /__w/1/s/.packages/microsoft.dotnet.hotreload.utils.generator.buildtool/1.0.2-alpha.0.21579.1/build/../tools/net6.0/Microsoft.DotNet.HotReload.Utils.Generator.BuildTool.dll -msbuild:/__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/ApplyUpdateReferencedAssembly.csproj -script:/__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/deltascript.json -p:Configuration=Debug -p:RuntimeIdentifier=browser-wasm" exited with code 10. [/__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/ApplyUpdateReferencedAssembly.csproj]

.. error : Expected only one module in the delta, got 0.

This seems to happen specifically when $(DisableSourceLink)=false, which gets set because of $(ContinuousIntegrationBuild)=true.

The reasons might be similar to #62551 .

  • I am building this locally, where my branch HEAD is not pushed to any branch
@radical radical added arch-wasm WebAssembly architecture area-EnC-mono Hot Reload for WebAssembly, iOS/Android, etc labels Dec 10, 2021
@ghost
Copy link

ghost commented Dec 10, 2021

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

I can't build src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/ApplyUpdateReferencedAssembly.csproj with /p:ContinuousIntegrationBuild=true. It fails with:

 initializing ChangeMakerService with capabilities: Baseline, AddMethodToExistingType, AddStaticFieldToExistingType, AddInstanceFieldToExistingType, NewTypeDefinition, ChangeCustomAttributes
  baseline ready
  got a change
  parsing patch #1 from /__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/MethodBody1_v1.cs and creating delta
  Found changes in MethodBody1.cs
EXEC : error : Expected only one module in the delta, got 0 [/__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/ApplyUpdateReferencedAssembly.csproj]
##[error]EXEC(0,0): error : Expected only one module in the delta, got 0
/__w/1/s/.packages/microsoft.dotnet.hotreload.utils.generator.buildtool/1.0.2-alpha.0.21579.1/build/Microsoft.DotNet.HotReload.Utils.Generator.BuildTool.targets(56,5): error MSB3073: The command ""/__w/1/s/.dotnet/dotnet" /__w/1/s/.packages/microsoft.dotnet.hotreload.utils.generator.buildtool/1.0.2-alpha.0.21579.1/build/../tools/net6.0/Microsoft.DotNet.HotReload.Utils.Generator.BuildTool.dll -msbuild:/__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/ApplyUpdateReferencedAssembly.csproj -script:/__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/deltascript.json -p:Configuration=Debug -p:RuntimeIdentifier=browser-wasm" exited with code 10. [/__w/1/s/src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/ApplyUpdateReferencedAssembly.csproj]

.. error : Expected only one module in the delta, got 0.

This seems to happen specifically when $(DisableSourceLink)=false, which gets set because of $(ContinuousIntegrationBuild)=true.

The reasons might be similar to #62551 .

  • I am building this locally, where my branch HEAD is not pushed to any branch
Author: radical
Assignees: -
Labels:

arch-wasm, area-EnC-mono

Milestone: -

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Dec 10, 2021
@radical
Copy link
Member Author

radical commented Dec 10, 2021

cc @lambdageek

radical added a commit to radical/runtime that referenced this issue Dec 10, 2021
Essentially, disable use of SourceLink which gets enabled by default
when using `-p:ContinuousIntegrationBuild=true`.

Issue: dotnet#62618
@lambdageek
Copy link
Member

@radical Disable the test. (add an ActiveIssue in dotnet/runtime and assign to me, please). I think this is probably a bug in dotnet/hotreload-utils, although it's possible that Roslyn really doesn't generate a delta in this case for some reason.

@lewing lewing added this to the 7.0.0 milestone Dec 15, 2021
@lewing lewing removed the untriaged New issue has not been triaged by the area owner label Dec 15, 2021
thaystg pushed a commit that referenced this issue Dec 16, 2021
* [wasm] Don't emit warning if runtimeconfig.json cannot be found

Library projects don't have runtimeconfig.json files by default. So,
don't make it a warning. Instead, emit a low importance which might be
useful when debugging.

But library projects can have runtimeconfig.json, like the runtime test
projects. So, don't limit processing that by OutputType.

IOW, if it's found then use it.

* [wasm] Add timestamp to logs

* Download dotnet-install script for installing workloads

Instead of trying to use the script from `.dotnet`, download the script.
`.dotnet` might not exist, for example, when the `global.json` version
matches the system installed one.

* [wasm] WasmAppBuilder: catch UnauthorizedAccessException also

* [wasm] Fix bug in tests

Some helper methods have a `Action<JToken>` parameter. Many tests
pass an async lambda to this, expecting it to get awaited upon.

```csharp
    EvaluateAndCheck (Action<T> locals_fn)
    {
        ...
        locals_fn(); // no await
        ...
    }

    async Task Test()
    {
        EvaluateAndCheck( async (locals) => {
            ...
            CheckNumber(locals, ...);

            await CheckDateTime(locals, ..);
            ...

        } );
    }
```

In the above example, roslyn generates an async-void lambda, so the
compiler never complains about the async lambda being passed.
`EvaluateAndCheck` cannot, and does not await this, but if the lambda happens to
block, then it will return at that point, and the test(calling method) will end,
without ever completing the lambda. And for most tests, the actual
checks are done in that lambda.

This gets hit when `CheckDateTimeValue` tries to fetch properties of a
`DateTime` object. And it started to show up when adding
`ConfigureAwait(false)` to some calls.

* [wasm] Add Wasm.Debugger.Tests wrapper project

This is a proxy/wrapper project for `src/mono/wasm/debugger/DebuggerTestSuite/DebuggerTestSuite.csproj`.

- Building the project as part of the regular browser-wasm build
  presents some issues, because of part the tests need use the aspnet
  sdk, and that doesn't work with `browser-wasm`.
- This wrapper project essentially builds the `DebuggerTestSuite`
  project, with some
  properties(`TargetFramework;TargetFrameworks;Configuration;TargetOS;TargetArchitecture`)
  removed so they don't propogate from the parent build.
  - And it packages it up for running the tests on helix

- I did try to convert `DebuggerTestSuite` into a `Wasm.Debugger.Tests`,
  and make it use the library tests infrastructure, but ran into an
  issue
  - it built the project with no `testhost.dll`, so can't use `dotnet
    test`
  - it did get `xunit.console.dll`, but that would fail to run the tests
    because of missing `System.Runtime` (and I'm guessing, other
    assemblies)
    - attempts to publish the project failed
    - So, for now, this is what we have!

* [wasm][tests] Make them friendly to running outside the tree

.. like on helix.

Add new `DEBUGGER_TEST_PATH`, and `CHROME_PATH_FOR_DEBUGGER_TESTS` which
will be set for helix.

And change the appbundle directory name from the misleading `publish/`
to `AppBundle/`.

* [wasm] Tests.cs -> MiscTests.cs

* [wasm] Add support for submitting debugger tests to helix

Also, added `eng/testing/scenarios/WasmDebuggerTestsJobsList.txt` which
is a manually generated list of test classes. This will be changed to be
generated at runtime, in an upcoming PR.

* [wasm] Add debugger tests job for linux, and windows

They follow the same pattern as other wasm jobs:

- build when isFullMatrix
- build in runtime-manual
- Additionally, build when there are changes in:

```
  - src/mono/wasm/debugger/*
  - src/mono/wasm/runtime/*
  - src/mono/mono/*
```

* [wasm] Add new make targets to submit tests to helix

`submit-debugger-tests-helix`
`submit-tests-helix` - submits any library test archives

* Build Wasm.Debugger.Tests from src/libraries/tests.proj

* DebuggerTestSuite: Copy files for the test archive

* [wasm] Fix HarnessTests.BrowserClose

* [wasm] Fix building `ApplyUpdateReferencedAssembly` project on CI

Essentially, disable use of SourceLink which gets enabled by default
when using `-p:ContinuousIntegrationBuild=true`.

Issue: #62618

* cleanup

* Wasm.Build.Tests: add missing file

* [wasm] sendtohelixhelp.proj: Error out if there is more than one zip

.. file when running for Wasm.Build.Tests, or Wasm.Debugger.Tests .

* [wasm] Disable DebuggerTests.ArrayTests on helix

Issue: #62661

Using `[Trait..` instead of `ActiveIssue` because: #62660

* disable non-wasma builds

* sendtohelixhelp.proj: guard against no payload found

* Disable more tests

* add back builds

* [wasm][debugger] Disable failing debugger test

`DebuggerTests.BreakpointTests.BreakpointInAssemblyUsingTypeFromAnotherAssembly_BothDynamicallyLoaded`

Issue: #62823

* Try to fix windows command line

* Move debugger-tests for linux to runtime-staging

* Revert "[wasm][debugger] Fix source-link test (#62786)"

.. as it is breaking debugger tests build on windows.

Issue: #62892
This reverts commit 8151740.
@lewing
Copy link
Member

lewing commented Jun 13, 2022

@lambdageek is this still an open issue?

@ilonatommy
Copy link
Member

Just checked, still failing with the same message.

@radical radical modified the milestones: 7.0.0, 8.0.0 Aug 11, 2022
@lewing
Copy link
Member

lewing commented Aug 13, 2023

@lambdageek can we get a status update here

@lewing lewing modified the milestones: 8.0.0, 9.0.0 Aug 13, 2023
@lambdageek
Copy link
Member

I didn't have time to look into it.

@lewing
Copy link
Member

lewing commented Jul 30, 2024

@thaystg @lambdageek what work is required here?

@lambdageek
Copy link
Member

We should try it again (that is, remove these two lines). I think it's related to dotnet/sdk#36666 which looks like it's fixed. We can also just leave the workaround in place and update the comment

<!-- FIXME: issue -->
<DisableSourceLink>true</DisableSourceLink>

@thaystg
Copy link
Member

thaystg commented Jul 31, 2024

I'm testing.

@ilonatommy
Copy link
Member

It's still failing when the workaround is removed (repro: testing ./dotnet.sh test src/mono/browser/debugger/DebuggerTestSuite --filter DebuggerTests.HotReloadTests -e RuntimeConfiguration=Debug -e Configuration=Debug -e DebuggerHost=chrome)

@dotnet-policy-service dotnet-policy-service bot added the in-pr There is an active PR which will close this issue when it is merged label Jul 31, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Aug 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-EnC-mono Hot Reload for WebAssembly, iOS/Android, etc in-pr There is an active PR which will close this issue when it is merged
Projects
None yet
5 participants