Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MRTCore will also lookup parent folder #554

Merged
merged 2 commits into from
Mar 11, 2021
Merged

Conversation

huichen123
Copy link
Contributor

When file path is not provided (default or only filename), MRTCore will also lookup current module path as well as the parent folder for the resource file. This is to accommodate Visual Studio which usually creates EXE in a subfolder with project name unless the project has TargetPlatformIdentifier set to UAP.

@ghost ghost added the needs-triage label Mar 11, 2021

*filePath = outputPath.release();
*filePath = finalPath.release();

return S_OK;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we have the fallback impl be in a separate function that we call if filePath is empty after the existing code runs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not quite sure what you mean. but this has least code churn.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing code looks in the current module path, right? We're adding looking in the parent folder too. I'm saying having the addition, i.e., looking in the parent folder, be in a separate function. That way if we want to remove it in the future, for example, it is much easier. It also makes the code more self-explanatory.


In reply to: 591992825 [](ancestors = 591992825)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then the second function will be similar to the first one. People will ask why you cannot abstract the logic. Plus, a few more places need to be updated. Similar logic of lookup/check existence/lookup again will also need to apply to multiple places. If you want to prepare for possible future removal, this is probably the easiest.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, this is fine with me


In reply to: 591996471 [](ancestors = 591996471)

RETURN_IF_NULL_ALLOC(rawOutputPath);
if (i == 0)
{
// If none of the file exists, will return the file in current path
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will return the file in current path [](start = 43, length = 36)

But if the file exists in the current path, we won't even get here. We will break above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is when the file doesn't exist in either location, we will return the file path in current folder.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but if we're here, the file doesn't exist in the current folder, no?


In reply to: 591996835 [](ancestors = 591996835)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct. this function returns a filename. If the file doesn't exist, it will still return you a name. There is no point to fail.

Copy link
Contributor

@rohanp-msft rohanp-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

Copy link
Contributor

@riverar riverar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That path manipulation code is a bit scary at glance, would like to see another PR at some point replace it with std::experimental::filesystem::path. But sounds like minimal churn was your goal for now.

RETURN_IF_FAILED(StringCchCopyW(outputPath.get(), length, pointerToPath));
RETURN_IF_FAILED(StringCchCatW(outputPath.get(), length, filename));

if (GetFileAttributes(outputPath.get()) != INVALID_FILE_ATTRIBUTES)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will also succeed if a directory, not a file, with the same name exists. Might want to explicitly test for and exclude items with FILE_ATTRIBUTE_DIRECTORY.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. There is little time before release. Also this is no throwing code, and this doesn't use std.
I was debating whether exclude directory or make code simple. The chance you have a folder called resources.pri is extremely slim. I can make that check if you insist.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha! I'm an external so can't insist anything. Agree the risk is low, we can create an issue to track it and move forward.

@huichen123 huichen123 merged commit d177c8b into main Mar 11, 2021
@huichen123 huichen123 deleted the user/huichen/checkparentpath branch March 11, 2021 02:09
huichen123 added a commit that referenced this pull request Mar 11, 2021
huichen123 added a commit that referenced this pull request Mar 12, 2021
kythant added a commit that referenced this pull request Apr 23, 2021
Note from Will: May not actually include all these changes in the same form anymore. 

* Update framework udk (#511)

* Cherry pick VSIX into 0.5 preview release branch (#517)

* Update roadmap (unpackaged apps to 0.8) (#506)

* Update roadmap (unpackaged apps to 0.8)

* Include a subscribe option

* Port VS changes in Microsoft.AppxPackage.targets to Microsoft.ApplicationModel.Resources.PriGen.targets: reduce messages printed to output to improve performance. (#485)

* Initial checkin of Reunion VSIX, ported from WinUI3 (#496)

* Initial checkin of Reunion VSIX, ported from WinUI VSIX sources

* update nupkgs and fix wap appx references

* added missing pubxml files

* path bug, reunion tags

* cruft, pubxml

* remove Microsoft.WinUI.AppX.targets

* remove asset dupes

* PR feedback on appx manifests

* replace nuget.config with RestoreSources to support pipeline, fix bad vstemplate

* updated readmes

* Initial checkin of Reunion VSIX, ported from WinUI3 (#496)

* Initial checkin of Reunion VSIX, ported from WinUI VSIX sources

* update nupkgs and fix wap appx references

* added missing pubxml files

* path bug, reunion tags

* cruft, pubxml

* remove Microsoft.WinUI.AppX.targets

* remove asset dupes

* PR feedback on appx manifests

* replace nuget.config with RestoreSources to support pipeline, fix bad vstemplate

* updated readmes

Co-authored-by: Andrew Leader <aleader@microsoft.com>
Co-authored-by: Rohan Palaniappan <35987549+rohanp-msft@users.noreply.github.com>

* Tweaks for Reunion 0.5 Preview release (#524) (#525)

* candidate versions of 0.5 preview nupkgs

* update to latest nupkgs

* another update and template fix

* Cherry pick commit 8f2e841: Revert naming of win32 apps' PRI to the project name. (#529)

* address build/restore issues causing vsix pipeline failures (#530)

* Cherry pick: create VSIX pipeline (#509)  (#537)

* User/ertorres/create vsix (#509)

* remove nuget org feed

* remove vssdk overhead

* always use internal feed (#547)

* Search parent folder (#554) (#569)

* simplify wap project templates to enable PackageReferences upgrades, ensure that ad hoc PackageReferences work for wapproj (#578)

* Bump transport package version to 0.5 (#576) (#581)

* GA tweaks - VS 16.9 prereq, WinUI 3 rename, remove UWP templates, Suspending event (#591)

* GA tweaks - VS 16.9 prereq, WinUI 3 rename, UWP templates unsupported

* remove UWP templates - not supported in release

* remove experimental Suspending event

* Update FrameworkUDK release (#614)

* Remove unnecessary Pkg* defines and avoid bad vsix builds when nuget restore fails (still investigating those) (#631)

* Duplicate MSBuildProjectExtensionsPath was causing inconsistent nuget restore and broken vsix builds (#640)

* fixing regression from earlier VSIX MSbuild change that moved published file (#643)

Co-authored-by: Ben Kuhn <benkuhn@ntdev.microsoft.com>

* drop preview tag (#646)

Co-authored-by: Ben Kuhn <benkuhn@ntdev.microsoft.com>

* User/benkuhn/add vsix patch option (#654)

* adding VSIX version override support

* formatting fix

* non-empty default value

* updating how versions are handled in build script

* trying again

* trying again

* trying again

* debugging

* variable reference fix

* simpler version

Co-authored-by: Ben Kuhn <benkuhn@ntdev.microsoft.com>

* Set SDKVersion (#674) (#684)

* Move MrtCore up to cswinrt 1.2 to keep in sync with WinUI which is doing likewise to pick up memory leak fixes (#685)

* Switch to Open Helix Queues (#665) (#706)

Co-authored-by: Keith Mahoney <41657372+kmahone@users.noreply.github.com>

* Update MRTCore to .net 5.0.3 (#703) (#705)

* Update MRTCore to .net 5.0.3 (#703)

* Update MRTCore to .net 5.0.3

* Update runtime version

* Change task display name

* update to cswinrt 1.2.1 and .NET 5.0.5 (#715)

* update to cswinrt 1.2.1 and .NET 5.0.5

* syncing with latest dotnet update changes

* revert framework udk versions

* update SDK.NET.Ref to 16

* update CsWinRT to 1.2.2

Co-authored-by: Scott Jones <sjones@microsoft.com>
Co-authored-by: Andrew Leader <aleader@microsoft.com>
Co-authored-by: Rohan Palaniappan <35987549+rohanp-msft@users.noreply.github.com>
Co-authored-by: Erik Torres <erik.torres.aguilar@gmail.com>
Co-authored-by: Hui Chen <huichen@microsoft.com>
Co-authored-by: Ben Kuhn <bjk4929@yahoo.com>
Co-authored-by: Ben Kuhn <benkuhn@ntdev.microsoft.com>
Co-authored-by: Keith Mahoney <41657372+kmahone@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants