Update assembly version from hardcoded to MajorVersion #74157
Conversation
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsAddresses
from #72112
|
|
@carlossanlop tests are failing in the PR because they assert on MajorVersion being 7 instead of 8. Can you please take care of updating the tests and remove such assumptions so that this won't fail against when we brand to NET 9 next year? |
|
Currently looking into this. |
...es/System.Runtime.Serialization.Xml/tests/XsdDataContractExporterTests/ExporterTypesTests.cs
Outdated
Show resolved
Hide resolved
|
The System.Resources.Extensions failure is more complicated. It seems it is not retrieving the version info in plain text, so I'll have to investigate further. |
|
Ah, the tests csproj says I should execute this target from console: The problem is that if I bump the version number of the command to 8, I get this error: And I checked, and that net8.0-windows folder does not exist. I did build the whole repo, and I'm using the branch of this PR. So what's missing? How do I ensure the artifacts of the test project get automatically generated in the folder |
Bumping the target framework from net7.0 to net8.0 is tracked in #72112. You will want to find a solution without depending on the project already targeting net8.0. |
|
I hardcoded This is because the Tests.csproj has this... uh... dependency?.. on the Target: <Target Name="GenerateTestResourcesFile">
<PropertyGroup>
<_executor>Microsoft.DotNet.RemoteExecutor.dll</_executor>I tried searching for other places in the whole repo where we mention D:\runtime2\artifacts\bin\System.Resources.Extensions.Tests\Debug\net7.0-unix\System.Resources.Extensions.Tests.deps.json I'll try searching without the dll extension, in csproj files only, see what I can find. |
|
That error number in the output was not helpful, so I executed the command manually, and I think the problem is that the executor DLL is not being found: Now I'm trying to figure out how to get the full path for the remote executor. The only thing I can find so far in other test projects is that they have |
|
Making progress... Found the location of the executor, so I hardcoded it in the csproj. Now the command complains that the json is not found: I decided to hardcode all those embedded paths to keep using the I ran all the tests locally and they passed when consuming the new resources file: |
|
If the CI passes, I'd like to get this merged to unblock whoever depends on these changes, and I'll open an issue to separately fix the Tests.csproj so we don't have to go through this again. It will need a deeper investigation, because I don't know how to address it yet. |
|
I see new failures caused by this PR. I'm investigating: Affected queues:
Affected tests:
Relevant callstack: |
|
@carlossanlop kindly asking if you can share an update on the remaining test failures? Did you find the root cause for the above mentioned issue? |
carlossanlop
force-pushed
the
Net8Changes
branch
from
9ce9e1d
to
e6216ae
Compare
|
The build failure is reporting CP004, which is likely from The default The If the assembly is already /cc @ViktorHofer |
...raries/System.Runtime.Serialization.Xml/tests/XsdDataContractExporterTests/SurrogateTests.cs
Outdated
Show resolved
Hide resolved
- 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.
.. for runtime tests since the paths are set explicitly in the project
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.
…into Net8Changes
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
The remaining wasm failures in |
|
The wasm/nodejs failures are #77631 . |
|
@carlossanlop this is good to go from my pov. |
|
Thank you so much, @radical for your help with this. The rest of the non-wasm failures are also unrelated. |
carlossanlop
requested review from
lewing,
steveisok,
ViktorHofer and
ericstj
This has dotnet/runtime#74157, which is needed to use compiled-against-8.0 tasks.
ghost
locked as resolved and limited conversation to collaborators
Addresses
from #72112