dotnet / project-system

The .NET Project System for Visual Studio
MIT License
968 stars 386 forks source link

Projects with workflow XAML do not compile #5252

Open DzonnyDZ opened 5 years ago

DzonnyDZ commented 5 years ago

Visual Studio Version: 16.2.0

Summary: Compiling project with XAML Service references fails with The target "CoreCompile" does not exist in the project.

Steps to Reproduce:

  1. Have a project with XAML service references (.xaml file with Build Action: Workflow definition, Custom Tool: MSBuild:Compile) or (.svcmap file with Custom Tool: Xaml Activity Generator which generates .xaml files with Build Action: XamlAppDef and Custom Tool: XamlIntelliSenseFileGenerator)

  2. Convert this project to new project format

  3. Rebuild the project

Expected Behavior: Works, works always and works on first attempt

Actual Behavior: Build fails with error C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Xaml.targets(333,43): error MSB4057: The target "CoreCompile" does not exist in the project. The build works if you do Rebuild + Build (i.e. 2nd time)

User Impact: Cannot convert projects with such files to new .csproj format. Cannot use new .csproj format consistently. This si especially issue for compiling such projects on build servers as locally it can be worked around by building the project twice.

More info: As has already been discussed on https://github.com/dotnet/project-system/issues/1467 under some circumstances projects containing .xaml files are build using 2-pass build. A temporary projects with extension .tmp_proj is generated and built in order to obtain some kind of reference assembly for the 2nd build (of the main .csproj project). Unfortunately the choice of extension (which is hard-coded in the task) confuses the new project system as it cannot determine from the .tmp_proj extension which language the project is (VB, C# or something else) and thus just some default common options are available. Specifying <LanguageTargets> (<LanguageTargets>$(MSBuildToolsPath)\Microsoft.CSharp.targets</LanguageTargets>) does not solve the issue, just brings bunch error messages like

Workaround: As I have observer that in case I do Rebuild + Build in Visual Studio the 2nd build passed, it seems to be possible to work around this issue by doing exactly that: Before build of the offending project try to build it and ignore any build errors. This can be achieved by following MSBuild code in the new .csproj file:

    <Target Name="PreCompileSelf" BeforeTargets="XamlTemporaryAssemblyGeneration" Condition="'$(MSBuildProjectExtension)' == '.csproj' and '$(SelfPreCompile)' != 'true'">
        <Message Text="Pre-compiling $(MSBuildProjectFile)..." Importance="high"/>
        <MSBuild Projects="$(MSBuildProjectFile)" Properties="Configuration=$(Configuration);Platform=$(Platform);SelfPreCompile=true" ContinueOnError="WarnAndContinue"/>
    </Target>
    <Target Name="CoreCompile" Condition="'$(MSBuildProjectExtension)' != '.csproj'">
        <!--Fake target - workaround for 2-phases build of projects with XAML files-->
        <Message Text="CoreCompile target called"/>
    </Target>
davkean commented 5 years ago

@davidwengier Can you figure out if this is just Workflow XAML, or does it affect WPF too?

davidwengier commented 5 years ago

From my research these are all Worflow related items.

DzonnyDZ commented 5 years ago

See https://github.com/Microsoft/msbuild/issues/2798

danielmeza commented 4 years ago

