Skip to content

[wasm][wbt] Test that dotnet.js could be run from any current directory - #69441

Merged
radical merged 10 commits into
dotnet:mainfrom
yamachu:resolve-asset-path-by-locatefile
Jul 28, 2022
Merged

[wasm][wbt] Test that dotnet.js could be run from any current directory#69441
radical merged 10 commits into
dotnet:mainfrom
yamachu:resolve-asset-path-by-locatefile

Conversation

@yamachu

@yamachuyamachu commented May 17, 2022•
edited by pavelsavara
Loading

Copy link
Copy Markdown
Contributor

In #72275 we fixed locateFile to deal with relative file path or URL. We could also handle absolute path/URL. This PR is adding tests to prove it works.

@yamachu
yamachu requested a review from marek-safar as a code ownerMay 17, 2022 16:14
@ghost

ghost commented May 17, 2022

Copy link
Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@ghostghost added the community-contribution Indicates that the PR has been added by a community member label May 17, 2022
yamachu added a commit to yamachu/azure-functions-nodejs-with-csharp that referenced this pull request May 17, 2022
@yamachu
Waitingdotnet/runtime#69441patch...
206f71e
Until then, replace `else t=r.name;` in dotnet.js with `else t=locateFile(r.name);`
@yamachuyamachu changed the title Use localeFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of remoteSourcesMay 17, 2022
@marek-safarmarek-safar added the arch-wasm WebAssembly architecture label May 17, 2022
@ghost

ghost commented May 17, 2022

Copy link
Copy Markdown

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

Issue Details

Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists

ref: #69259

I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.

Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.
I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).

https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs

Author:yamachu
Assignees:-
Labels:

arch-wasm, community-contribution

Milestone:-

@pavelsavara

pavelsavara commented May 17, 2022

Copy link
Copy Markdown
Member

/azp run runtime-wasm

@azure-pipelines

azure-pipelinesBot commented May 17, 2022

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@lewing
lewing requested a review from thaystgMay 17, 2022 16:52
@pavelsavara

pavelsavara commented May 17, 2022

Copy link
Copy Markdown
Member

hi @yamachu, thanks for the contribution!
At first look I like it, it brings more consistency to locating assets.

It would be great to add unit test to cover running V8 and NodeJS from different folder.
I think we are setting the folder here

runtime/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs

Line 228 in da2cf17

workingDir:bundleDir,

I also wonder what would happen to web app, which has dotnet.js on path relative to window.location
I think we don't have unit test for that either.
(Note that this loader is not used by Blazor, they have their own)

@runfoapprunfoappBot mentioned this pull request May 17, 2022
Closed
@yamachu

yamachu commented May 18, 2022

Copy link
Copy Markdown
ContributorAuthor

Thanks for the review!

I have set up an environment to run the tests you presented, so I rewrote the working directory and ran the tests.
But, the working directory in run-v8.sh has changed and v8 is having problems finding test-main.js.
There is also a module resolution issue with js, so it appears that a drastic rewrite of the test environment is needed...

@yamachu

yamachu commented May 18, 2022

Copy link
Copy Markdown
ContributorAuthor

I have not yet been to verify this for the web app.
Looking at the emscripten implementation, it starts from the URL (window.location.href) where the execution took place.
This is very different from the behavior of path resolution in Node.

In a web environment, it may be desirable to override the locateFile, as in the following sample code.
For example, if you consider the case where you want to distribute dotnet.js or managed assets on a CDN or similar, the locateFile behavior provided by emscripten will not work.
https://github.com/dotnet/runtime/blob/main/src/mono/sample/wasm/browser-nextjs/components/deepThought.js

However, I think it is also possible to support this by utilizing remoteSources in addition to this locateFile change.
https://github.com/dotnet/runtime/blob/10883a7bae7fbd99b1edaa77d4ea4a5a3766114d/src/tasks/WasmAppBuilder/WasmAppBuilder.cs

Currently, only icu files support remoteSources, but I think that by making all assets support it, it will be possible to execute in a way that does not depend on the behavior of the locateFile.

@yamachuyamachu changed the title Use locateFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of AppBundleMay 21, 2022
@yamachuyamachu changed the title Use locateFile to resolve path for assets outside of AppBundleUse locateFile to resolve path for assets outside of remoteSourcesMay 21, 2022
@pavelsavara
pavelsavara requested a review from radicalMay 23, 2022 08:27
@yamachu

This comment was marked as outdated.

Sign in to view
pavelsavara
pavelsavara reviewed May 25, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js Outdated
@ghost

ghost commented May 29, 2022

Copy link
Copy Markdown

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

Issue Details

Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists

ref: #69259

I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.

Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.
I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).

https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs

Author:yamachu
Assignees:pavelsavara
Labels:

arch-wasm, area-Infrastructure-mono, community-contribution

Milestone:-

@pavelsavarapavelsavara mentioned this pull request Jun 7, 2022
Closed
pavelsavara
pavelsavara reviewed Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js Outdated
pavelsavara
pavelsavara reviewed Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js Outdated
yamachu
yamachu commented Jun 30, 2022
View reviewed changes
Comment threadsrc/mono/wasm/runtime/startup.ts Outdated
@yamachu
yamachu requested a review from lewing as a code ownerJuly 4, 2022 16:51
@pavelsavarapavelsavara mentioned this pull request Jul 18, 2022
Merged
@pavelsavara

pavelsavara commented Jul 21, 2022

Copy link
Copy Markdown
Member

@yamachu
I took some of your ideas into #72275.
I would appreciate if you could test that it solves your scenario.

After it's merged, we could rebase this PR and use the unit test you created.

@pavelsavara

pavelsavara commented Jul 26, 2022

Copy link
Copy Markdown
Member

/azp run runtime-wasm

@azure-pipelines

azure-pipelinesBot commented Jul 26, 2022

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

radical
radical reviewed Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs Outdated
radical
radical reviewed Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs Outdated
@radical

radical commented Jul 26, 2022

Copy link
Copy Markdown
Member

You need to add the new test classes to https://github.com/dotnet/runtime/blob/main/eng/testing/scenarios/BuildWasmAppsJobsList.txt .

radical
radical reviewed Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs Outdated
radical
radical reviewed Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs Outdated
radical
radical reviewed Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs Outdated
radical
radical reviewed Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs Outdated
string binDir = GetBinDir(baseDir: _projectDir!, config: buildArgs.Config);
string appBundleDir = Path.Combine(binDir, "AppBundle");
string tmpBundleDirName = "AppBundleTmp";
string tmpBundleDir = Path.Combine(binDir, tmpBundleDirName);

@radicalradicalJul 26, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

What do you think of creating this tmpBundleDir in a completely different location, like under Path.GetTempPath()? This would ensure that it isn't dependent on anything in the binDir.
And make sure to add id, and the project name to the dir name, so the different runs don't overlap.

@yamachuyamachuJul 27, 2022

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

It is a good method in Node and V8 environments!
I' ll change that style.

However, browsers like Chrome cannot explore the parent directory, so I would like to keep the current style.

radical
radical reviewed Jul 27, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs Outdated
@radical

radical commented Jul 27, 2022

Copy link
Copy Markdown
Member

Don't merge yet. The test needs some changes. I will get those working locally, and share that tomorrow.

@radical

radical commented Jul 27, 2022

