-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update assembly version from hardcoded to MajorVersion and update NetCoreAppCurrent to net8.0 #78354
Update assembly version from hardcoded to MajorVersion and update NetCoreAppCurrent to net8.0 #78354
Conversation
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsCo-authored with @radical Original PR was #74157 but we had to revert it #77899 Reason why it had to be reverted:
|
…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.
- 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.
… runtime tests since the paths are set explicitly in the project
c5dc79a
to
057c3f8
Compare
@ViktorHofer do we need any other changes to prevent breaking the other repos, or are we good now? I can't approve this PR because I submitted it, and I assume @ViktorHofer can't either since he contributed to it too. @agocke / @ericstj / @smasher164 / @radical can we get a sign-off from at least one of you? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving others and my own changes.
@ViktorHofer Can I do anything in DNNE to make this better? |
I don't want to block this PR, but consider just redefining |
That sounds like a good strategy until we have strongly defined dependencies in the repo. But before adding the |
DNNE's msbuild integration is well written and allows to customize any of the used properties. I doubt that we would need improvements there to simplify our build. The problem is dotnet/runtime itself which makes it hard to depend on live built artifacts (like the host) because of the way it currently builds in CI (runtime and libraries in parallel on separate machines). |
Agreed, especially if the host is only needed to run the |
@@ -101,7 +101,7 @@ For more advanced scenarios, look for at [Building the Tests](/docs/workflow/tes | |||
|
|||
### Running library tests | |||
|
|||
Build library tests by passing the `libs.tests` subset together with the `/p:TestNativeAot=true` to build the libraries, i.e. `clr.aot+libs+libs.tests /p:TestNativeAot=true` together with the full arguments as specified [above](#building). Then, to run a specific library, go to the tests directory of the library and run the usual command to run tests for the library (see [Running tests for a single library](/docs/workflow/testing/libraries/testing.md#running-tests-for-a-single-library)) but add the `/p:TestNativeAot=true` and the build configuration that was used, i.e. `dotnet.cmd build /t:Test /p:TestNativeAot=true -c Release`. | |||
Build library tests by passing the `libs.tests` subset together with the `/p:TestNativeAot=true` to build the libraries, i.e. `clr.runtime+clr.aot+host.native+libs+libs.tests /p:TestNativeAot=true` together with the full arguments as specified [above](#building). Then, to run a specific library, go to the tests directory of the library and run the usual command to run tests for the library (see [Running tests for a single library](/docs/workflow/testing/libraries/testing.md#running-tests-for-a-single-library)) but add the `/p:TestNativeAot=true` and the build configuration that was used, i.e. `dotnet.cmd build /t:Test /p:TestNativeAot=true -c Release`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really necessary?
I thought the failures we saw were related to the RunNativeAotTestApps
step that was added in #76109. We don't run that in this doc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, you are right. I mixed up RunNativeAotTestApps
and TestNativeAot
. Will send a follow-up to revert this change to not block this PR.
As mentioned in #78354 (comment), this documentation refers to libraries tests and not `RunNativeAotTestApps` testing. Reverting the documentation change.
…SecondAttempt Update assembly version from hardcoded to MajorVersion and update NetCoreAppCurrent to net8.0 Commit migrated from dotnet/runtime@315f4ab
As mentioned in #78354 (comment), this documentation refers to libraries tests and not `RunNativeAotTestApps` testing. Reverting the documentation change.
Contributes to #72112
Fixes #58109
Co-authored with @radical and @ViktorHofer
Original PR was #74157 but we had to revert it #77899
Reason why it had to be reverted: