Msbuild: Item Exclude syntax doesn't support '/' as a path separator

[davkean]

1. Create a new Console application
2. Create a new folder called "Exclude", copy Program.cs into it
3. Unload -> Edit
4. Replace the <Compile Include items with <Compile Include="**/*.cs" Exclude="Excluded/**" />
5. Reload project

Expected: For Excluded\Program.cs to not be included in the project
Actual: Excluded\Program.cs is included in the project.

It appears that while '/' is understood in Include, it's not in Exclude. Does this prevent us from writing platform-agnostic paths?

[rainersigwald]

I think we'll automagically correct \ to / when platform-appropriate, but this is definitely a bogus restriction that we should fix.

[davkean]

You'll want to do the other way too anyway, right? What if you start on Linux? It looks like this automatically happens for Include, just not Exclude.

[TheRealPiotrP]

Hitting this in CLI repo as well.

[TheRealPiotrP]

@Sarabeth-Jaffe-Microsoft we need to get this scheduled sooner than later. We're already finding that this bug is causing massive code blowup in CLI builds. We've already defined an internal $(PathSeparator) but even it's usage is not consistent since the paths returned by Include="GLOB" will use a mixture of OS slashes and user-provided slashes from the globbing pattern. In other words, without a fix we basically need to make the literal use of / and \ unsupported.

[eerhardt]

I think we'll automagically correct \ to / when platform-appropriate, but this is definitely a bogus restriction that we should fix.

\ is a valid file/folder name character on Unix. Blindly converting all \ characters on Unix is not correct.

For example, I can have a folder named my\folder by running

$ mkdir my\\folder
$ ls
my\folder

Are we saying that with MSBuild this won't be supported?

[cdmihai]

See #781

MSBuild's code base has a ton of hard-coded file system assumptions all over the place. At some point we'll need to decide whether to a) switch all of them to Unix (making Windows builds fail), b) keep them as they are, or c) find and put them all behind a file system abstraction that's toggleable at runtime

[brthor]

This issue is making it impossible to create an include exclude set on an item using globs that works cross-plat when using any kind of slash:

An example:

<Compile Include="**\*.cs" Exclude="bin\**;obj\**" />
<Compile Include="**\*.cs" Exclude="bin/**;obj/**" />

Neither of these items will include/exclude things correctly on on unix and is currently blocking migration excludes from working properly on OS X.

Is there a workaround for this?

[rainersigwald]

@brthor I would expect the former, with backslashes, to work everywhere. Are you not seeing that?

[brthor]

@rainersigwald I can't seem to get it working with any combination of slashes between the include and exclude.

The one with all backslashes results in an include like:
obj/Debug/netcoreapp1.0/dotnet-compile.assemblyinfo.cs

[rainersigwald]

@brthor Thanks. I repro on my machine as well: I can't get any Exclude to work when the Include has wildcards. That's much worse than I thought, and might be unrelated to the original issue in this thread. Splitting it out into #970.

[cdmihai]

Current roadmap of bug fixes:
1) Migrate the fix for #917 over to the xplat branch. Right now only desktop MSBuild has this fix
2) Fix #931 on master and then port it to xplat
3) Fix this issue: include and exclude should be able to use slashes and back-slashes as path separators

[cdmihai]

I tested this on OSX and it seems to work with the latest xplat build. Probably fixing the other exclude bugs also fixed this :)

Can someone else please confirm? In the meantime I am going to augment tests with forward slashes