@DzonnyDZ I try to use your workaround but not work.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
    <OutputType>Exe</OutputType>
    <StartupObject />
  </PropertyGroup>
  <ItemGroup>
    <None Remove="Activity2.xaml" />
    <None Remove="Workflow1.xaml" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System" />
    <Reference Include="System.Activities" />
    <Reference Include="System.Core" />
    <Reference Include="System.Data" />
    <Reference Include="System.Runtime.Serialization" />
    <Reference Include="System.ServiceModel" />
    <Reference Include="System.ServiceModel.Activities" />
    <Reference Include="System.Xaml" />
    <Reference Include="System.Xml" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="WindowsBase" />
  </ItemGroup>
  <ItemGroup>
    <XamlAppDef Include="Activity2.xaml">
      <Generator>MSBuild:Compile</Generator>
    </XamlAppDef>
    <XamlAppDef Include="Workflow1.xaml">
      <Generator>MSBuild:Compile</Generator>
    </XamlAppDef>
  </ItemGroup>
  <Choose>
    <When Condition="'$(MSBuildProjectExtension)' != '.csproj' and '$(MSBuildProjectExtension)' != '.vbproj'">
      <PropertyGroup>
        <LanguageTargets Condition="Exists('$(MSBuildProjectDirectory)\$(AssemblyName).csproj')">$(MSBuildToolsPath)\Microsoft.CSharp.targets</LanguageTargets>
        <LanguageTargets Condition="Exists('$(MSBuildProjectDirectory)\$(AssemblyName).vbproj')">$(MSBuildToolsPath)\Microsoft.VisualBasic.targets</LanguageTargets>
      </PropertyGroup>
    </When>
  </Choose>
  <PropertyGroup>
    <AssemblySearchPaths>$(AssemblySearchPaths);{GAC}</AssemblySearchPaths>
    <ApplicationIcon />
  </PropertyGroup>

  <Target Name="PreCompileSelf" BeforeTargets="XamlTemporaryAssemblyGeneration" Condition="'$(MSBuildProjectExtension)' == '.csproj' and '$(SelfPreCompile)' != 'true'">
    <Message Text="Pre-compiling $(MSBuildProjectFile)..." Importance="high"/>
    <MSBuild Projects="$(MSBuildProjectFile)" Properties="Configuration=$(Configuration);Platform=$(Platform);SelfPreCompile=true" ContinueOnError="WarnAndContinue"/>
  </Target>
  <Target Name="CoreCompile" Condition="'$(MSBuildProjectExtension)' != '.csproj'">
    <!--Fake target - workaround for 2-phases build of projects with XAML files-->
    <Message Text="CoreCompile target called"/>
  </Target>
</Project>

Here is my sample WorkflowConsoleApplication1.zip

The only way it work was build manually again.

danielmeza commented 4 years ago

@davidwengier and @davkean fix this will help to adopt the https://github.com/UiPath-Open/corewf project

Nirmal4G commented 4 years ago

@DzonnyDZ @danielmeza

Some background on 2-Pass compilation of Xaml in WPF and WFF targets

The problem is similar to WPF's CreateTemporaryTargetAssembly which was fixed for supporting project files without xmlns tag a while back, around v4.7.x. But the same fix was not applied for WorkFlow Xaml targets which was in many ways similar in structure and code path to the WPF targets.

So, to solve this issue, you only need to add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" back to your project file to generate the temporary project correctly.

So your project file becomes... ```xml net472 Exe MSBuild:Compile MSBuild:Compile $(MSBuildToolsPath)\Microsoft.CSharp.targets $(MSBuildToolsPath)\Microsoft.VisualBasic.targets ```

and with my Extras SDK (which extends from claire's but her sdk don't have wff or wcf yet), you'd essentially have

<Project Sdk="MSBuild.NET.Extras.Sdk" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
    <OutputType>Exe</OutputType>
    <EnableWffProjectSetup>true</EnableWffProjectSetup>
    <!--
        This is needed for Presentation tech used as a part of Activities lib.
        Only references are needed. Don't need to enable whole wpf support.
        You could also set `EnableWpfProjectSetup` to build both WPF and WFF in single exe!
     -->
    <EnableImplicitWpfReferences>true</EnableImplicitWpfReferences>
  </PropertyGroup>

</Project>

Note: I haven't updated my readme yet but the package (latest from myget) requires Visual Studio v16 (2019) but the old one on nuget works from v15.6 (2017 Update 6) onwards.

@davkean @davidwengier May I ask why was the fix not added to the WFF targets?

danielmeza commented 4 years ago

@Nirmal4G the project build and run as well! But, the designer can't load assembly from reference project in the solution. Its fail trying to load the .dll becasuse he way the assembly is searched. The problem ocurre whit reference project by another reference project. The workaround is to directly add the project as a reference.

davidwengier commented 4 years ago

May I ask why was the fix not added to the WFF targets?

Those targets don't live in this repo so I'm afraid I couldn't say.