Migration: Content include directory hierarchy is not preserved

[livarcocc]

From @jgoshi on November 15, 2016 18:25

For a project.json file that has this:
"copyToOutput": {
"include": [
"../../TestAssets/TestProjects/AppWithToolDependency/**/",
"../../artifacts//stage2/sdk//.version"
],
"mappings": {
".version": "../../artifacts//stage2/sdk/*/.version"
}
}

AppWithToolDependency was copied to the output directory preserving the directory hierarchy from TestAssets, while .version was copied flag to the the output directory (not preserving the directory hierarchy). There seems to be a different behavior either because of the "mappings" entry, or because of the "**" path. We need to figure out the project.json algorithm and mimic this for csproj.

For csproj files, migration currently does this.
<Content Include="....\TestAssets\TestProjects\AppWithToolDependency**">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</Content>
<Content Include"../../artifacts//stage2/sdk/*/.version">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</Content>

Which copies the files flat (not preserving directory hierarchy). To preserve the hierarchy you can add the <Link> tag like this:
<Link>TestAssets/TestProjects/AppWithToolDependency/%(RecursiveDir)%(Filename)%(Extension)</Link>

The SDK cannot change behavior because they would break existing projects. But migration should insert the <Link> tags where necessary so we maintain the same behavior as project.json.

Copied from original issue: dotnet/cli#4724

[livarcocc]

From @jgoshi on November 15, 2016 21:8

I'm attaching sample projects.

1. TestContentPJ - Sample project.json based project
2. TestContentMsbuild - Migrated project
3. TestAppWithManualFixes.csproj - File that contains the manually added link tags that migration should add.

Sample.zip

Here is the observed project.json behavior:

1. Anything with a mapping entry specifies the (user-specified) output path. Note that migration already handles this part.
2. Anything without a mapping entry preserves directory hierarchy. Migration needs to add link tags and also needs to exclude files that have an explicit mapping entry. See TestAppWithManualFixes.csproj for more details.

[livarcocc]

From @jgoshi on January 30, 2017 23:16

Looking at this more, I don't think we should fix this. The mappings in project.json all the user to specify directory hierarchy. The implicit stuff seems like it would be a big fix. For example, given this project.json.

"copyToOutput": {
"include": [
"testcontentfile.txt",
"../Content/SubDir1/SubDir2/testcontentfile.txt",
"../Content/SubDir1/testcontentfile.txt",
"../Content/SubDir2/testcontentfile.txt",
"../Content/SubDir3//*",
"../Content/SubDir4//*",
"../Content/SubDir5//testcontentfile.txt"
],
"mappings": {
"dir/testcontentfile.txt": {
"include": "../Content/SubDir4//testcontentfile.txt"
},
"renamed.txt": "../Content/SubDir5/**/testcontentfile.txt"
}
}

We produce this:
<Content Include="..\Content\SubDir4*\testcontentfile.txt">
<Link>dir/testcontentfile.txt</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
<Content Include="..\Content\SubDir5*\testcontentfile.txt">
<Link>renamed.txt</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
<Content Include="testcontentfile.txt;..\Content\SubDir1\SubDir2\testcontentfile.txt;..\Content\SubDir1\testcontentfile.txt;..\Content\SubDir2\testcontentfile.txt;..\Content\SubDir3**;..\Content\SubDir4**">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>

We would have to break up the last Content Include into multiple Content elements each with their own Link element. And project.json maps ..\Content to Content in the output directory. I guess I could specifically look for ..\ at the beginning of a path, but this seems risky.

@piotrpMSFT @livarcocc What do you think?

[livarcocc]

I always thought this was too risky. Let's not take it, specially now.

[livarcocc]

From @jgoshi on January 31, 2017 17:48

Ok, I'll move this out to 2.0.