Eric StJohn
Eric StJohn
Seems like a reasonable feature - maybe we have some items that are honored by default by the GenerateFileFromTemplate task and we also have some properties with values are specified...
@antonfirsov looks like this might be your area. Please have a look.
@steveharter do we know what commit most likely caused this? Another option here would be to temporarily disable this one test to allow this to merge and file a release...
I pulled out the test, ran it on `net7.0` while only changing the `Microsoft.Extensions.DependencyInjection` reference and was able to isolate the failure. `8.0.0-preview.7.23328.1` -> succeeds 1815306c1b325a66189511f3ddecd45638c47681 `8.0.0-preview.7.23328.6` -> fails c06d77a74f64d6c5b0280db56fb0c6a43c0aa907...
I filed the issue and disabled the test.
Seeing failures on mac and linux: ``` [mUnhandled exception. System.TypeLoadException: Could not load type 'System.Runtime.CompilerServices.NullableContextAttribute' from assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. at System.ModuleHandle.ResolveType(QCallModule module, Int32 typeToken, IntPtr* typeInstArgs, Int32 typeInstCount,...
> looks like that was fixed in https://github.com/dotnet/efcore/pull/31270 That didn't fix it -- that might make it fail on Windows too. We need a newer SDK to get the updates...
@bricelam thank you for jumping on this. Your change should fix https://github.com/dotnet/efcore/issues/31300 To double check that we can look at the test logs. We expect them to be running against...
Mac build is failing during build to run the compiler from the SDK - looks to me like it's using the wrong `dotnet`. It's using `/Users/runner/.dotnet/` instead of `/Users/runner/work/1/s/.dotnet`. ```...
I see, so we might need to undo the SDK update (since it's not needed now with @bricelam's changes) or figure out how to fix it.