Test Save_SimpleSettings_Ok failing #28833
Labels
Projects
Milestone
Comments
maryamariyan
changed the title
ViktorHofer
changed the title
|
Failed again, this time on Windows 7: https://dev.azure.com/dnceng/public/_build/results?buildId=358032&view=ms.vss-test-web.build-test-results-tab&runId=10839480&resultId=105888&paneView=debug Configuration: |
|
Failed on Windows7 and Windows8.1 with perhaps a new kind of error. |
|
This is always failing trying to find I'm working on adding more logging here and changing the re-throw to retain context. |
|
The assembly qualified name gets serialized in the user settings, which is placed in a location that is based off of the executing assembly name and the location of the assembly. This file is persisted in the app data directory and thus will persist across test runs. What likely happened is that a run with 4.0.3.0 was followed by a run with a lower version number (the one that failed). The type requests will normally roll forward to newer versions, but never backwards to older ones. If we find rolling forward to be a customer problem we could consider redirecting our type requests for In the immediate we need to re-enable the test. I'm going to try and:
I'll also look to see what other user settings gaps we currently have. I've done some manual testing (in the context of a Windows Forms app) and things seem to be in good shape. cc: @maryamariyan; @ericstj |
|
Do we need to support cross-targeting betweek desktop and core here? Would it make sense to write the desktop identity? We've done this elsewhere, either explicitly, or by reading the TypeForwardedFrom attribute. |
I don't think so as user settings are app location specific. I don't see a scenario where you would swap .NET Core and .NET Framework apps in the same physical location. |
|
There are actually two issues here. It fails consistently on Unix. Here is the current stack: The first thing I would look at is if the app data folder exists and there are appropriate rights. |
maryamariyan
added
the
untriaged
|
Was going to move this out but I don't have enough context. |
|
Not seeing a regression here. It'd be nice to fix this but I don't see that meeting the bar for 5.0 and this existed in 3.x as well. |
|
If that helps, I get the same exception on Linux when trying to save/upgrade settings and the "/home/USERNAME/.local/share" directory does not exist. This is the location where configuration file should be stored. Configuration file path is empty, when the parent directory does not exist. It's easy to check its value with this code:
This behavior is confirmed in documentation for Environment.GetFolderPath():
(https://docs.microsoft.com/en-us/dotnet/api/system.environment.getfolderpath?view=net-5.0) I found two possible solutions:
string localAppData = Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData, System.Environment.SpecialFolderOption.Create);In my opinion, the stacktrace from saving application settings gives no clue, that the problem is with non-existing folder. This could be definetely improved. It took couple of days to figure this out and I suppose this is the reason for errors in your unit tests. Stacktrace: |
|
Thank you @trysil for the investigation. Do you have any interest in offering a proposed PR? |
|
Windows 10
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue tracks the Linux failures on
Save_SimpleSettings_Ok, a test that is added in PR dotnet/corefx#28894.The Linux issue may be something weird about how our machines are configured on our CI machines.
Failing on Linux with:
(Taken from comment dotnet/corefx#28894 (comment))
The text was updated successfully, but these errors were encountered: