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.

Sign up for GitHub

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

Jump to bottom

UseSymboliclinksIfPossible for local resources leads to unresolved path in out dir #3730

Open
vaboca opened this issue Sep 11, 2018 · 4 comments · May be fixed by #8251
Open

UseSymboliclinksIfPossible for local resources leads to unresolved path in out dir #3730

vaboca opened this issue Sep 11, 2018 · 4 comments · May be fixed by #8251
Assignees
@manfred-brands
Labels
symlink triaged

Comments

@vaboca
Copy link

vaboca commented Sep 11, 2018 •
edited
Loading

Steps to reproduce

I have activated all the available flags to use symbolic links (CreateSymbolicLinksForAdditionalFilesIfPossible, CreateSymbolicLinksForCopyFilesToOutputDirectoryIfPossible, CreateSymbolicLinksForCopyAdditionalFilesIfPossible, CreateSymbolicLinksForCopyLocalIfPossible, CreateSymbolicLinksForPublishFilesIfPossible) and I have discovered a general behavior that might be unexpected for all the local project resources.

_CopyAppConfigFile
Creating symbolic link to copy "App.config" to "X:\REPO\out\retail-amd64\Project\Project.exe.config".

Doing dir X:\REPO\out\retail-amd64\Project\Project.exe.config, this will point to relative [App.config] instead of the full path of App.config.

Another example is:

CopyFilesToOutputDirectory:
Creating symbolic link to copy "obj\amd64\Project.dll" to "X:\REPO\out\retail-amd64\Project\Project.dll".

Doing dir X:\REPO\out\retail-amd64\Project\Project.dll, the target is [obj\amd64\Project.dll] which is relative path.

Seems that the general behavior is converting a copy command from:
Copy relativeLocalFile x:\target\path\dstFile
Into
Mklink x:\target\path\dstFile relativeLocalFile

Maybe we want for links to use ?
Mklink x:\target\path\dstFile y:\full\path\relativeLocalFile

Potential fix:
I have tested patching Microsoft.Common.CurrentVersion.targets in all the targets, tasks to use the meta %(FullPath) and it's working ok, I don't see any side effect.

<Copy  SourceFiles="@(IntermediateAssembly->'%(FullPath)')"...

Environment data

Version 15.7.177.53362

Thanks,
Daniel
@manfred-brands
Copy link
Contributor

3.5 years later, this is still broken in dotnet 6.0.201.

@manfred-brands
Copy link
Contributor

Can you assign this to me, I will fix it.

@manfred-brands manfred-brands mentioned this issue Dec 16, 2022
Merged
@rainersigwald
Copy link
Member

@manfred-brands Assigned to you.

I have tested patching Microsoft.Common.CurrentVersion.targets in all the targets, tasks to use the meta %(FullPath) and it's working ok, I don't see any side effect.

A theoretical downside to this: it makes the result machine-specific, so if you copied the result to another machine in a different path (or changed a drive letter), the symlink would be invalid even if you had copies of both the link and its destination.

Computing and using a relative path inside Copy would be more robust to that case, but less robust to the case "I copied stuff out of the bin folder and tried to use it" on a single machine, which isn't ideal.

@manfred-brands did you have a plan for the details on this?

@manfred-brands
Copy link
Contributor

manfred-brands commented Dec 18, 2022 •
edited
Loading

I prefer to fix it in the NativeMethods.MakeSymbolicLink instead. That will fix it for all other possible cases this is called.
Using newFileName = Path.GetRelativePath(Path.GetDirectoryName(newFileName), existingFileName);

Symbolic links always have the risk of breaking and are machine/user specific by nature as the NuGet cache is user specific.
The main reason we need to use symbolic links is because the source and nuget cache are on different drives and copying adds significant time to the build.
Now that #8211 is merged, I expect it to use hard-links for these relative paths as they are on the same drive.

@manfred-brands manfred-brands linked a pull request Dec 18, 2022 that will close this issue
Open
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@manfred-brands manfred-brands

Labels
symlink triaged
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Create proper relative symbolic links manfred-brands/msbuild
5 participants
@rainersigwald @vaboca @manfred-brands @AR-May @f-alizada