[wasm] Don't use workload for tfm < net6.0

[radical]

If the project requires the workload (eg. for AOT), but the project targets <net6.0, then error out before Publish.

To support this, the Wasm.Build.Tests not support testing with sdk, with no workload installed.

Currently, Wasm.Build.Tests are run in two modes:

1. sdk($(SdkVersionForWorkloadTesting))+workload installed
2. sdk(from global.json)+EMSDK+LocalBuild targets

this commit changes (2) to:

2. sdk($(SdkVersionForWorkloadTesting)), no workload installed, +
   EMSDK+LocalBuild targets

This makes it closer to what a user would actually use.

Also, for the workload tests, this removes $(WasmNativeWorkload)
always being set to true. The workload should be setting that, and not
the tests.

Fixes#54308

[ghost]

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

Issue Details

---

Fixes #54308

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lewing]

I think we probably want an error/warning that explains this?

[radical]

I think we probably want an error/warning that explains this?

I've made it an error when the project requires a workload, but we have to disable it due to tfm<net6.0 . And emitting the error before publish, since that's when the workload would have kicked in. It will be changed to run before build, once we move to that from publish.

[akoeplinger]

nit: there are still a bunch of .css, .razor, weather.json, favicon.ico etc assets that don't seem relevant if we're not running the app so we could get rid of them too as having this Main() here should be enough to test the workload behavior right?

It looks good to me otherwise :)

[radical]

Removing the razor files, it ends up with pretty much an empty Main. I think, it would be preferable to have the razor files around at least, so they can get processed by the build. I'll remove the other files that are needed for running.

.

[radical]

I think this needs some fixes right now, so marked it no-merge.

[radical]

I had to make bigger changes to test the case of testing with latest sdk, and no workload installed. And that exposed other issues, so there are new changes here now. And I'll re-request for review, once I have it working on helix too.

[radical]

/azp run runtime,runtime-staging

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[radical]

Remaining test failure is waiting on #56606 .

[radical]

Blocked on #56974 to get the emsdk update.

[radical]

Installer test failure is #57243 , unrelated to this PR.

[radical]

This could use some testing with VS, runtime/library tests, and blazorwasm projects.

[lewing]

Looking good, I'll do some manual testing then approve.

[radical]

If the project requires the workload (eg. for AOT), but the project targets <net6.0, then error out before Publish.

To support this, the Wasm.Build.Tests not support testing with sdk, with no workload installed.

Currently, Wasm.Build.Tests are run in two modes:

1. sdk($(SdkVersionForWorkloadTesting))+workload installed
2. sdk(from global.json)+EMSDK+LocalBuild targets

this commit changes (2) to:

2. sdk($(SdkVersionForWorkloadTesting)), no workload installed, +
   EMSDK+LocalBuild targets

This makes it closer to what a user would actually use.

Also, for the workload tests, this removes $(WasmNativeWorkload)
always being set to true. The workload should be setting that, and not
the tests.

Fixes#54308

[ghost]

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

Issue Details

---

Fixes #54308

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lewing]

I think we probably want an error/warning that explains this?

[radical]

I think we probably want an error/warning that explains this?

I've made it an error when the project requires a workload, but we have to disable it due to tfm<net6.0 . And emitting the error before publish, since that's when the workload would have kicked in. It will be changed to run before build, once we move to that from publish.

[akoeplinger]

nit: there are still a bunch of .css, .razor, weather.json, favicon.ico etc assets that don't seem relevant if we're not running the app so we could get rid of them too as having this Main() here should be enough to test the workload behavior right?

It looks good to me otherwise :)

[radical]

Removing the razor files, it ends up with pretty much an empty Main. I think, it would be preferable to have the razor files around at least, so they can get processed by the build. I'll remove the other files that are needed for running.

.

[radical]

I think this needs some fixes right now, so marked it no-merge.

[radical]

I had to make bigger changes to test the case of testing with latest sdk, and no workload installed. And that exposed other issues, so there are new changes here now. And I'll re-request for review, once I have it working on helix too.

[radical]

/azp run runtime,runtime-staging

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[radical]

Remaining test failure is waiting on #56606 .

[radical]

Blocked on #56974 to get the emsdk update.

[radical]

Installer test failure is #57243 , unrelated to this PR.

[radical]

This could use some testing with VS, runtime/library tests, and blazorwasm projects.

[lewing]

Looking good, I'll do some manual testing then approve.

[radical]

If the project requires the workload (eg. for AOT), but the project targets <net6.0, then error out before Publish.

To support this, the Wasm.Build.Tests not support testing with sdk, with no workload installed.

Currently, Wasm.Build.Tests are run in two modes:

1. sdk($(SdkVersionForWorkloadTesting))+workload installed
2. sdk(from global.json)+EMSDK+LocalBuild targets

this commit changes (2) to:

2. sdk($(SdkVersionForWorkloadTesting)), no workload installed, +
   EMSDK+LocalBuild targets

This makes it closer to what a user would actually use.

Also, for the workload tests, this removes $(WasmNativeWorkload)
always being set to true. The workload should be setting that, and not
the tests.

Fixes#54308

[ghost]

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

Issue Details

---

Fixes #54308

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lewing]

I think we probably want an error/warning that explains this?

[radical]

I think we probably want an error/warning that explains this?

I've made it an error when the project requires a workload, but we have to disable it due to tfm<net6.0 . And emitting the error before publish, since that's when the workload would have kicked in. It will be changed to run before build, once we move to that from publish.

[akoeplinger]

nit: there are still a bunch of .css, .razor, weather.json, favicon.ico etc assets that don't seem relevant if we're not running the app so we could get rid of them too as having this Main() here should be enough to test the workload behavior right?

It looks good to me otherwise :)

[radical]

Removing the razor files, it ends up with pretty much an empty Main. I think, it would be preferable to have the razor files around at least, so they can get processed by the build. I'll remove the other files that are needed for running.

.

[radical]

I think this needs some fixes right now, so marked it no-merge.

[radical]

I had to make bigger changes to test the case of testing with latest sdk, and no workload installed. And that exposed other issues, so there are new changes here now. And I'll re-request for review, once I have it working on helix too.

[radical]

/azp run runtime,runtime-staging

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[radical]

Remaining test failure is waiting on #56606 .

[radical]

Blocked on #56974 to get the emsdk update.

[radical]

Installer test failure is #57243 , unrelated to this PR.

[radical]

This could use some testing with VS, runtime/library tests, and blazorwasm projects.

[lewing]

Looking good, I'll do some manual testing then approve.

[radical]

If the project requires the workload (eg. for AOT), but the project targets <net6.0, then error out before Publish.

To support this, the Wasm.Build.Tests not support testing with sdk, with no workload installed.

Currently, Wasm.Build.Tests are run in two modes:

1. sdk($(SdkVersionForWorkloadTesting))+workload installed
2. sdk(from global.json)+EMSDK+LocalBuild targets

this commit changes (2) to:

2. sdk($(SdkVersionForWorkloadTesting)), no workload installed, +
   EMSDK+LocalBuild targets

This makes it closer to what a user would actually use.

Also, for the workload tests, this removes $(WasmNativeWorkload)
always being set to true. The workload should be setting that, and not
the tests.

Fixes#54308

[ghost]

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

Issue Details

---

Fixes #54308

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lewing]

I think we probably want an error/warning that explains this?

[radical]

I think we probably want an error/warning that explains this?

I've made it an error when the project requires a workload, but we have to disable it due to tfm<net6.0 . And emitting the error before publish, since that's when the workload would have kicked in. It will be changed to run before build, once we move to that from publish.

[akoeplinger]

nit: there are still a bunch of .css, .razor, weather.json, favicon.ico etc assets that don't seem relevant if we're not running the app so we could get rid of them too as having this Main() here should be enough to test the workload behavior right?

It looks good to me otherwise :)

[radical]

Removing the razor files, it ends up with pretty much an empty Main. I think, it would be preferable to have the razor files around at least, so they can get processed by the build. I'll remove the other files that are needed for running.

.

[radical]

I think this needs some fixes right now, so marked it no-merge.

[radical]

I had to make bigger changes to test the case of testing with latest sdk, and no workload installed. And that exposed other issues, so there are new changes here now. And I'll re-request for review, once I have it working on helix too.

[radical]

/azp run runtime,runtime-staging

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[radical]

Remaining test failure is waiting on #56606 .

[radical]

Blocked on #56974 to get the emsdk update.

[radical]

Installer test failure is #57243 , unrelated to this PR.

[radical]

This could use some testing with VS, runtime/library tests, and blazorwasm projects.

[lewing]

