-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Re-enable functional tests on full .NET Framework #5873
Comments
This might be a misdirection but… All machines where tests fail have System.Collections.Immutable in the GAC; it isn't in the GAC where the tests succeed. For example, everything worked on my laptop 'til I did a couple of VS installations today. Even then, tests worked before I rebuilt the Mvc repo. My registry now contains the following. From the installation logs, VS 2017 added this. Not sure why the GAC addition didn't happen in earlier installations of that product.
|
- thanx to @NTaylorMullen for initial conversion - e.g. AssemblyInfo.cs files were already minimized or removed :) - allow `>=` RC3 CLI's to build and run MVC - work around several dotnet migration issues; see #5482 - disable full .NET Framework runs of functional tests; see #5873 - remove `Microsoft.DotNet.InternalAbstractions` and `System.Xml.XmlDocument` dependencies - remove project.json (!!), *.xproj, .notest, and web.config files Redo earlier changes: - apply test migration to .NET 4.5.2 in *.csproj world - see 63507c8 for previous, project.json work - apply dependency version downgrade from 0097e40 in *.csproj world Make other test-related changes: - make Microsoft.AspNetCore.Mvc.TestDiagnosticListener a regular class library - add support for `/p:GenerateBaselines=true` for functional and Razor.Host tests - separate `GetCSharpTypeName_ReturnsCorrectTypeNames_ForOutParameter()` test - work around inability to deserialize a odd `ref` type - xUnit and vstest now serialize / deserialze test data more often - skip poor test mentioned in #5768 - work around microsoft/vstest#392 - rename tests to avoid duplicates - work around microsoft/vstest#419 - set up created `AppDomain`s with current `ApplicationBase`
Doing some initial work on this since I've been debugging it already. Will turn issue over if I run out of ideas or reach the end of the day w/o getting a repro to share with potential culprits. |
- #5873 - creating an EXE for the test project seems to work around #5873 - also avoids dotnet/sdk#926 when building in Visual Studio nit: clean up duplicate test data
When testing a more limited repro that I can run completely within VS, the test gets further and instead fails with the following. Note the test hits the
Fusion log from Visual Studio
The mentioned copy of The <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Reflection.Metadata" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.4.1.0" newVersion="1.4.1.0" />
</dependentAssembly>
</assemblyBinding>
|
This problem is a variant of microsoft/vstest#428. Main oddity is binding redirects are not needed unless System.Collections.Immutable.dll is in the GAC. Smaller repohttps://github.com/dougbu/XunitTestImmutable Includes a test that hits a <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType> (Note tests in that repro succeed. Need to back up one commit to observe the issue because the above lines are in the project file.) DetailsThe copy of Microsoft.CodeAnalysis.CSharp.dll (v1.3.0) in the NuGetPackages cache depends on <dependency id="System.Collections.Immutable" version="1.1.37" />
<dependency id="System.Reflection.Metadata" version="1.2.0" /> Everything is fine as long as nothing depends on a newer copy of either assembly because the GAC contains System.Collections.Immutable.dll v1.1.37. As soon as something depends on a newer copy e.g. v1.3.1 (also in the cache), the test needs binding redirects and those aren't added automatically. Failures also start when something depends on a newer copy of System.Reflection.Metadata.dll e.g. v1.4.1 because that depends on System.Collections.Immutable.dll v1.3.0. |
- use specific workaround for microsoft/vstest#428 - generating an executable for a test project is a bit too weird - also work around dotnet/sdk#926 - generating an executable covered this as well nit: add and update comments about other workarounds in the functional tests project
- use specific workaround for microsoft/vstest#428 - generating an executable for a test project is a bit too weird - also work around dotnet/sdk#926 - generating an executable covered this as well nit: add and update comments about other workarounds in the functional tests project
Improved workaround with 5c96a7c. Will track removing this workaround (once microsoft/vstest#428 is fixed or worked around elsewhere) with other bullets in #5482. |
These tests fail on AppVeyor and some (but not all) other Windows machines. See https://ci.appveyor.com/project/aspnetci/mvc/build/1.0.8116 for example.
Innermost stack trace is always some variant of
The text was updated successfully, but these errors were encountered: