Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Setting RunAOTCompilation=true on non-wasm/non-mobile projects fails to build #77707

Closed
radical opened this issue Nov 1, 2022 · 0 comments · Fixed by #77762
Closed

Setting RunAOTCompilation=true on non-wasm/non-mobile projects fails to build #77707

radical opened this issue Nov 1, 2022 · 0 comments · Fixed by #77762
Assignees
@radical
Labels
area-Build-mono
Milestone
8.0.0

Comments

@radical
Copy link
Member

radical commented Nov 1, 2022

If a simple console project, for example, is built with RunAOTCompilation=true then it fails like:

/usr/local/share/dotnet/sdk/7.0.200-preview.22521.7/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.ImportWorkloads.targets(38,5):

error NETSDK1147: To build this project, the following workloads must be installed: macos [/private/tmp/c/c.csproj]
error NETSDK1147: To install these workloads, run the following command: dotnet workload restore [/private/tmp/c/c.csproj]

And this is because the MonoAOTCompiler.Task is imported with:

https://github.com/radical/runtime/blob/31599a4e9f8b42c4872d7f7446b14d213f75104b/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.targets.in#L57-L58

cc @lewing @steveisok
@radical radical self-assigned this Nov 1, 2022
@ghost ghost added the untriaged New issue has not been triaged by the area owner label Nov 1, 2022
radical added a commit to carlossanlop/runtime that referenced this issue Nov 1, 2022
@radical
[wasm] Workaround for dotnet#77707
fcc492e 
The middleware projects are now being built separately, so they can
target a different TFM. But when `RunAOTCompilation=true` is set, like
on CI/AOT builds, the build breaks with:

```
To build this project, the following workloads must be installed: macos [/__w/1/s/Build.proj]
To install these workloads, run the following command: dotnet workload restore [/__w/1/s/Build.proj]
```

This is described in dotnet#77707 .
And the issue is present in `7.0 rc1` also, which is currently used for
building the repo. To workaround it, we unset some properties which
aren't needed anyway for the middleware projects builds.
@radical radical added this to the 8.0.0 milestone Nov 1, 2022
@ghost ghost removed the untriaged New issue has not been triaged by the area owner label Nov 1, 2022
@radical radical mentioned this issue Nov 2, 2022
Merged
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Nov 2, 2022
carlossanlop added a commit that referenced this issue Nov 2, 2022
@carlossanlop @radical
Update assembly version from hardcoded to MajorVersion (#74157)
f84c1b5 
* Update assembly version from hardcoded to MajorVersion

* Bump version to 8 in XsdDataContractExporterTests

* Retrieve major version dynamically for expected message in TypesTest_Negative

* Retrieve major version dynamically for expected message in SurrogateProvider_MemberData

* Manually generate the TestData.resources.
The dotnet exec command generated by the msbuild Target had to be manually executed in the cmdline with the target framework folders for RemoteExecutor hardcoded to net7.0-windows so the resources file could be generated.

* Avoid hardcoded 8 in additional SurrogateTests line

* Fix Diagnostics.EventLog supression message

* Update assembly version from hardcoded to MajorVersion

* Bump version to 8 in XsdDataContractExporterTests

* Retrieve major version dynamically for expected message in TypesTest_Negative

* Retrieve major version dynamically for expected message in SurrogateProvider_MemberData

* Manually generate the TestData.resources.
The dotnet exec command generated by the msbuild Target had to be manually executed in the cmdline with the target framework folders for RemoteExecutor hardcoded to net7.0-windows so the resources file could be generated.

* Avoid hardcoded 8 in additional SurrogateTests line

* Fix Diagnostics.EventLog supression message

* Extract the LocalEchoServer bits from the projects

.. so that the helix bits are in a LocalEchoServer.helix.targets ,
instead of being special-cased in sendtohelix-wasm.targets .
- And this is setup and used by the test projects by importing one file.

* Build the LocalEchoServers specifically without using artifacts .

- The RemoteLoopServer, and NetCoreServer are projects used as aspnetcore
middleware, and loaded by xharness.
- These are built against the live artifacts, same as other projects.
    - But this can be a problem when the libraries in `runtime` are on a
    newer assembly version (say `8.0.0`), but xharness is still built with
    `7.0.0` libraries.
    - In that case, xharness fails to load the middleware:

```
Application startup exception: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types.

...

Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

   at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
   at System.Reflection.Assembly.GetTypes()
   at Microsoft.DotNet.XHarness.CLI.CommandArguments.TypeFromAssemblyArgument`1.GetLoadedTypes()+MoveNext() in /_/src/Microsoft.DotNet.XHarness.CLI/CommandArguments/Arguments/TypeFromAssemblyArgument.cs:line 29
   at Microsoft.DotNet.XHarness.CLI.Commands.WebServer.<>c__DisplayClass0_0.<Start>b__9(TestWebServerOptions options) in /_/src/Microsoft.DotNet.XHarness.CLI/Commands/WebServer.cs:line 60
   at Microsoft.Extensions.Options.OptionsFactory`1.Create(String name)
   at Microsoft.Extensions.Options.OptionsCache`1.<>c__3`1.<GetOrAdd>b__3_0(String name, ValueTuple`2 arg)
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd[TArg](TKey key, Func`3 valueFactory, TArg factoryArgument)
   at Microsoft.Extensions.Options.OptionsCache`1.GetOrAdd[TArg](String name, Func`3 createOptions, TArg factoryArgument)
   at Microsoft.DotNet.XHarness.CLI.Commands.WebServer.TestWebServerStartup.Configure(IApplicationBuilder app, IOptionsMonitor`1 optionsAccessor) in /_/src/Microsoft.DotNet.XHarness.CLI/Commands/WebServer.cs:line 126
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Microsoft.AspNetCore.Hosting.ConfigureBuilder.Invoke(Object instance, IApplicationBuilder builder)
   at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.Configure(IApplicationBuilder app)
   at Microsoft.AspNetCore.Hosting.WebHost.BuildApplication()
```

- Build the project in isolation from rest of the repo, so that it is
built with references only from the SDK. The built assembly can then be
deployed for use with xharness, just like before.

* add missing files

* [wasm] fixup extensions targets for LocalEchoServer

* [wasm] Use eng/targetingpacks.targets instead of wasm specific targets

* [wasm] Avoid duplicate imports, and don't use the targetingpacks.targets

.. for runtime tests since the paths are set explicitly in the project

* [wasm] Workaround for #77707

The middleware projects are now being built separately, so they can
target a different TFM. But when `RunAOTCompilation=true` is set, like
on CI/AOT builds, the build breaks with:

```
To build this project, the following workloads must be installed: macos [/__w/1/s/Build.proj]
To install these workloads, run the following command: dotnet workload restore [/__w/1/s/Build.proj]
```

This is described in #77707 .
And the issue is present in `7.0 rc1` also, which is currently used for
building the repo. To workaround it, we unset some properties which
aren't needed anyway for the middleware projects builds.

Co-authored-by: carlossanlop <carlossanlop@users.noreply.github.com>
Co-authored-by: Ankit Jain <radical@gmail.com>
@radical radical closed this as completed in 8e45d5f Nov 3, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Nov 3, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Dec 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@radical radical

Labels
area-Build-mono
Projects
None yet
Milestone
8.0.0
Development

Successfully merging a pull request may close this issue.

Mono workloads: Fix building non-mono project when RunAOTCompilation=true radical/runtime
1 participant
@radical