Looking good, I'll do some manual testing then approve.

[radical]

If the project requires the workload (eg. for AOT), but the project targets <net6.0, then error out before Publish.

To support this, the Wasm.Build.Tests not support testing with sdk, with no workload installed.

Currently, Wasm.Build.Tests are run in two modes:

1. sdk($(SdkVersionForWorkloadTesting))+workload installed
2. sdk(from global.json)+EMSDK+LocalBuild targets

this commit changes (2) to:

2. sdk($(SdkVersionForWorkloadTesting)), no workload installed, +
   EMSDK+LocalBuild targets

This makes it closer to what a user would actually use.

Also, for the workload tests, this removes $(WasmNativeWorkload)
always being set to true. The workload should be setting that, and not
the tests.

Fixes#54308

[ghost]

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

Issue Details

---

Fixes #54308

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lewing]

I think we probably want an error/warning that explains this?

[radical]

I think we probably want an error/warning that explains this?

I've made it an error when the project requires a workload, but we have to disable it due to tfm<net6.0 . And emitting the error before publish, since that's when the workload would have kicked in. It will be changed to run before build, once we move to that from publish.

[akoeplinger]

nit: there are still a bunch of .css, .razor, weather.json, favicon.ico etc assets that don't seem relevant if we're not running the app so we could get rid of them too as having this Main() here should be enough to test the workload behavior right?

It looks good to me otherwise :)

[radical]

Removing the razor files, it ends up with pretty much an empty Main. I think, it would be preferable to have the razor files around at least, so they can get processed by the build. I'll remove the other files that are needed for running.

.

[radical]

I think this needs some fixes right now, so marked it no-merge.

[radical]

I had to make bigger changes to test the case of testing with latest sdk, and no workload installed. And that exposed other issues, so there are new changes here now. And I'll re-request for review, once I have it working on helix too.

[radical]

/azp run runtime,runtime-staging

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[radical]

Remaining test failure is waiting on #56606 .

[radical]

Blocked on #56974 to get the emsdk update.

[radical]

Installer test failure is #57243 , unrelated to this PR.

[radical]

This could use some testing with VS, runtime/library tests, and blazorwasm projects.

[lewing]

Looking good, I'll do some manual testing then approve.

[radical]

If the project requires the workload (eg. for AOT), but the project targets <net6.0, then error out before Publish.

To support this, the Wasm.Build.Tests not support testing with sdk, with no workload installed.

Currently, Wasm.Build.Tests are run in two modes:

1. sdk($(SdkVersionForWorkloadTesting))+workload installed
2. sdk(from global.json)+EMSDK+LocalBuild targets

this commit changes (2) to:

2. sdk($(SdkVersionForWorkloadTesting)), no workload installed, +
   EMSDK+LocalBuild targets

This makes it closer to what a user would actually use.

Also, for the workload tests, this removes $(WasmNativeWorkload)
always being set to true. The workload should be setting that, and not
the tests.

Fixes#54308

[ghost]

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

Issue Details

---

Fixes #54308

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lewing]

I think we probably want an error/warning that explains this?

[radical]

I think we probably want an error/warning that explains this?

I've made it an error when the project requires a workload, but we have to disable it due to tfm<net6.0 . And emitting the error before publish, since that's when the workload would have kicked in. It will be changed to run before build, once we move to that from publish.

[akoeplinger]

nit: there are still a bunch of .css, .razor, weather.json, favicon.ico etc assets that don't seem relevant if we're not running the app so we could get rid of them too as having this Main() here should be enough to test the workload behavior right?

It looks good to me otherwise :)

[radical]

Removing the razor files, it ends up with pretty much an empty Main. I think, it would be preferable to have the razor files around at least, so they can get processed by the build. I'll remove the other files that are needed for running.

.

[radical]

I think this needs some fixes right now, so marked it no-merge.

[radical]

I had to make bigger changes to test the case of testing with latest sdk, and no workload installed. And that exposed other issues, so there are new changes here now. And I'll re-request for review, once I have it working on helix too.

[radical]

/azp run runtime,runtime-staging

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[radical]

Remaining test failure is waiting on #56606 .

[radical]

Blocked on #56974 to get the emsdk update.

[radical]

Installer test failure is #57243 , unrelated to this PR.

[radical]

This could use some testing with VS, runtime/library tests, and blazorwasm projects.

[lewing]

Looking good, I'll do some manual testing then approve.

[radical]

If the project requires the workload (eg. for AOT), but the project targets <net6.0, then error out before Publish.

To support this, the Wasm.Build.Tests not support testing with sdk, with no workload installed.

Currently, Wasm.Build.Tests are run in two modes:

1. sdk($(SdkVersionForWorkloadTesting))+workload installed
2. sdk(from global.json)+EMSDK+LocalBuild targets

this commit changes (2) to:

2. sdk($(SdkVersionForWorkloadTesting)), no workload installed, +
   EMSDK+LocalBuild targets

This makes it closer to what a user would actually use.

Also, for the workload tests, this removes $(WasmNativeWorkload)
always being set to true. The workload should be setting that, and not
the tests.

Fixes#54308

[ghost]

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

Issue Details

---

Fixes #54308

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lewing]

I think we probably want an error/warning that explains this?

[radical]

I think we probably want an error/warning that explains this?

I've made it an error when the project requires a workload, but we have to disable it due to tfm<net6.0 . And emitting the error before publish, since that's when the workload would have kicked in. It will be changed to run before build, once we move to that from publish.

[akoeplinger]

nit: there are still a bunch of .css, .razor, weather.json, favicon.ico etc assets that don't seem relevant if we're not running the app so we could get rid of them too as having this Main() here should be enough to test the workload behavior right?

It looks good to me otherwise :)

[radical]

Removing the razor files, it ends up with pretty much an empty Main. I think, it would be preferable to have the razor files around at least, so they can get processed by the build. I'll remove the other files that are needed for running.

.

[radical]

I think this needs some fixes right now, so marked it no-merge.

[radical]

I had to make bigger changes to test the case of testing with latest sdk, and no workload installed. And that exposed other issues, so there are new changes here now. And I'll re-request for review, once I have it working on helix too.

[radical]

/azp run runtime,runtime-staging

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[radical]

Remaining test failure is waiting on #56606 .

[radical]

Blocked on #56974 to get the emsdk update.

[radical]

Installer test failure is #57243 , unrelated to this PR.

[radical]

This could use some testing with VS, runtime/library tests, and blazorwasm projects.

[lewing]

Looking good, I'll do some manual testing then approve.

[radical]

If the project requires the workload (eg. for AOT), but the project targets <net6.0, then error out before Publish.

To support this, the Wasm.Build.Tests not support testing with sdk, with no workload installed.

Currently, Wasm.Build.Tests are run in two modes:

1. sdk($(SdkVersionForWorkloadTesting))+workload installed
2. sdk(from global.json)+EMSDK+LocalBuild targets

this commit changes (2) to:

2. sdk($(SdkVersionForWorkloadTesting)), no workload installed, +
   EMSDK+LocalBuild targets

This makes it closer to what a user would actually use.

Also, for the workload tests, this removes $(WasmNativeWorkload)
always being set to true. The workload should be setting that, and not
the tests.

Fixes#54308

[ghost]

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

Issue Details

---

Fixes #54308

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[lewing]

I think we probably want an error/warning that explains this?

[radical]

I think we probably want an error/warning that explains this?

I've made it an error when the project requires a workload, but we have to disable it due to tfm<net6.0 . And emitting the error before publish, since that's when the workload would have kicked in. It will be changed to run before build, once we move to that from publish.

[akoeplinger]

nit: there are still a bunch of .css, .razor, weather.json, favicon.ico etc assets that don't seem relevant if we're not running the app so we could get rid of them too as having this Main() here should be enough to test the workload behavior right?

It looks good to me otherwise :)

[radical]

Removing the razor files, it ends up with pretty much an empty Main. I think, it would be preferable to have the razor files around at least, so they can get processed by the build. I'll remove the other files that are needed for running.

.

[radical]

I think this needs some fixes right now, so marked it no-merge.

[radical]

I had to make bigger changes to test the case of testing with latest sdk, and no workload installed. And that exposed other issues, so there are new changes here now. And I'll re-request for review, once I have it working on helix too.

[radical]

/azp run runtime,runtime-staging

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[radical]

Remaining test failure is waiting on #56606 .

[radical]

Blocked on #56974 to get the emsdk update.

[radical]

Installer test failure is #57243 , unrelated to this PR.

[radical]

This could use some testing with VS, runtime/library tests, and blazorwasm projects.

[lewing]

Looking good, I'll do some manual testing then approve.