Copy link
Copy Markdown
Member

So, one of the problems with the WasmRunOutOfAppBundle test is that we won't be able to run dotnet xharness outside in a temporary directory. That can be worked around by creating a tool manifest there, but then we have to get the xharness version from the repo to helix. This applies to all the hosts.

IIUC, the intention here is:

  1. v8, node - start from a directory which is not the AppBundle directory. In which case we can use the parent directory.
  2. chrome - the web server can be started in the parent directory too.

This is what I came up with: https://gist.github.com/radical/18d60949c789cf98f8b175c30096b683 . Feel free to add this to your PR.

The test output has:

  • Running v8 --expose_wasm ./AppBundle/test-main.js ...
  • Running node ./AppBundle/test-main.js ...

Make sure to confirm that it is indeed testing what is intended here. AFAIU, it does that.

@runfoapprunfoappBot mentioned this pull request Jul 27, 2022
Closed
@radical

radical commented Jul 27, 2022

Copy link
Copy Markdown
Member

@yamachu Thank you for your contribution! Great job 👍

@yamachu

yamachu commented Jul 27, 2022

Copy link
Copy Markdown
ContributorAuthor

@pavelsavara@radical
Thanks for all your support!

@radical

radical commented Jul 28, 2022

Copy link
Copy Markdown
Member

Failures are unrelated.

@radical

radical commented Jul 28, 2022

Copy link
Copy Markdown
Member

@yamachu This is only adding the --config-src param to test-main.js, which is not used by any user apps. Was that the intention here? I don't see the reason for adding that, since tests run in a pretty controlled environment.

@yamachu

yamachu commented Jul 28, 2022•
edited
Loading

Copy link
Copy Markdown
ContributorAuthor

This addition is to verify that config-src could be resolved when passed as an absolute path.
ref: #69441 (comment)

@radical
radical merged commit 79d1988 into dotnet:mainJul 28, 2022
@ghostghost locked as resolved and limited conversation to collaborators Aug 27, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@pavelsavarapavelsavarapavelsavara left review comments
@radicalradicalradical approved these changes
@marek-safarmarek-safarAwaiting requested review from marek-safar
@thaystgthaystgAwaiting requested review from thaystg
@lewinglewingAwaiting requested review from lewinglewing is a code owner

Assignees

@pavelsavarapavelsavara

Labels

arch-wasmWebAssembly architecturearea-Infrastructure-monocommunity-contributionIndicates that the PR has been added by a community member

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@yamachu@pavelsavara@radical@marek-safar@jeffhandley
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
[wasm][wbt] Test that `dotnet.js` could be run from any current directory by yamachu · Pull Request #69441 · dotnet/runtime · GitHub
Skip to content
[wasm][wbt] Test that dotnet.js could be run from any current directory - #69441
Merged
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Jul 28, 2022
Merged
[wasm][wbt] Test that dotnet.js could be run from any current directory#69441
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Conversation
@yamachu
@yamachuyamachu
commented
May 17, 2022•

edited by pavelsavara

Loading

Copy link


Copy Markdown

Contributor
In #72275 we fixed locateFile to deal with relative file path or URL. We could also handle absolute path/URL. This PR is adding tests to prove it works.
@yamachu
yamachu
requested a review
from marek-safar
as a code ownerMay 17, 2022 16:14
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
added
the 
community-contribution
Indicates that the PR has been added by a community member
label
May 17, 2022
yamachu added a commit
to yamachu/azure-functions-nodejs-with-csharp
that referenced
this pull request
May 17, 2022
@yamachu
Waitingdotnet/runtime#69441patch...
206f71e
Until then, replace `else t=r.name;` in dotnet.js with `else t=locateFile(r.name);`
@yamachuyamachu
changed the title
Use localeFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of remoteSourcesMay 17, 2022
@marek-safarmarek-safar
added
the 
arch-wasm
WebAssembly architecture
label
May 17, 2022
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

Tagging subscribers to 'arch-wasm': @lewing

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:-
Labels:
arch-wasm, community-contribution
Milestone:-
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
May 17, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
@lewing
lewing
requested a review
from thaystgMay 17, 2022 16:52
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
hi @yamachu, thanks for the contribution!

At first look I like it, it brings more consistency to locating assets.
It would be great to add unit test to cover running V8 and NodeJS from different folder.

I think we are setting the folder here
runtime/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs

Line 228
in
da2cf17
workingDir:bundleDir,
I also wonder what would happen to web app, which has dotnet.js on path relative to window.location

I think we don't have unit test for that either.

(Note that this loader is not used by Blazor, they have their own)
@runfoapprunfoappBot
mentioned this pull request
May 17, 2022

Closed

@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
Thanks for the review!
I have set up an environment to run the tests you presented, so I rewrote the working directory and ran the tests.

But, the working directory in run-v8.sh has changed and v8 is having problems finding test-main.js.

There is also a module resolution issue with js, so it appears that a drastic rewrite of the test environment is needed...
@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
I have not yet been to verify this for the web app.

Looking at the emscripten implementation, it starts from the URL (window.location.href) where the execution took place.

This is very different from the behavior of path resolution in Node.
In a web environment, it may be desirable to override the locateFile, as in the following sample code.

For example, if you consider the case where you want to distribute dotnet.js or managed assets on a CDN or similar, the locateFile behavior provided by emscripten will not work.
https://github.com/dotnet/runtime/blob/main/src/mono/sample/wasm/browser-nextjs/components/deepThought.js
However, I think it is also possible to support this by utilizing remoteSources in addition to this locateFile change.
https://github.com/dotnet/runtime/blob/10883a7bae7fbd99b1edaa77d4ea4a5a3766114d/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Currently, only icu files support remoteSources, but I think that by making all assets support it, it will be possible to execute in a way that does not depend on the behavior of the locateFile.
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of AppBundleMay 21, 2022
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of AppBundleUse locateFile to resolve path for assets outside of remoteSourcesMay 21, 2022
@pavelsavara
pavelsavara
requested a review
from radicalMay 23, 2022 08:27
@yamachu

This comment was marked as outdated.

Sign in to view
pavelsavara
pavelsavara
reviewed
May 25, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

@ghost
ghost
commented
May 29, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @directhex

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:pavelsavara
Labels:
arch-wasm, area-Infrastructure-mono, community-contribution
Milestone:-
@pavelsavarapavelsavara
mentioned this pull request
Jun 7, 2022
 Closed

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

yamachu
yamachu
commented
Jun 30, 2022
View reviewed changes
Comment threadsrc/mono/wasm/runtime/startup.ts
Outdated

@yamachu
yamachu
requested a review
from lewing
as a code ownerJuly 4, 2022 16:51
@pavelsavarapavelsavara
mentioned this pull request
Jul 18, 2022
 Merged

@pavelsavara
pavelsavara
commented
Jul 21, 2022

Copy link


Copy Markdown

Member
@yamachu

I took some of your ideas into #72275.

I would appreciate if you could test that it solves your scenario.
After it's merged, we could rebase this PR and use the unit test you created.
@pavelsavara
pavelsavara
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
Jul 26, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

@radical
radical
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
You need to add the new test classes to https://github.com/dotnet/runtime/blob/main/eng/testing/scenarios/BuildWasmAppsJobsList.txt .
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

 string binDir = GetBinDir(baseDir: _projectDir!, config: buildArgs.Config);
 string appBundleDir = Path.Combine(binDir, "AppBundle");
 string tmpBundleDirName = "AppBundleTmp";
 string tmpBundleDir = Path.Combine(binDir, tmpBundleDirName);
@radicalradicalJul 26, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

What do you think of creating this tmpBundleDir in a completely different location, like under Path.GetTempPath()? This would ensure that it isn't dependent on anything in the binDir.

And make sure to add id, and the project name to the dir name, so the different runs don't overlap.
@yamachuyamachuJul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

It is a good method in Node and V8 environments!

I' ll change that style.
However, browsers like Chrome cannot explore the parent directory, so I would like to keep the current style.
radical
radical
reviewed
Jul 27, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
Don't merge yet. The test needs some changes. I will get those working locally, and share that tomorrow.
@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
So, one of the problems with the WasmRunOutOfAppBundle test is that we won't be able to run dotnet xharness outside in a temporary directory. That can be worked around by creating a tool manifest there, but then we have to get the xharness version from the repo to helix. This applies to all the hosts.
IIUC, the intention here is:
  1. v8, node - start from a directory which is not the AppBundle directory. In which case we can use the parent directory.
  2. chrome - the web server can be started in the parent directory too.
This is what I came up with: https://gist.github.com/radical/18d60949c789cf98f8b175c30096b683 . Feel free to add this to your PR.
The test output has:
  • Running v8 --expose_wasm ./AppBundle/test-main.js ...
  • Running node ./AppBundle/test-main.js ...
Make sure to confirm that it is indeed testing what is intended here. AFAIU, it does that.
@runfoapprunfoappBot
mentioned this pull request
Jul 27, 2022

Closed

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
@yamachu Thank you for your contribution! Great job 👍
@yamachu
yamachu
commented
Jul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
@pavelsavara@radical

Thanks for all your support!
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
Failures are unrelated.
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
@yamachu This is only adding the --config-src param to test-main.js, which is not used by any user apps. Was that the intention here? I don't see the reason for adding that, since tests run in a pretty controlled environment.
@yamachu
yamachu
commented
Jul 28, 2022•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
This addition is to verify that config-src could be resolved when passed as an absolute path.

ref: #69441 (comment)
@radical
radical
merged commit 79d1988
into
dotnet:mainJul 28, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Aug 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@pavelsavarapavelsavarapavelsavara left review comments
@radicalradicalradical approved these changes
@marek-safarmarek-safarAwaiting requested review from marek-safar
@thaystgthaystgAwaiting requested review from thaystg
@lewinglewingAwaiting requested review from lewinglewing is a code owner

Assignees

@pavelsavarapavelsavara

Labels

arch-wasmWebAssembly architecturearea-Infrastructure-monocommunity-contributionIndicates that the PR has been added by a community member

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@yamachu@pavelsavara@radical@marek-safar@jeffhandley

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[wasm][wbt] Test that `dotnet.js` could be run from any current directory by yamachu · Pull Request #69441 · dotnet/runtime · GitHub
Skip to content
[wasm][wbt] Test that dotnet.js could be run from any current directory - #69441
Merged
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Jul 28, 2022
Merged
[wasm][wbt] Test that dotnet.js could be run from any current directory#69441
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Conversation
@yamachu
@yamachuyamachu
commented
May 17, 2022•

edited by pavelsavara

Loading

Copy link


Copy Markdown

Contributor
In #72275 we fixed locateFile to deal with relative file path or URL. We could also handle absolute path/URL. This PR is adding tests to prove it works.
@yamachu
yamachu
requested a review
from marek-safar
as a code ownerMay 17, 2022 16:14
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
added
the 
community-contribution
Indicates that the PR has been added by a community member
label
May 17, 2022
yamachu added a commit
to yamachu/azure-functions-nodejs-with-csharp
that referenced
this pull request
May 17, 2022
@yamachu
Waitingdotnet/runtime#69441patch...
206f71e
Until then, replace `else t=r.name;` in dotnet.js with `else t=locateFile(r.name);`
@yamachuyamachu
changed the title
Use localeFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of remoteSourcesMay 17, 2022
@marek-safarmarek-safar
added
the 
arch-wasm
WebAssembly architecture
label
May 17, 2022
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

Tagging subscribers to 'arch-wasm': @lewing

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:-
Labels:
arch-wasm, community-contribution
Milestone:-
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
May 17, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
@lewing
lewing
requested a review
from thaystgMay 17, 2022 16:52
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
hi @yamachu, thanks for the contribution!

At first look I like it, it brings more consistency to locating assets.
It would be great to add unit test to cover running V8 and NodeJS from different folder.

I think we are setting the folder here
runtime/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs

Line 228
in
da2cf17
workingDir:bundleDir,
I also wonder what would happen to web app, which has dotnet.js on path relative to window.location

I think we don't have unit test for that either.

(Note that this loader is not used by Blazor, they have their own)
@runfoapprunfoappBot
mentioned this pull request
May 17, 2022

Closed

@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
Thanks for the review!
I have set up an environment to run the tests you presented, so I rewrote the working directory and ran the tests.

But, the working directory in run-v8.sh has changed and v8 is having problems finding test-main.js.

There is also a module resolution issue with js, so it appears that a drastic rewrite of the test environment is needed...
@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
I have not yet been to verify this for the web app.

Looking at the emscripten implementation, it starts from the URL (window.location.href) where the execution took place.

This is very different from the behavior of path resolution in Node.
In a web environment, it may be desirable to override the locateFile, as in the following sample code.

For example, if you consider the case where you want to distribute dotnet.js or managed assets on a CDN or similar, the locateFile behavior provided by emscripten will not work.
https://github.com/dotnet/runtime/blob/main/src/mono/sample/wasm/browser-nextjs/components/deepThought.js
However, I think it is also possible to support this by utilizing remoteSources in addition to this locateFile change.
https://github.com/dotnet/runtime/blob/10883a7bae7fbd99b1edaa77d4ea4a5a3766114d/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Currently, only icu files support remoteSources, but I think that by making all assets support it, it will be possible to execute in a way that does not depend on the behavior of the locateFile.
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of AppBundleMay 21, 2022
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of AppBundleUse locateFile to resolve path for assets outside of remoteSourcesMay 21, 2022
@pavelsavara
pavelsavara
requested a review
from radicalMay 23, 2022 08:27
@yamachu

This comment was marked as outdated.

Sign in to view
pavelsavara
pavelsavara
reviewed
May 25, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

@ghost
ghost
commented
May 29, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @directhex

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:pavelsavara
Labels:
arch-wasm, area-Infrastructure-mono, community-contribution
Milestone:-
@pavelsavarapavelsavara
mentioned this pull request
Jun 7, 2022
 Closed

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

yamachu
yamachu
commented
Jun 30, 2022
View reviewed changes
Comment threadsrc/mono/wasm/runtime/startup.ts
Outdated

@yamachu
yamachu
requested a review
from lewing
as a code ownerJuly 4, 2022 16:51
@pavelsavarapavelsavara
mentioned this pull request
Jul 18, 2022
 Merged

@pavelsavara
pavelsavara
commented
Jul 21, 2022

Copy link


Copy Markdown

Member
@yamachu

I took some of your ideas into #72275.

I would appreciate if you could test that it solves your scenario.
After it's merged, we could rebase this PR and use the unit test you created.
@pavelsavara
pavelsavara
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
Jul 26, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

@radical
radical
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
You need to add the new test classes to https://github.com/dotnet/runtime/blob/main/eng/testing/scenarios/BuildWasmAppsJobsList.txt .
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

 string binDir = GetBinDir(baseDir: _projectDir!, config: buildArgs.Config);
 string appBundleDir = Path.Combine(binDir, "AppBundle");
 string tmpBundleDirName = "AppBundleTmp";
 string tmpBundleDir = Path.Combine(binDir, tmpBundleDirName);
@radicalradicalJul 26, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

What do you think of creating this tmpBundleDir in a completely different location, like under Path.GetTempPath()? This would ensure that it isn't dependent on anything in the binDir.

And make sure to add id, and the project name to the dir name, so the different runs don't overlap.
@yamachuyamachuJul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

It is a good method in Node and V8 environments!

I' ll change that style.
However, browsers like Chrome cannot explore the parent directory, so I would like to keep the current style.
radical
radical
reviewed
Jul 27, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
Don't merge yet. The test needs some changes. I will get those working locally, and share that tomorrow.
@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
So, one of the problems with the WasmRunOutOfAppBundle test is that we won't be able to run dotnet xharness outside in a temporary directory. That can be worked around by creating a tool manifest there, but then we have to get the xharness version from the repo to helix. This applies to all the hosts.
IIUC, the intention here is:
  1. v8, node - start from a directory which is not the AppBundle directory. In which case we can use the parent directory.
  2. chrome - the web server can be started in the parent directory too.
This is what I came up with: https://gist.github.com/radical/18d60949c789cf98f8b175c30096b683 . Feel free to add this to your PR.
The test output has:
  • Running v8 --expose_wasm ./AppBundle/test-main.js ...
  • Running node ./AppBundle/test-main.js ...
Make sure to confirm that it is indeed testing what is intended here. AFAIU, it does that.
@runfoapprunfoappBot
mentioned this pull request
Jul 27, 2022

Closed

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
@yamachu Thank you for your contribution! Great job 👍
@yamachu
yamachu
commented
Jul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
@pavelsavara@radical

Thanks for all your support!
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
Failures are unrelated.
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
@yamachu This is only adding the --config-src param to test-main.js, which is not used by any user apps. Was that the intention here? I don't see the reason for adding that, since tests run in a pretty controlled environment.
@yamachu
yamachu
commented
Jul 28, 2022•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
This addition is to verify that config-src could be resolved when passed as an absolute path.

ref: #69441 (comment)
@radical
radical
merged commit 79d1988
into
dotnet:mainJul 28, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Aug 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@pavelsavarapavelsavarapavelsavara left review comments
@radicalradicalradical approved these changes
@marek-safarmarek-safarAwaiting requested review from marek-safar
@thaystgthaystgAwaiting requested review from thaystg
@lewinglewingAwaiting requested review from lewinglewing is a code owner

Assignees

@pavelsavarapavelsavara

Labels

arch-wasmWebAssembly architecturearea-Infrastructure-monocommunity-contributionIndicates that the PR has been added by a community member

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@yamachu@pavelsavara@radical@marek-safar@jeffhandley

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[wasm][wbt] Test that `dotnet.js` could be run from any current directory by yamachu · Pull Request #69441 · dotnet/runtime · GitHub
Skip to content
[wasm][wbt] Test that dotnet.js could be run from any current directory - #69441
Merged
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Jul 28, 2022
Merged
[wasm][wbt] Test that dotnet.js could be run from any current directory#69441
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Conversation
@yamachu
@yamachuyamachu
commented
May 17, 2022•

edited by pavelsavara

Loading

Copy link


Copy Markdown

Contributor
In #72275 we fixed locateFile to deal with relative file path or URL. We could also handle absolute path/URL. This PR is adding tests to prove it works.
@yamachu
yamachu
requested a review
from marek-safar
as a code ownerMay 17, 2022 16:14
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
added
the 
community-contribution
Indicates that the PR has been added by a community member
label
May 17, 2022
yamachu added a commit
to yamachu/azure-functions-nodejs-with-csharp
that referenced
this pull request
May 17, 2022
@yamachu
Waitingdotnet/runtime#69441patch...
206f71e
Until then, replace `else t=r.name;` in dotnet.js with `else t=locateFile(r.name);`
@yamachuyamachu
changed the title
Use localeFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of remoteSourcesMay 17, 2022
@marek-safarmarek-safar
added
the 
arch-wasm
WebAssembly architecture
label
May 17, 2022
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

Tagging subscribers to 'arch-wasm': @lewing

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:-
Labels:
arch-wasm, community-contribution
Milestone:-
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
May 17, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
@lewing
lewing
requested a review
from thaystgMay 17, 2022 16:52
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
hi @yamachu, thanks for the contribution!

At first look I like it, it brings more consistency to locating assets.
It would be great to add unit test to cover running V8 and NodeJS from different folder.

I think we are setting the folder here
runtime/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs

Line 228
in
da2cf17
workingDir:bundleDir,
I also wonder what would happen to web app, which has dotnet.js on path relative to window.location

I think we don't have unit test for that either.

(Note that this loader is not used by Blazor, they have their own)
@runfoapprunfoappBot
mentioned this pull request
May 17, 2022

Closed

@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
Thanks for the review!
I have set up an environment to run the tests you presented, so I rewrote the working directory and ran the tests.

But, the working directory in run-v8.sh has changed and v8 is having problems finding test-main.js.

There is also a module resolution issue with js, so it appears that a drastic rewrite of the test environment is needed...
@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
I have not yet been to verify this for the web app.

Looking at the emscripten implementation, it starts from the URL (window.location.href) where the execution took place.

This is very different from the behavior of path resolution in Node.
In a web environment, it may be desirable to override the locateFile, as in the following sample code.

For example, if you consider the case where you want to distribute dotnet.js or managed assets on a CDN or similar, the locateFile behavior provided by emscripten will not work.
https://github.com/dotnet/runtime/blob/main/src/mono/sample/wasm/browser-nextjs/components/deepThought.js
However, I think it is also possible to support this by utilizing remoteSources in addition to this locateFile change.
https://github.com/dotnet/runtime/blob/10883a7bae7fbd99b1edaa77d4ea4a5a3766114d/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Currently, only icu files support remoteSources, but I think that by making all assets support it, it will be possible to execute in a way that does not depend on the behavior of the locateFile.
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of AppBundleMay 21, 2022
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of AppBundleUse locateFile to resolve path for assets outside of remoteSourcesMay 21, 2022
@pavelsavara
pavelsavara
requested a review
from radicalMay 23, 2022 08:27
@yamachu

This comment was marked as outdated.

Sign in to view
pavelsavara
pavelsavara
reviewed
May 25, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

@ghost
ghost
commented
May 29, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @directhex

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:pavelsavara
Labels:
arch-wasm, area-Infrastructure-mono, community-contribution
Milestone:-
@pavelsavarapavelsavara
mentioned this pull request
Jun 7, 2022
 Closed

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

yamachu
yamachu
commented
Jun 30, 2022
View reviewed changes
Comment threadsrc/mono/wasm/runtime/startup.ts
Outdated

@yamachu
yamachu
requested a review
from lewing
as a code ownerJuly 4, 2022 16:51
@pavelsavarapavelsavara
mentioned this pull request
Jul 18, 2022
 Merged

@pavelsavara
pavelsavara
commented
Jul 21, 2022

Copy link


Copy Markdown

Member
@yamachu

I took some of your ideas into #72275.

I would appreciate if you could test that it solves your scenario.
After it's merged, we could rebase this PR and use the unit test you created.
@pavelsavara
pavelsavara
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
Jul 26, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

@radical
radical
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
You need to add the new test classes to https://github.com/dotnet/runtime/blob/main/eng/testing/scenarios/BuildWasmAppsJobsList.txt .
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

 string binDir = GetBinDir(baseDir: _projectDir!, config: buildArgs.Config);
 string appBundleDir = Path.Combine(binDir, "AppBundle");
 string tmpBundleDirName = "AppBundleTmp";
 string tmpBundleDir = Path.Combine(binDir, tmpBundleDirName);
@radicalradicalJul 26, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

What do you think of creating this tmpBundleDir in a completely different location, like under Path.GetTempPath()? This would ensure that it isn't dependent on anything in the binDir.

And make sure to add id, and the project name to the dir name, so the different runs don't overlap.
@yamachuyamachuJul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

It is a good method in Node and V8 environments!

I' ll change that style.
However, browsers like Chrome cannot explore the parent directory, so I would like to keep the current style.
radical
radical
reviewed
Jul 27, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
Don't merge yet. The test needs some changes. I will get those working locally, and share that tomorrow.
@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
So, one of the problems with the WasmRunOutOfAppBundle test is that we won't be able to run dotnet xharness outside in a temporary directory. That can be worked around by creating a tool manifest there, but then we have to get the xharness version from the repo to helix. This applies to all the hosts.
IIUC, the intention here is:
  1. v8, node - start from a directory which is not the AppBundle directory. In which case we can use the parent directory.
  2. chrome - the web server can be started in the parent directory too.
This is what I came up with: https://gist.github.com/radical/18d60949c789cf98f8b175c30096b683 . Feel free to add this to your PR.
The test output has:
  • Running v8 --expose_wasm ./AppBundle/test-main.js ...
  • Running node ./AppBundle/test-main.js ...
Make sure to confirm that it is indeed testing what is intended here. AFAIU, it does that.
@runfoapprunfoappBot
mentioned this pull request
Jul 27, 2022

Closed

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
@yamachu Thank you for your contribution! Great job 👍
@yamachu
yamachu
commented
Jul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
@pavelsavara@radical

Thanks for all your support!
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
Failures are unrelated.
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
@yamachu This is only adding the --config-src param to test-main.js, which is not used by any user apps. Was that the intention here? I don't see the reason for adding that, since tests run in a pretty controlled environment.
@yamachu
yamachu
commented
Jul 28, 2022•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
This addition is to verify that config-src could be resolved when passed as an absolute path.

ref: #69441 (comment)
@radical
radical
merged commit 79d1988
into
dotnet:mainJul 28, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Aug 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@pavelsavarapavelsavarapavelsavara left review comments
@radicalradicalradical approved these changes
@marek-safarmarek-safarAwaiting requested review from marek-safar
@thaystgthaystgAwaiting requested review from thaystg
@lewinglewingAwaiting requested review from lewinglewing is a code owner

Assignees

@pavelsavarapavelsavara

Labels

arch-wasmWebAssembly architecturearea-Infrastructure-monocommunity-contributionIndicates that the PR has been added by a community member

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@yamachu@pavelsavara@radical@marek-safar@jeffhandley

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
[wasm][wbt] Test that `dotnet.js` could be run from any current directory by yamachu · Pull Request #69441 · dotnet/runtime · GitHub
Skip to content
[wasm][wbt] Test that dotnet.js could be run from any current directory - #69441
Merged
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Jul 28, 2022
Merged
[wasm][wbt] Test that dotnet.js could be run from any current directory#69441
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Conversation
@yamachu
@yamachuyamachu
commented
May 17, 2022•

edited by pavelsavara

Loading

Copy link


Copy Markdown

Contributor
In #72275 we fixed locateFile to deal with relative file path or URL. We could also handle absolute path/URL. This PR is adding tests to prove it works.
@yamachu
yamachu
requested a review
from marek-safar
as a code ownerMay 17, 2022 16:14
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
added
the 
community-contribution
Indicates that the PR has been added by a community member
label
May 17, 2022
yamachu added a commit
to yamachu/azure-functions-nodejs-with-csharp
that referenced
this pull request
May 17, 2022
@yamachu
Waitingdotnet/runtime#69441patch...
206f71e
Until then, replace `else t=r.name;` in dotnet.js with `else t=locateFile(r.name);`
@yamachuyamachu
changed the title
Use localeFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of remoteSourcesMay 17, 2022
@marek-safarmarek-safar
added
the 
arch-wasm
WebAssembly architecture
label
May 17, 2022
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

Tagging subscribers to 'arch-wasm': @lewing

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:-
Labels:
arch-wasm, community-contribution
Milestone:-
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
May 17, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
@lewing
lewing
requested a review
from thaystgMay 17, 2022 16:52
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
hi @yamachu, thanks for the contribution!

At first look I like it, it brings more consistency to locating assets.
It would be great to add unit test to cover running V8 and NodeJS from different folder.

I think we are setting the folder here
runtime/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs

Line 228
in
da2cf17
workingDir:bundleDir,
I also wonder what would happen to web app, which has dotnet.js on path relative to window.location

I think we don't have unit test for that either.

(Note that this loader is not used by Blazor, they have their own)
@runfoapprunfoappBot
mentioned this pull request
May 17, 2022

Closed

@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
Thanks for the review!
I have set up an environment to run the tests you presented, so I rewrote the working directory and ran the tests.

But, the working directory in run-v8.sh has changed and v8 is having problems finding test-main.js.

There is also a module resolution issue with js, so it appears that a drastic rewrite of the test environment is needed...
@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
I have not yet been to verify this for the web app.

Looking at the emscripten implementation, it starts from the URL (window.location.href) where the execution took place.

This is very different from the behavior of path resolution in Node.
In a web environment, it may be desirable to override the locateFile, as in the following sample code.

For example, if you consider the case where you want to distribute dotnet.js or managed assets on a CDN or similar, the locateFile behavior provided by emscripten will not work.
https://github.com/dotnet/runtime/blob/main/src/mono/sample/wasm/browser-nextjs/components/deepThought.js
However, I think it is also possible to support this by utilizing remoteSources in addition to this locateFile change.
https://github.com/dotnet/runtime/blob/10883a7bae7fbd99b1edaa77d4ea4a5a3766114d/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Currently, only icu files support remoteSources, but I think that by making all assets support it, it will be possible to execute in a way that does not depend on the behavior of the locateFile.
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of AppBundleMay 21, 2022
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of AppBundleUse locateFile to resolve path for assets outside of remoteSourcesMay 21, 2022
@pavelsavara
pavelsavara
requested a review
from radicalMay 23, 2022 08:27
@yamachu

This comment was marked as outdated.

Sign in to view
pavelsavara
pavelsavara
reviewed
May 25, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

@ghost
ghost
commented
May 29, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @directhex

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:pavelsavara
Labels:
arch-wasm, area-Infrastructure-mono, community-contribution
Milestone:-
@pavelsavarapavelsavara
mentioned this pull request
Jun 7, 2022
 Closed

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

yamachu
yamachu
commented
Jun 30, 2022
View reviewed changes
Comment threadsrc/mono/wasm/runtime/startup.ts
Outdated

@yamachu
yamachu
requested a review
from lewing
as a code ownerJuly 4, 2022 16:51
@pavelsavarapavelsavara
mentioned this pull request
Jul 18, 2022
 Merged

@pavelsavara
pavelsavara
commented
Jul 21, 2022

Copy link


Copy Markdown

Member
@yamachu

I took some of your ideas into #72275.

I would appreciate if you could test that it solves your scenario.
After it's merged, we could rebase this PR and use the unit test you created.
@pavelsavara
pavelsavara
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
Jul 26, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

@radical
radical
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
You need to add the new test classes to https://github.com/dotnet/runtime/blob/main/eng/testing/scenarios/BuildWasmAppsJobsList.txt .
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

 string binDir = GetBinDir(baseDir: _projectDir!, config: buildArgs.Config);
 string appBundleDir = Path.Combine(binDir, "AppBundle");
 string tmpBundleDirName = "AppBundleTmp";
 string tmpBundleDir = Path.Combine(binDir, tmpBundleDirName);
@radicalradicalJul 26, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

What do you think of creating this tmpBundleDir in a completely different location, like under Path.GetTempPath()? This would ensure that it isn't dependent on anything in the binDir.

And make sure to add id, and the project name to the dir name, so the different runs don't overlap.
@yamachuyamachuJul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

It is a good method in Node and V8 environments!

I' ll change that style.
However, browsers like Chrome cannot explore the parent directory, so I would like to keep the current style.
radical
radical
reviewed
Jul 27, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
Don't merge yet. The test needs some changes. I will get those working locally, and share that tomorrow.
@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
So, one of the problems with the WasmRunOutOfAppBundle test is that we won't be able to run dotnet xharness outside in a temporary directory. That can be worked around by creating a tool manifest there, but then we have to get the xharness version from the repo to helix. This applies to all the hosts.
IIUC, the intention here is:
  1. v8, node - start from a directory which is not the AppBundle directory. In which case we can use the parent directory.
  2. chrome - the web server can be started in the parent directory too.
This is what I came up with: https://gist.github.com/radical/18d60949c789cf98f8b175c30096b683 . Feel free to add this to your PR.
The test output has:
  • Running v8 --expose_wasm ./AppBundle/test-main.js ...
  • Running node ./AppBundle/test-main.js ...
Make sure to confirm that it is indeed testing what is intended here. AFAIU, it does that.
@runfoapprunfoappBot
mentioned this pull request
Jul 27, 2022

Closed

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
@yamachu Thank you for your contribution! Great job 👍
@yamachu
yamachu
commented
Jul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
@pavelsavara@radical

Thanks for all your support!
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
Failures are unrelated.
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
@yamachu This is only adding the --config-src param to test-main.js, which is not used by any user apps. Was that the intention here? I don't see the reason for adding that, since tests run in a pretty controlled environment.
@yamachu
yamachu
commented
Jul 28, 2022•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
This addition is to verify that config-src could be resolved when passed as an absolute path.

ref: #69441 (comment)
@radical
radical
merged commit 79d1988
into
dotnet:mainJul 28, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Aug 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@pavelsavarapavelsavarapavelsavara left review comments
@radicalradicalradical approved these changes
@marek-safarmarek-safarAwaiting requested review from marek-safar
@thaystgthaystgAwaiting requested review from thaystg
@lewinglewingAwaiting requested review from lewinglewing is a code owner

Assignees

@pavelsavarapavelsavara

Labels

arch-wasmWebAssembly architecturearea-Infrastructure-monocommunity-contributionIndicates that the PR has been added by a community member

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@yamachu@pavelsavara@radical@marek-safar@jeffhandley

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[wasm][wbt] Test that `dotnet.js` could be run from any current directory by yamachu · Pull Request #69441 · dotnet/runtime · GitHub
Skip to content
[wasm][wbt] Test that dotnet.js could be run from any current directory - #69441
Merged
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Jul 28, 2022
Merged
[wasm][wbt] Test that dotnet.js could be run from any current directory#69441
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Conversation
@yamachu
@yamachuyamachu
commented
May 17, 2022•

edited by pavelsavara

Loading

Copy link


Copy Markdown

Contributor
In #72275 we fixed locateFile to deal with relative file path or URL. We could also handle absolute path/URL. This PR is adding tests to prove it works.
@yamachu
yamachu
requested a review
from marek-safar
as a code ownerMay 17, 2022 16:14
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
added
the 
community-contribution
Indicates that the PR has been added by a community member
label
May 17, 2022
yamachu added a commit
to yamachu/azure-functions-nodejs-with-csharp
that referenced
this pull request
May 17, 2022
@yamachu
Waitingdotnet/runtime#69441patch...
206f71e
Until then, replace `else t=r.name;` in dotnet.js with `else t=locateFile(r.name);`
@yamachuyamachu
changed the title
Use localeFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of remoteSourcesMay 17, 2022
@marek-safarmarek-safar
added
the 
arch-wasm
WebAssembly architecture
label
May 17, 2022
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

Tagging subscribers to 'arch-wasm': @lewing

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:-
Labels:
arch-wasm, community-contribution
Milestone:-
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
May 17, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
@lewing
lewing
requested a review
from thaystgMay 17, 2022 16:52
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
hi @yamachu, thanks for the contribution!

At first look I like it, it brings more consistency to locating assets.
It would be great to add unit test to cover running V8 and NodeJS from different folder.

I think we are setting the folder here
runtime/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs

Line 228
in
da2cf17
workingDir:bundleDir,
I also wonder what would happen to web app, which has dotnet.js on path relative to window.location

I think we don't have unit test for that either.

(Note that this loader is not used by Blazor, they have their own)
@runfoapprunfoappBot
mentioned this pull request
May 17, 2022

Closed

@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
Thanks for the review!
I have set up an environment to run the tests you presented, so I rewrote the working directory and ran the tests.

But, the working directory in run-v8.sh has changed and v8 is having problems finding test-main.js.

There is also a module resolution issue with js, so it appears that a drastic rewrite of the test environment is needed...
@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
I have not yet been to verify this for the web app.

Looking at the emscripten implementation, it starts from the URL (window.location.href) where the execution took place.

This is very different from the behavior of path resolution in Node.
In a web environment, it may be desirable to override the locateFile, as in the following sample code.

For example, if you consider the case where you want to distribute dotnet.js or managed assets on a CDN or similar, the locateFile behavior provided by emscripten will not work.
https://github.com/dotnet/runtime/blob/main/src/mono/sample/wasm/browser-nextjs/components/deepThought.js
However, I think it is also possible to support this by utilizing remoteSources in addition to this locateFile change.
https://github.com/dotnet/runtime/blob/10883a7bae7fbd99b1edaa77d4ea4a5a3766114d/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Currently, only icu files support remoteSources, but I think that by making all assets support it, it will be possible to execute in a way that does not depend on the behavior of the locateFile.
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of AppBundleMay 21, 2022
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of AppBundleUse locateFile to resolve path for assets outside of remoteSourcesMay 21, 2022
@pavelsavara
pavelsavara
requested a review
from radicalMay 23, 2022 08:27
@yamachu

This comment was marked as outdated.

Sign in to view
pavelsavara
pavelsavara
reviewed
May 25, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

@ghost
ghost
commented
May 29, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @directhex

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:pavelsavara
Labels:
arch-wasm, area-Infrastructure-mono, community-contribution
Milestone:-
@pavelsavarapavelsavara
mentioned this pull request
Jun 7, 2022
 Closed

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

yamachu
yamachu
commented
Jun 30, 2022
View reviewed changes
Comment threadsrc/mono/wasm/runtime/startup.ts
Outdated

@yamachu
yamachu
requested a review
from lewing
as a code ownerJuly 4, 2022 16:51
@pavelsavarapavelsavara
mentioned this pull request
Jul 18, 2022
 Merged

@pavelsavara
pavelsavara
commented
Jul 21, 2022

Copy link


Copy Markdown

Member
@yamachu

I took some of your ideas into #72275.

I would appreciate if you could test that it solves your scenario.
After it's merged, we could rebase this PR and use the unit test you created.
@pavelsavara
pavelsavara
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
Jul 26, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

@radical
radical
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
You need to add the new test classes to https://github.com/dotnet/runtime/blob/main/eng/testing/scenarios/BuildWasmAppsJobsList.txt .
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

 string binDir = GetBinDir(baseDir: _projectDir!, config: buildArgs.Config);
 string appBundleDir = Path.Combine(binDir, "AppBundle");
 string tmpBundleDirName = "AppBundleTmp";
 string tmpBundleDir = Path.Combine(binDir, tmpBundleDirName);
@radicalradicalJul 26, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

What do you think of creating this tmpBundleDir in a completely different location, like under Path.GetTempPath()? This would ensure that it isn't dependent on anything in the binDir.

And make sure to add id, and the project name to the dir name, so the different runs don't overlap.
@yamachuyamachuJul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

It is a good method in Node and V8 environments!

I' ll change that style.
However, browsers like Chrome cannot explore the parent directory, so I would like to keep the current style.
radical
radical
reviewed
Jul 27, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
Don't merge yet. The test needs some changes. I will get those working locally, and share that tomorrow.
@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
So, one of the problems with the WasmRunOutOfAppBundle test is that we won't be able to run dotnet xharness outside in a temporary directory. That can be worked around by creating a tool manifest there, but then we have to get the xharness version from the repo to helix. This applies to all the hosts.
IIUC, the intention here is:
  1. v8, node - start from a directory which is not the AppBundle directory. In which case we can use the parent directory.
  2. chrome - the web server can be started in the parent directory too.
This is what I came up with: https://gist.github.com/radical/18d60949c789cf98f8b175c30096b683 . Feel free to add this to your PR.
The test output has:
  • Running v8 --expose_wasm ./AppBundle/test-main.js ...
  • Running node ./AppBundle/test-main.js ...
Make sure to confirm that it is indeed testing what is intended here. AFAIU, it does that.
@runfoapprunfoappBot
mentioned this pull request
Jul 27, 2022

Closed

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
@yamachu Thank you for your contribution! Great job 👍
@yamachu
yamachu
commented
Jul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
@pavelsavara@radical

Thanks for all your support!
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
Failures are unrelated.
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
@yamachu This is only adding the --config-src param to test-main.js, which is not used by any user apps. Was that the intention here? I don't see the reason for adding that, since tests run in a pretty controlled environment.
@yamachu
yamachu
commented
Jul 28, 2022•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
This addition is to verify that config-src could be resolved when passed as an absolute path.

ref: #69441 (comment)
@radical
radical
merged commit 79d1988
into
dotnet:mainJul 28, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Aug 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@pavelsavarapavelsavarapavelsavara left review comments
@radicalradicalradical approved these changes
@marek-safarmarek-safarAwaiting requested review from marek-safar
@thaystgthaystgAwaiting requested review from thaystg
@lewinglewingAwaiting requested review from lewinglewing is a code owner

Assignees

@pavelsavarapavelsavara

Labels

arch-wasmWebAssembly architecturearea-Infrastructure-monocommunity-contributionIndicates that the PR has been added by a community member

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@yamachu@pavelsavara@radical@marek-safar@jeffhandley

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
})();
[wasm][wbt] Test that `dotnet.js` could be run from any current directory by yamachu · Pull Request #69441 · dotnet/runtime · GitHub
Skip to content
[wasm][wbt] Test that dotnet.js could be run from any current directory - #69441
Merged
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Jul 28, 2022
Merged
[wasm][wbt] Test that dotnet.js could be run from any current directory#69441
radical merged 10 commits into
dotnet:mainfrom 
yamachu:resolve-asset-path-by-locatefile
Conversation
@yamachu
@yamachuyamachu
commented
May 17, 2022•

edited by pavelsavara

Loading

Copy link


Copy Markdown

Contributor
In #72275 we fixed locateFile to deal with relative file path or URL. We could also handle absolute path/URL. This PR is adding tests to prove it works.
@yamachu
yamachu
requested a review
from marek-safar
as a code ownerMay 17, 2022 16:14
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
added
the 
community-contribution
Indicates that the PR has been added by a community member
label
May 17, 2022
yamachu added a commit
to yamachu/azure-functions-nodejs-with-csharp
that referenced
this pull request
May 17, 2022
@yamachu
Waitingdotnet/runtime#69441patch...
206f71e
Until then, replace `else t=r.name;` in dotnet.js with `else t=locateFile(r.name);`
@yamachuyamachu
changed the title
Use localeFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of remoteSourcesMay 17, 2022
@marek-safarmarek-safar
added
the 
arch-wasm
WebAssembly architecture
label
May 17, 2022
@ghost
ghost
commented
May 17, 2022

Copy link


Copy Markdown

Tagging subscribers to 'arch-wasm': @lewing

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:-
Labels:
arch-wasm, community-contribution
Milestone:-
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
May 17, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
@lewing
lewing
requested a review
from thaystgMay 17, 2022 16:52
@pavelsavara
pavelsavara
commented
May 17, 2022

Copy link


Copy Markdown

Member
hi @yamachu, thanks for the contribution!

At first look I like it, it brings more consistency to locating assets.
It would be great to add unit test to cover running V8 and NodeJS from different folder.

I think we are setting the folder here
runtime/src/tests/BuildWasmApps/Wasm.Build.Tests/BuildTestBase.cs

Line 228
in
da2cf17
workingDir:bundleDir,
I also wonder what would happen to web app, which has dotnet.js on path relative to window.location

I think we don't have unit test for that either.

(Note that this loader is not used by Blazor, they have their own)
@runfoapprunfoappBot
mentioned this pull request
May 17, 2022

Closed

@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
Thanks for the review!
I have set up an environment to run the tests you presented, so I rewrote the working directory and ran the tests.

But, the working directory in run-v8.sh has changed and v8 is having problems finding test-main.js.

There is also a module resolution issue with js, so it appears that a drastic rewrite of the test environment is needed...
@yamachu
yamachu
commented
May 18, 2022

Copy link


Copy Markdown

ContributorAuthor
I have not yet been to verify this for the web app.

Looking at the emscripten implementation, it starts from the URL (window.location.href) where the execution took place.

This is very different from the behavior of path resolution in Node.
In a web environment, it may be desirable to override the locateFile, as in the following sample code.

For example, if you consider the case where you want to distribute dotnet.js or managed assets on a CDN or similar, the locateFile behavior provided by emscripten will not work.
https://github.com/dotnet/runtime/blob/main/src/mono/sample/wasm/browser-nextjs/components/deepThought.js
However, I think it is also possible to support this by utilizing remoteSources in addition to this locateFile change.
https://github.com/dotnet/runtime/blob/10883a7bae7fbd99b1edaa77d4ea4a5a3766114d/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Currently, only icu files support remoteSources, but I think that by making all assets support it, it will be possible to execute in a way that does not depend on the behavior of the locateFile.
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of remoteSourcesUse locateFile to resolve path for assets outside of AppBundleMay 21, 2022
@yamachuyamachu
changed the title
Use locateFile to resolve path for assets outside of AppBundleUse locateFile to resolve path for assets outside of remoteSourcesMay 21, 2022
@pavelsavara
pavelsavara
requested a review
from radicalMay 23, 2022 08:27
@yamachu

This comment was marked as outdated.

Sign in to view
pavelsavara
pavelsavara
reviewed
May 25, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

@ghost
ghost
commented
May 29, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @directhex

See info in area-owners.md if you want to be subscribed.
Issue Details
Use locateFile to resolve path for assets outside of remoteSources, so that we can run from a different path than locate that dotnet.js exists
ref: #69259
I followed the repro step described in the Issue ( #69259 ) and confirmed that it works.
Referring to the mono-config.json generation task, I found that the file output destination was fixed at AppDir based path.

I therefore decided that I could use a locateFile based from scriptDirectory ( https://github.com/emscripten-core/emscripten/blob/e1d97f55d12ed63dc30e547c818af9a63be0b976/src/shell.js#L155 ).
https://github.com/dotnet/runtime/blob/3f0c2cc88dc8efdde04f422bb05ef13719ce6aa8/src/tasks/WasmAppBuilder/WasmAppBuilder.cs
Author:yamachu
Assignees:pavelsavara
Labels:
arch-wasm, area-Infrastructure-mono, community-contribution
Milestone:-
@pavelsavarapavelsavara
mentioned this pull request
Jun 7, 2022
 Closed

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

pavelsavara
pavelsavara
reviewed
Jun 27, 2022
View reviewed changes
Comment threadsrc/mono/wasm/test-main.js
Outdated

yamachu
yamachu
commented
Jun 30, 2022
View reviewed changes
Comment threadsrc/mono/wasm/runtime/startup.ts
Outdated

@yamachu
yamachu
requested a review
from lewing
as a code ownerJuly 4, 2022 16:51
@pavelsavarapavelsavara
mentioned this pull request
Jul 18, 2022
 Merged

@pavelsavara
pavelsavara
commented
Jul 21, 2022

Copy link


Copy Markdown

Member
@yamachu

I took some of your ideas into #72275.

I would appreciate if you could test that it solves your scenario.
After it's merged, we could rebase this PR and use the unit test you created.
@pavelsavara
pavelsavara
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
/azp run runtime-wasm
@azure-pipelines
azure-pipelinesBot
commented
Jul 26, 2022

Copy link


Copy Markdown


Azure Pipelines successfully started running 1 pipeline(s).
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

@radical
radical
commented
Jul 26, 2022

Copy link


Copy Markdown

Member
You need to add the new test classes to https://github.com/dotnet/runtime/blob/main/eng/testing/scenarios/BuildWasmAppsJobsList.txt .
radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/ConfigSrcTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

radical
radical
reviewed
Jul 26, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

 string binDir = GetBinDir(baseDir: _projectDir!, config: buildArgs.Config);
 string appBundleDir = Path.Combine(binDir, "AppBundle");
 string tmpBundleDirName = "AppBundleTmp";
 string tmpBundleDir = Path.Combine(binDir, tmpBundleDirName);
@radicalradicalJul 26, 2022

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

What do you think of creating this tmpBundleDir in a completely different location, like under Path.GetTempPath()? This would ensure that it isn't dependent on anything in the binDir.

And make sure to add id, and the project name to the dir name, so the different runs don't overlap.
@yamachuyamachuJul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

It is a good method in Node and V8 environments!

I' ll change that style.
However, browsers like Chrome cannot explore the parent directory, so I would like to keep the current style.
radical
radical
reviewed
Jul 27, 2022
View reviewed changes
Comment threadsrc/tests/BuildWasmApps/Wasm.Build.Tests/WasmRunOutOfAppBundleTests.cs
Outdated

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
Don't merge yet. The test needs some changes. I will get those working locally, and share that tomorrow.
@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
So, one of the problems with the WasmRunOutOfAppBundle test is that we won't be able to run dotnet xharness outside in a temporary directory. That can be worked around by creating a tool manifest there, but then we have to get the xharness version from the repo to helix. This applies to all the hosts.
IIUC, the intention here is:
  1. v8, node - start from a directory which is not the AppBundle directory. In which case we can use the parent directory.
  2. chrome - the web server can be started in the parent directory too.
This is what I came up with: https://gist.github.com/radical/18d60949c789cf98f8b175c30096b683 . Feel free to add this to your PR.
The test output has:
  • Running v8 --expose_wasm ./AppBundle/test-main.js ...
  • Running node ./AppBundle/test-main.js ...
Make sure to confirm that it is indeed testing what is intended here. AFAIU, it does that.
@runfoapprunfoappBot
mentioned this pull request
Jul 27, 2022

Closed

@radical
radical
commented
Jul 27, 2022

Copy link


Copy Markdown

Member
@yamachu Thank you for your contribution! Great job 👍
@yamachu
yamachu
commented
Jul 27, 2022

Copy link


Copy Markdown

ContributorAuthor
@pavelsavara@radical

Thanks for all your support!
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
Failures are unrelated.
@radical
radical
commented
Jul 28, 2022

Copy link


Copy Markdown

Member
@yamachu This is only adding the --config-src param to test-main.js, which is not used by any user apps. Was that the intention here? I don't see the reason for adding that, since tests run in a pretty controlled environment.
@yamachu
yamachu
commented
Jul 28, 2022•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
This addition is to verify that config-src could be resolved when passed as an absolute path.

ref: #69441 (comment)
@radical
radical
merged commit 79d1988
into
dotnet:mainJul 28, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Aug 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@pavelsavarapavelsavarapavelsavara left review comments
@radicalradicalradical approved these changes
@marek-safarmarek-safarAwaiting requested review from marek-safar
@thaystgthaystgAwaiting requested review from thaystg
@lewinglewingAwaiting requested review from lewinglewing is a code owner

Assignees

@pavelsavarapavelsavara

Labels

arch-wasmWebAssembly architecturearea-Infrastructure-monocommunity-contributionIndicates that the PR has been added by a community member

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@yamachu@pavelsavara@radical@marek-safar@jeffhandley