Microsoft.WinFx.targets file has an error

[daghb]

The task GenerateTemporaryTargetAssembly uses a deprecated parameter GenerateTemporaryTargetAssemblyDebuggingInformation. This seems to be the case when I am building 32 bits WPF applications. The Framework64 version does not have this error on line 454.

If I manually remove the parameter from the targets file, my build runs OK.

Extra info: The build problem does not emerge on my Desktop computer, only on Windows Server Core with MSBuild. However, the .targets files on Framework and Framework64 are still different.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(454,17): error MSB4064: The "GenerateTemporaryTargetAssemblyDebuggingInformation" parameter is not supported by the "GenerateTemporaryTargetAssembly" task. Verify the parameter exists on the task, and it is a settable public instance property. [MyProject.csproj]
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(444,8): error MSB4063: The "GenerateTemporaryTargetAssembly" task could not be initialized with its input parameters.  [MyProject.csproj]

[rakeshsinghranchi]

@daghb , Thanks for reporting the issue. Can you please send install logs to dotnet-install-help@service.microsoft.com .

Steps to collect install log can be found at http://aka.ms/vscollect.exe . Also, please share repro steps to further diagnose the issue.

[Jo8n]

After reading this a few times:

The GenerateTemporaryTargetAssembly task generates an assembly if at least one Extensible Application Markup Language (XAML) page in a project references a type that is declared locally in that project. The generated assembly is removed after the build process is completed, or if the build process fails.

(source https://docs.microsoft.com/en-us/visualstudio/msbuild/generatetemporarytargetassembly-task?view=vs-2017)

I realized I could get my project to stop needing GenerateTemporaryTargetAssembly by not referring to any types within the same project from the XAML. In the end, this actually required not only removing references to those types but also references to those internal namespaces in the XAML.

While this does work around the problem for one of my 100 or so projects, it will not be possible in most of the other projects so I'd really like to see a better work around or a fix for the .targets file that references GenerateTemporaryTargetAssemblyDebuggingInformation.

[baruchiro]

Hi, I have the same problem when I try to build the project in Windows Server Core Docker. I'm not familiar with UWP, and I need to build this in Docker.

This actually required not only removing references to those types but also references to those internal namespaces in the XAML

@Jo8n what it means? Where is this references? What do they look like?

[thefipster]

Same thing here trying to build a WPF Application in a Docker Build Agent based on Windows Server Core.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(454,17): error MSB4064: The "GenerateTemporaryTargetAssemblyDebuggingInformation" parameter is not supported by the "GenerateTemporaryTargetAssembly" task. Verify the parameter exists on the task, and it is a settable public instance property.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(444,8): error MSB4063: The "GenerateTemporaryTargetAssembly" task could not be initialized with its input parameters.

I will try the Workaround suggested by @Jo8n due to missing alternatives, but it sounds like an ugly fix.

Are there any plans if or when this will be fixed?

[Jo8n]

Hi, I have the same problem when I try to build the project in Windows Server Core Docker. I'm not familiar with UWP, and I need to build this in Docker.

This actually required not only removing references to those types but also references to those internal namespaces in the XAML

@Jo8n what it means? Where is this references? What do they look like?

Hi, Baruch.

Sorry I didn't notice your response earlier. In your XAML files, you may have references like this that refer to the project being built. I think the Designer adds one named "local" by default even if you don't need it. If you can, remove the ones like that that refer to the project being built.

-Jonathan

Example (see "local" below). The work around that worked for me is to remove the ones that reference the project itself. To be practical to solve all my issues, I'd have to move many controls to their own projects in order to make all my projects build without this warning.

<UserControl x:Class="Time.EventControl" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="using:Time" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:Ignorable="d" d:DesignHeight="300" d:DesignWidth="400">

[weltkante]

This prevents me from updating a VS 2015 project to VS 2017. The project used to build just fine.

Sorry, this was a mistake on my side. While making a binlog of the failing build I noticed that the project file had customizations causing it to load PresentationBuildTasks.dll from an unexpected location. Probably not a bug in VS after all. I assume the DLL which gets loaded doesn't match the targets file and thus is causing an error. Sorry for the false alarm.

[Roemer]

I have the same issue now. Also while building a library with xaml code inside a Docker container. Are there any solutions for this yet? So the only workaround I found for now is to effectively replace the the files C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets and C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.WinFx.targets with a version that just removes that parameter on line 454. This happens when having the current version of the Visual Studio 2017 Build tools installed in a Docker Container and building a WPF project.