License header?

There's no License header for any of the test assets in https://github.com/dotnet/runtime/tree/master/src/installer/test/Assets/TestProjects

So, I kept the same pattern.

Can you please fix that in a followup PR? Or at least create an issue for it.

OK I'll fix it for all the projects in a subsequent PR.

CloseHandle above may alter GetLastError. If that happens, the last error in the log will be bogus.

Do you also need to close map handle before the function returns?

There is no API to close a File Mapping. The UnMapViewOfFile documentation says:
"Although an application may close the file handle used to create a file mapping object, the system holds the corresponding file open until the last view of the file is unmapped. Files for which the last view has not yet been unmapped are held open with no sharing restrictions."

CreateFileMapping documentation says:
"Mapped views of a file mapping object maintain internal references to the object, and a file mapping object does not close until all references to it are released. Therefore, to fully close a file mapping object, an application must unmap all mapped views of the file mapping object by calling UnmapViewOfFile and close the file mapping object handle by calling CloseHandle. These functions can be called in any order."

Therefore, I think map handle cannot be closed; the sharing violation was because of the FileHandle.

The documentation you have quoted says that you should close the map handle using CloseHandle.

You should close it even if it does not cause any obvious problem like sharing violation. It is good practice to avoid leaking resources.

Thanks @jkotas. I misunderstood the text to mean that the mapping handle is automatically closed after all the references are unmapped. I've fixed it now.

Nitpick, but this could be written as:

if (address == nullptr)
{
    trace::warning(...);
}

// ...
CloseHandle(file);
CloseHandle(map);

return address;

(Slightly shorter code.)

Nitpick: do we need string interpolation here? (Nevermind. This is just for testing, so it's OK.)

Nit: It would make more sense to swap the order - we first open the file and then create the mapping, so closing them should be done in reverse order. Thus close the mapping first and then close the file. (I know it doesn't matter as the OS will do the right thing in both cases anyway).

Can you please fix that in a followup PR? Or at least create an issue for it.

Do we really need a separate function for this if all it is calling is GetHostPath?

I do think it is useful to have the wrapper call. In the single-file tests, we generate single-file apps in two ways:

• Through the SDK (dotnet publish /p:PublishSingleFile=true)
• Through invoking HostModel functions directly.

In the former case GetHostPath() will be the pre-bundled app, whereas in the later case, GetHostPath() will just be the host. So, I think it is easier to refer to them by different names.
Helps documenting the intent, and in searching for the use with different semantics.

Ahh, okay. I didn't realize the different use cases and just assumed the paths in BundleHelper were for the pre-bundled app.