[Windows]Fix NullReferenceException in OpenReadAsync for FileResult created with full path

[devanathan-vaithiyanathan]

Issue details

Calling OpenReadAsync() on a FileResult constructed using the full path constructor throws a NullReferenceException with the message: "Value cannot be null. (Parameter 'windowsRuntimeFile')". This occurs because the internal File property is null when a full path is provided.

Description of Change

The changes fix the Exception in OpenReadAsync() by properly initializing the File property when a FileResult is created with a full path.

Issues Fixed

Fixes #26858

Tested the behavior in the following platforms.

• Android
• Windows
• iOS
• Mac

Before	After
Windows	Windows

[MartyIX]

This caught my attention. Should this be:

Suggested change

	_ = await stream.ReadAsync(bytes, 0, (int)stream.Length);
	Assert.True(bytes.Length > 0);
	var count = await stream.ReadAsync(bytes, 0, (int)stream.Length);
	Assert.True(count > 0);

?

bytes.Lenght is always >0, or not?

(I did not open the PR in my IDE. Sorry, if I'm confusing things.)

[devanathan-vaithiyanathan]

@MartyIX, I’ve removed the assert that check bytes.Length and completed the test using Assert.NotNull(stream)

[MartyIX]

L55 (using var stream = await fileResult.OpenReadAsync();) is still using the file..?

[devanathan-vaithiyanathan]

@MartyIX,
It is using FileResult, not the file directly. The OpenReadAsync() method returns a stream from the FileResult

[MartyIX]

I don't know this API in depth. It's just I find it weird that you seem to operate on a file and delete it before the stream is disposed.

I would expect:

using (var stream = await fileResult.OpenReadAsync())
{
  Assert.NotNull(stream);
}

File.Delete(filePath);

I find it safer. But I might be very well wrong, so feel free to ignore this suggestion.

edit: Ah, I see what you are saying.

[robitsrl]

Hello,
does now the FileResult is able to load the file correctly ? i'm in maui net 8
Thank's

[devanathan-vaithiyanathan]

@robitsrl , Yes, in .NET 8, FileResult is able to load the file correctly when creating a new FileResult using an existing FileResult.

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

/rebase

[jsuarezruiz]

@devanathan-vaithiyanathan Could you rebase and fix the conflict?

[devanathan-vaithiyanathan]

@devanathan-vaithiyanathan Could you rebase and fix the conflict?

@jsuarezruiz , I’ve rebased the branch and resolved the conflicts.

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

Could add a test that calls OpenReadAsync twice to validate it? Ensures the second call does not regress and that the StorageFile remains usable across multiple streams.

[devanathan-vaithiyanathan]

@jsuarezruiz , Based on suggestion, I've modified the test

[Copilot]

Pull Request Overview

This PR fixes an issue where FileResult.OpenReadAsync() fails on UWP when a FileResult is created with only a file path (without a StorageFile object). The fix enables the UWP implementation to lazily load the StorageFile from the path when needed.

• Added lazy StorageFile initialization in UWP's PlatformOpenReadAsync method
• Added tests to verify FileResult works with file paths and supports multiple stream openings

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/Essentials/src/FileSystem/FileSystem.uwp.cs	Updated PlatformOpenReadAsync to lazily initialize StorageFile from FullPath when File is null
src/Essentials/test/DeviceTests/Tests/FileSystem_Tests.cs	Added two new tests to verify FileResult works with file paths and supports multiple OpenReadAsync calls

[Copilot]

The file cleanup could fail if an exception occurs during the test. Consider wrapping the test logic in a try-finally block or moving the cleanup to a finally block to ensure the test file is deleted even if assertions fail.

Suggested change

	var fileResult = new FileResult(filePath);
	using var stream = await fileResult.OpenReadAsync();
	Assert.NotNull(stream);
	File.Delete(filePath);
	try
	{
	var fileResult = new FileResult(filePath);
	using var stream = await fileResult.OpenReadAsync();
	Assert.NotNull(stream);
	}
	finally
	{
	File.Delete(filePath);
	}

[Copilot]

The file cleanup could fail if an exception occurs during the test. Consider wrapping the test logic in a try-finally block or moving the cleanup to a finally block to ensure the test file is deleted even if assertions fail.

[PureWeen]

Merge conflict

[devanathan-vaithiyanathan]

Merge conflict

@PureWeen , I've resolved the merge conflicts

Merge conflicts have been resolved by the author

[StephaneDelcroix]

LGTM! The fix correctly handles the case where a FileResult is created with just a path by lazily loading the StorageFile when needed. The tests cover both single and multiple OpenReadAsync calls. The CI failures appear to be unrelated flaky tests (Layout, WebView).

The base branch was changed.