Comments (7)
Oh that's a very interesting failure mode for this. I'd say it's an MSBuild bug, but it's a hard one to fix, so we might need to figure out how to work around for the SDK.
from msbuild.
I haven't looked at the details of the PR but I am broadly in favor of having a way for items, item types, or tasks to opt out of the path "correction"--since it's heuristic it's caused problems before.
from msbuild.
Thanks for recognizing it as a bug 😄
It's probably an edge case, as almost every property that contains a path should be correct on the build server. However, there might be some others that would make sense to resolve on the target platform as well. Maybe dotnet tools have the same issue? But, I'm not sure.
We'll have to think a bit on how to solve this. I made a first attempt in my fork of the SDK repo at "fixing" it by swapping out the ITaskItem
s with strings, but I don't like the approach, and I haven't been able to get it working either.
Do you have suggestions on the best way of fixing this? Is there anywhere in the build pipeline we can decide which implementation of ITaskItem
that gets instantiated? I tried looking at the constructor that takes metadata, and pondered upon whether we could use a metadata item to tell the TaskItem to not normalise the paths, or normalise to a specific platform, but I couldn't finish the thought. Are there other contructs than a TaskItem that would make sense to use for path properties where we don't want the path "fixing"?
from msbuild.
One possible hacky option: renormalize inside the task, which should know the target OS's preferred slash direction :-/
Is there anywhere in the build pipeline we can decide which implementation of
ITaskItem
that gets instantiated? I tried looking at the constructor that takes metadata, and pondered upon whether we could use a metadata item to tell the TaskItem to not normalise the paths, or normalise to a specific platform, but I couldn't finish the thought.
This sounds directionally correct to me, but I'm afraid I haven't been in that portion of the code for a while and don't remember offhand where there might be some good hooks to change things. Another possible option would be an attribute on the ITaskItem
-taking input of the task that tells the engine to avoid normalization (somehow!).
Are there other contructs than a TaskItem that would make sense to use for path properties where we don't want the path "fixing"?
string
is all I can think of too.
from msbuild.
@baronfel Can you take a look at this issue? @rokonec and I looked at it, and we would rather to implement a work-around in Microsoft.NET.Build.Containers.Tasks.CreateNewImage task for this.
from msbuild.
I want to keep this open and see if it bites more people - It feels like the kind of thing that could be handled on a Task-by-Task basis, perhaps with an annotation on the Task's Input itself?
from msbuild.
I think keeping this one open is a good idea. I'm not sure whether the "build for an OS that has a different directory separator char than the one you are building on, AND, having to resolve paths at build-time, that are to be used runtime" is a very, very corner-case (only applicable to container builds), or if it's a broader issue.
That said, having worked a bit more on the PR, I'm not so much a fan of my own suggestion to solve the problem. It got a bit ugly, since the evaluated (already path-replaced) string is stored on the TaskItem
in so many different code paths. Of course, one might change to doing this replacement on read, but I'm not aware of potential performance issues with this. I guess there is a reason why it's stored on write, already with the paths "fixed".
Additionally, there are many implementations of the ITaskItem
in the MsBuild source code. So one needs to think about whether solving it specifically for TaskItem
will solve the end-problem, or if it needs to be fixed in multiple places, maybe the whole path transformation logic should be moved to a separate, explicit place (if feasible).
I fear "fixing" this in the TaskItem
, as well as being rather high-risk, as the TaskItem
is used as a very core citizen of MsBuild, and probably has thousands of usages out in the wild, will not fix the problem either, as there are very many places the paths are fixed elsewhere too (on the Solution, ProjectItem, etc).
One possible way is, of course, to just go all the way, and accept that Windows works well with forward-slash paths, and has done for decades, but I think people will feel this is obtrusive.
Sorry, just a lot of loose, random thoughts here, but I think the "idea bubbling phase" is important here, both to hammer out:
- Whether this use case is a corner case or a core case
- How one wants to solve this long-term
In my head, the short-term solution to choose, is depending on the answers to the questions above too.
from msbuild.
Related Issues (20)
- [Bug]: dotnet restore throws error NU1202 with dotnet sdk 8.0.300 for some centrally managed packages HOT 2
- [Feature Request]: Expand $(~) to $(HOME) or $(USERPROFILE) depending on OS HOT 4
- Got 'Insufficient system resources exist to complete the requested service' while building Store version of application
- [Feature Request]: Cache RoslynCodeTaskFactory compilations for the lifetime of the Server
- [Bug]: Cannot use Microsoft.Build.Utilities.Core 17.10.4 NuGet package HOT 4
- Correct way to generate sources for an external project (with incompatible `TargetFramework`)?
- [Feature Request]: Localize MSBuild messages with MSBuildInternalMessage task
- [Bug]: BuildCheck: Internal error thrown when reporting results HOT 1
- [Broken Build]: Blazor Integrity issue HOT 1
- [Bug]: NRE in at Microsoft.Build.BackEnd.TargetEntry.<ExecuteTarget>d__44.MoveNext() HOT 4
- Request to backport getResultOutputFile from 8.0.3xx to 8.0.1xx SDK. HOT 3
- [Bug]: CI/CD pipeline broken after update from 17.9 to 17.10: no Appx packages generated HOT 2
- [Bug]: OOM Exception due to infinite loop in FileMatcher HOT 2
- [Feature Request]: The way publish dll only HOT 7
- [Refactoring] Move all Xml*WithLocation to Microsoft.Build.Framework
- [Feature Request]: Reduce the wrapping around SDK Resolver messages when only one resolver is actually invoked HOT 1
- Analyzer for Property read before assigned HOT 2
- [Bug]: Incorrect framework library is used sometimes during build HOT 1
- Q: Verifying NuGet single multi targeting build assets importation HOT 25
- [Bug]: Project file does not exist with LongPaths HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from msbuild.