.NET Core 3 Preview 8 WPF Build error on custom BaseIntermediateOutputPath

[TFTomSun]

• .NET Core Version: 3.0 Preview 8
• Windows version: Windows 10
• Does the bug reproduce also in WPF for .NET Framework 4.8?: No

Problem description:
I set the BaseIntermediateOutputPath to >$(OutputRootDirectory)obj$(Configuration)$(MSBuildProjectName)
where OutputRootDirectory is a shared Output path of many projects
It is set via a build sdk that is included in the Directory.Build.props and Directory.Build.targets files in the root of my repository.

Actual behavior:
When I build the project I get alot of build errors for xaml files, for example:

D:\Git\Collaboration\Net\Framework_out\obj\Debug\Siemens.Collaboration.Net.Presentation\netcoreapp3.0\Controls\AvalonDockApplicationControl.g.cs(54,18,54,62): error CS1504: Source file 'Controls\AvalonDockApplicationControl.xaml' could not be opened -- Could not find file.

It seems like the line information generated in to the g.cs files don't honor the the changed BaseIntermediateOutputPath setting.

Expected behavior:
The build just runs fine

[vatsan-madhavan]

Likely related to or duplicate of #366

[grubioe]

Closing as duplicate of #366

[TFTomSun]

@grubioe I'm not sure whether this is a duplicate. It's more about how the compiler resolves line preprocessor statements with relative paths. For example into one of the generated cs files (AvalonDockApplicationControl.g.cs) in the intermediate ouput is the following line statement generated:

#line 16 "Controls\AvalonDockApplicationControl.xaml"

I don't know how the compiler can find the path to the xaml file, because the xaml file is not relatively located to the base intermediate output in my case. I'm afraid that there's somewhere an assumption that the intermediate output is below the project directory.

I tried to set the property XamlDebuggingInformation to false, but unfortunately it doesn't stop generating the line statements. Any other idea, how i could workaround that issue?

[TFTomSun]

I think I found the issue. The implementation of ParentFolderPath in the MarkupCompiler class of the PresentationBuildTasks assembly seems not to be clean:

Assembly location:

C:\Program Files\dotnet\sdk\3.0.100-preview8-013656\Sdks\Microsoft.NET.Sdk.WindowsDesktop\tools\netcoreapp2.1\PresentationBuildTasks.dll

excerpt of decompiled source code:

private string ParentFolderPrefix
    {
      get
      {
        string empty = string.Empty;
        if (this.TargetPath.StartsWith(this.SourceFileInfo.SourcePath, StringComparison.OrdinalIgnoreCase))
        {
          string[] strArray = (this.TargetPath.Substring(this.SourceFileInfo.SourcePath.Length) + this.SourceFileInfo.RelativeSourceFilePath).Split('\\');
          for (int index = 1; index < strArray.Length; ++index)
            empty += "..\\";
        }
        return empty;
      }
    }


....


 private void AddLinePragma(CodeTypeMember ctm, int lineNumber)
    {
      CodeLinePragma codeLinePragma = new CodeLinePragma(this.ParentFolderPrefix + this.SourceFileInfo.RelativeSourceFilePath + ".xaml", lineNumber);
      ctm.set_LinePragma(codeLinePragma);
    }

    private void AddLinePragma(CodeStatement cs, int lineNumber)
    {
      CodeLinePragma codeLinePragma = new CodeLinePragma(this.ParentFolderPrefix + this.SourceFileInfo.RelativeSourceFilePath + ".xaml", lineNumber);
      cs.set_LinePragma(codeLinePragma);
    }

The ParentFolderPrefix shall build up the project folder to the xaml files to which the line pragma's points to. In my case the targetpath doesn't start with the sourcefileinfo.sourcepath... therefore an empty string is returned, which is probably wrong. Instead a complex relative path or an absolute path to the project directory would have to be generated.

@grubioe please reopen the issue

[wjk]

@TFTomSun Open source is cool! No need to decompile anymore:

wpf/src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks/MS/Internal/MarkupCompiler/MarkupCompiler.cs

Lines 1567 to 1585 in 55815c9

	private string ParentFolderPrefix
	{
	get
	{
	string parentFolderPrefix = string.Empty;
	if (TargetPath.StartsWith(SourceFileInfo.SourcePath, StringComparison.OrdinalIgnoreCase))
	{
	string relPath = TargetPath.Substring(SourceFileInfo.SourcePath.Length);
	relPath += SourceFileInfo.RelativeSourceFilePath;
	string[] dirs = relPath.Split(new Char[] { ESCAPED_BACKSLASH_CHAR });
	for (int i = 1; i < dirs.Length; i++)
	{
	parentFolderPrefix += PARENTFOLDER;
	}
	}
	return parentFolderPrefix;
	}
	}

[TFTomSun]

off topic
@wjk maybe I don't know a technique yet how to browse and search for symbols within the original sources. What I did:

• check what the targets do in the PresentationBuildTasks package and found the task
• opened the assembly with dot peek
• navigated to the task
• drilled down to the methods via navigate to/ find symbols

Is there a similar way to do that based on the original sources? Finding and cloning the whole repository seems to be more complicated for me

[wjk]

@TFTomSun If you know what class name you're looking for, you can go to the homepage for this repo, press the "T" key on your keyboard, and type in the class name into the File Finder page that appears. Since most filenames in this repo share names with the classes they contain, this is usually a good way to find one class from the (admittedly large) repository.

Failing that, the src directory contains all the source code for the entire WPF project, organized in subfolders by assembly, then by namespace. If you're using PowerShell, you can use the following command to find a string out of all the C# source files in the repo:

cd path_to_wpf_repo_clone\src\Microsoft.DotNet.Wpf\src
dir -Recurse . -Include *.cs | sls "your_string_here" -SimpleMatch

Or, if you prefer working on a Linux or Mac box, I would recommend using the ack program instead. All you need to do to use it is type ack some.regex.here, and it will search every file under the current directory for that regex, and print filenames and line numbers for each match it finds -- and it's fast. Hope this helps!

[TFTomSun]

@wjk ok, i thought there might be a more feasible way to navigate the sources... i prefer a symbol based navigation support via decompilation until we can do that via visual code directly online one day.

[weltkante]

@TFTomSun something like reference source but for .NET Core repositories? Roslyn and CoreFX have one for their repository as well. I'm still using the Desktop Reference Source for navigating the sources of WPF and WinForms but they are moving apart quickly, in particular WinForms is doing heavy refactoring. But for WPF it is pretty close so it still works nicely. I've created #1967 and dotnet/winforms#1982 to suggest having online browsable source.

[TFTomSun]

@weltkante yes, that looks promising. I hope something like this will be integrated into github one day, so that you can use it for any project.

I even found the class i mentioned above.
https://referencesource.microsoft.com/#PresentationBuildTasks/BuildTasks/Ms/Internal/MarkupCompiler/MarkupCompiler.cs,8971d8b9b0963d26

Unfortunately I don't see a member list. So the useability still needs to be improved.

[weltkante]

@TFTomSun apparently WinForms and the managed part of WPF are already indexed in https://source.dot.net/

[tmat]

The fix would be to use full paths to xaml files in#line and #checksum directives of .g.cs files.

[epvanhouten]

I ran into this issue while adding packaging to a dotNet Framework based solution. Working around by narrowing who gets the 'EmbedUntrackedSources' property using a targets file.

[ryalanms]

This is fixed in .NET 6.0 and 5.0 with IncludePackageReferencesDuringMarkupCompilation = true.

[KirillOsenkov]

Related: dotnet/sdk#34438