Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XAML files are not supported #1467

Open
srivatsn opened this Issue Feb 3, 2017 · 52 comments

Comments

@srivatsn
Copy link
Contributor

srivatsn commented Feb 3, 2017

From @tannergooding on February 3, 2017 22:56

Attached is a simple repro solution.
WpfCps.zip

Issue 1: XAML files are treated as None, when they should be treated as Page with Generator=MSBuild:Compile and SubType=Designer metadata.
Issue 2: Page items are not visible in the Solution Explorer
Issue 3: xaml.cs files are not properly nested under the xaml file
Issue 4: Compilation fails with: 1>C:\windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(419,45): error MSB4057: The target "CoreCompile" does not exist in the project.

Copied from original issue: dotnet/sdk#810

@srivatsn

This comment has been minimized.

Copy link
Contributor Author

srivatsn commented Feb 3, 2017

From @tannergooding on February 3, 2017 22:56

FYI. @srivatsn, @jinujoseph, @nguerrera

@srivatsn

This comment has been minimized.

Copy link
Contributor Author

srivatsn commented Feb 3, 2017

From @tannergooding on February 3, 2017 22:57

This completely blocks the porting of WPF based applications to CPS (I imagine it would also block UWP and anything else that uses XAML).

@srivatsn

This comment has been minimized.

Copy link
Contributor Author

srivatsn commented Feb 3, 2017

Yes WPF and any other desktop projects are not supported yet. Currently only .NET Core projects are supported.

@srivatsn srivatsn added this to the Unknown milestone Feb 3, 2017

@onovotny

This comment has been minimized.

Copy link
Member

onovotny commented Feb 4, 2017

This should work with the right LanguageTargets, shouldn't it?

@aienabled

This comment has been minimized.

Copy link

aienabled commented Feb 6, 2017

For me it works good with VS2017 RC and the class library project (.NET Framework, not .NET Standard). I can include XAML files and everything is properly compiled, Intellisense works, etc.
The only issue I have is when I use globbing - the dependent .xaml.cs files are not nested. Reported there Microsoft/VSProjectSystem#169

UPD. I also checked default class library project (the template with .NET Standard). After switching target to net461 it works but indeed it treats XAML as None... and manual setting it to Page leads to The target "CoreCompile" does not exist in the project error.

@aienabled

This comment has been minimized.

Copy link

aienabled commented Feb 7, 2017

I was able to properly setup XAML files building with CPS for VS2017.
@onovotny was right, with proper targets it works. I've added <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />. Also I added missing XAML rule for Page. And I've found a workaround for the issue with the dependent .xaml.cs files for files globbing (see link above).

@tannergooding

This comment has been minimized.

Copy link
Member

tannergooding commented Feb 7, 2017

Ok. I now understand this much better (@srivatsn).

WPF (and some other project types) generate a temporary project file that does not use the same extension as the original (WPF uses .tmp_proj, for example).

The SDK.targets uses the project extension to set LanguageTargets (provided LanguageTargets has not already been set). It then imports whatever LanguageTargets is set to (C# should be setting it to $(MSBuildToolsPath)\Microsoft.CSharp.targets, for example).

So the workaround is to ensure that LanguageTargets is set on any project type that hits the above issue.

I would think the proper fix, however, is to get the XAML targets (and any other targets that generate temporary projects) to use the original project extension.

@aienabled

This comment has been minimized.

Copy link

aienabled commented Feb 8, 2017

@tannergooding, WPF is using temporary project because it need two-pass building to properly process XAML markup as described in this article on MSDN. So I'm afraid it might not be possible to avoid .tmp_proj.

@davkean

This comment has been minimized.

Copy link
Member

davkean commented Feb 8, 2017

@aienabled Keep any bugs you file for managed concepts on this repro.

@tannergooding

This comment has been minimized.

Copy link
Member

tannergooding commented Feb 8, 2017

@aienabled, i wasn't indicating it should avoid .tmp_proj, I'm saying t should usee the original projects file extension when doing so. Meaning instead of .tmp_proj, it should use .tmp_proj.csproj or just .csproj.

@srivatsn

This comment has been minimized.

Copy link
Contributor Author

srivatsn commented Feb 8, 2017

@tannergooding can you file that as an internal bug on XAML?

@tannergooding

This comment has been minimized.

Copy link
Member

tannergooding commented Feb 8, 2017

@srivatsn, I have logged VSO Bug: 382095 (not sure if the area path is correct, it seemed to be the best fit though).

@gulbanana

This comment has been minimized.

Copy link

gulbanana commented Apr 28, 2017

XAML needs PresentationBuildTasks, right, so is it correct that making this work in the SDK won't automatically make it work with dotnet build?

@tmat

This comment has been minimized.

Copy link
Member

tmat commented Jun 22, 2017

Related: dotnet/sdk#1367

@tmat

This comment has been minimized.

Copy link
Member

tmat commented Jun 22, 2017

Workaround in RepoToolset (included via Directory.Build.props):

  <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>

Turns out the XAML build sets the AssemblyName property to the original value.

@bdovaz

This comment has been minimized.

Copy link

bdovaz commented Sep 4, 2017

Anyone got this working? I'm able to compile it but I lost intellisense in VS 2017.

This is my csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <LanguageTargets>$(MSBuildExtensionsPath)\$(VisualStudioVersion)\Bin\Microsoft.CSharp.targets</LanguageTargets>
    <OutputType>winexe</OutputType>
    <TargetFramework>net462</TargetFramework>
    <DebugType>Full</DebugType>
    <ApplicationIcon>res\ico\icon.ico</ApplicationIcon>
    <OutputTypeEx>winexe</OutputTypeEx>
    <StartupObject />
  </PropertyGroup>

  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">15.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
    <TransformOnBuild>True</TransformOnBuild>
    <TransformOutOfDateOnly>false</TransformOutOfDateOnly>
  </PropertyGroup>

  <Import Project="$(VSToolsPath)\TextTemplating\Microsoft.TextTemplating.targets" />

  <ItemGroup>
    <!-- App.xaml -->
    <ApplicationDefinition Include="App.xaml" SubType="Designer" Generator="MSBuild:UpdateDesignTimeXaml" />

    <!-- XAML elements -->
    <Page Include="**\*.xaml" SubType="Designer" Generator="MSBuild:UpdateDesignTimeXaml" Exclude="App.xaml" />
    <Compile Update="**\*.xaml.cs" SubType="Designer" DependentUpon="%(Filename)" />
    <Compile Include="$(IntermediateOutputPath)**\*.g.cs" Visible="false" />
    <None Include="$(ProjectDir)obj" Visible="false" />

    <!-- Resources -->
    <EmbeddedResource Update="Properties\Resources.resx" Generator="ResXFileCodeGenerator" LastGenOutput="Resources.Designer.cs" />
    <Compile Update="Properties\Resources.Designer.cs" AutoGen="True" DependentUpon="Resources.resx" DesignTime="True" />

    <!-- Settings -->
    <None Update="Properties\Settings.settings" Generator="SettingsSingleFileGenerator" LastGenOutput="Settings.Designer.cs" />
    <Compile Update="Properties\Settings.Designer.cs" AutoGen="True" DependentUpon="Settings.settings" />

    <None Update="App.config">
      <TransformOnBuild>true</TransformOnBuild>
    </None>
    <None Update="App.Debug.config">
      <IsTransformFile>True</IsTransformFile>
    </None>
    <None Update="App.Release.config">
      <IsTransformFile>True</IsTransformFile>
    </None>
  </ItemGroup>

  <ItemGroup>
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <Reference Include="System.Xaml" />
    <Reference Include="WindowsBase" />
  </ItemGroup>

  <ItemGroup>
    <Compile Remove="Publish\**" />
    <EmbeddedResource Remove="Publish\**" />
    <None Remove="Publish\**" />
    <Page Remove="Publish\**" />
  </ItemGroup>

  <PropertyGroup>
    <AssemblySearchPaths>$(AssemblySearchPaths);{GAC}</AssemblySearchPaths>
  </PropertyGroup>

  <Import Project="$(MSBuildSDKExtrasTargets)" Condition="Exists('$(MSBuildSDKExtrasTargets)')" />
</Project>
@sharwell

This comment has been minimized.

Copy link
Member

sharwell commented Sep 4, 2017

@bdovaz I notice you have Generator="MSBuild:UpdateDesignTimeXaml". Is there a reason you aren't using Generator="MSBuild:Compile"?

Here's one project that I've been working on that uses XAML. I need to look back and see if IntelliSense is working properly.

https://github.com/Microsoft/perfview/blob/aa6bfb7d5dec6144979b3399c46818907e068885/src/PerfView/PerfView.csproj#L99

@bdovaz

This comment has been minimized.

Copy link

bdovaz commented Sep 4, 2017

@sharwell to be honest I don't know, my csproj is being written by seeing other people examples that are trying to achieve the same goal.

Also when I mean intellisense I mean that I can't reference almost anything. Example:

image

Note: The code that is not recognizing it's in another referenced project.

I really want to use the new format but I need a working example that works. One example that:

  • Intellisense works.
  • Successfully includes XAML intermediate code (*.g.cs) so I can reference components of the XAML page.

I've tried to update my csproj seeing that example but I have the same problem: it compiles but I have no Intellisense.

Any help?

@aienabled

This comment has been minimized.

Copy link

aienabled commented Sep 5, 2017

@bdovaz,
I'm using it successfully for WPF (multiple projects referencing each other) and IntelliSense works well (in C# and XAML files).

Do you need this for WPF/UWP or Xamarin project?
Are you able to see XAML files in the solution explorer? I'm asking because there is no Page item type rule in netstandard and without it XAML files added as Page are not visible in the solution explorer but you didn't mention about it. To workaround this, I'm using custom targets which add the Page rule.
I will prepare a small sample.

@BrunoJuchli

This comment has been minimized.

Copy link

BrunoJuchli commented Jan 29, 2018

@tannergooding We've been working on our WPF application for several years and are still creating new ones. We (can't speak for others...) would prefer, by far, a breaking change than not having CPS support. A breaking change we can deal with. We notice it, we learn about it, we apply the changes and we move on.
The split between CPS and old style projects has already created issues for us several times as we've also got .net core frontends. Using CPS everywhere would enable us to share more of our build chain and make our build chain/infrastructure simpler, too. Currently we have to duplicate quite some code and that creates continuous friction - much worse than a breaking change.

That said, however, we'd also be fine with CPS WPF support being an opt-in. Let's say you could add a *.targets import to every WPF csproj or something like that.

@gulbanana

This comment has been minimized.

Copy link

gulbanana commented Jan 29, 2018

I'm in exactly the same position - tons of old wpf, tons of new asp.net core, we want interoperability and can accept breaking changes to achieve it, whether they require an opt-in or not.

@bdominguez

This comment has been minimized.

Copy link

bdominguez commented Jan 29, 2018

Same here, If we have that breaking changes documented, there is no problem.

@gulbanana

This comment has been minimized.

Copy link

gulbanana commented Jan 29, 2018

bear in mind that for anyone using wpf clickonce, the last couple of .net framework and visual studio releases have already been massively breaking :)

@Latency

This comment has been minimized.

Copy link

Latency commented Feb 4, 2018

@sharwell the last bit of that .csproj file in the link you referenced, it will break loading of the Assemblies. Doesn't work! I am using v4.7.1 w/ CPS build configs.

<!--
  Work around to fix Intellisense file generation for XAML projects https://github.com/dotnet/project-system/issues/2488
-->
<Target Name="WorkaroundForXAMLIntellisenseBuildIssue" AfterTargets="_CheckCompileDesignTimePrerequisite">
  <PropertyGroup>
    <BuildingProject>false</BuildingProject>
  </PropertyGroup>
</Target>

Reverting to using this instead:

<!-- App.xaml --> 
<ApplicationDefinition Include="App.xaml" SubType="Designer" Generator="MSBuild:XamlIntelliSenseFileGenerator" />
	
<!-- XAML elements -->
<Page Include="**\*.xaml" SubType="Designer" Generator="MSBuild:XamlIntelliSenseFileGenerator" Exclude="App.xaml" />
<Compile Update="**\*.xaml.cs" SubType="Designer" DependentUpon="%(Filename)" />
<Compile Include="$(IntermediateOutputPath)**\*.g.cs" Visible="false" />
<None Include="$(ProjectDir)obj" Visible="false" />

@everyone as for the expected abstract target for CoreCompile, Adding the target Imports for old conventions do not work for me. It is very problematic and doesn't appear to be correct anyway.

I recommend using a pseudo target to get around it asking for the built-in default target for now.

<Target Name="CoreCompile" />

@sharwell

This comment has been minimized.

Copy link
Member

sharwell commented Feb 4, 2018

@Latency Can you be more specific? The code you referenced as broken is currently used in several projects, including Roslyn where I spend the most time. We have observed a few rare edge cases where things don't work right, but generally that appears to be a required inclusion.

@Latency

This comment has been minimized.

Copy link

Latency commented Feb 5, 2018

@sharwell I managed to get something to work within the past 24 hrs.. but it does not contain that target rule like mentioned in my previous thread. That target breaks my project.

Here is what I have:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup>
    <LanguageTargets Condition="Exists('$(MSBuildProjectDirectory)\$(AssemblyName).csproj')">$(MSBuildToolsPath)\Microsoft.CSharp.targets</LanguageTargets>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net471</TargetFramework>
    <StartupObject>HearthStone.UnInstaller.App</StartupObject>
    <PackageId>HearthStone.UnInstaller</PackageId>
    <AssemblyName>HearthStone.UnInstaller</AssemblyName>
    <RootNamespace>HearthStone.UnInstaller</RootNamespace>
    <Version>1.0.0</Version>
    <TargetFrameworkVersion>v4.7.1</TargetFrameworkVersion>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <Reference Include="System.Xaml" />
    <Reference Include="WindowsBase" />
    <!-- App.xaml -->
    <ApplicationDefinition Include="App.xaml" SubType="Designer" Generator="MSBuild:XamlIntelliSenseFileGenerator" />
    <!-- XAML elements -->
    <Page Include="**\*.xaml" SubType="Designer" Generator="MSBuild:Compile" Exclude="App.xaml" />
    <Compile Update="**\*.xaml.cs" SubType="Designer" DependentUpon="%(Filename)" />
    <Compile Update="$(IntermediateOutputPath)**\*.g.cs" Visible="false" />
  </ItemGroup>
</Project>

The <LanguageTargets ...> seems to be a key component to getting this to work, along with using the appropriate referenced assemblies to be included for XAML.

@DNF-SaS

This comment has been minimized.

Copy link

DNF-SaS commented Feb 5, 2018

Could you replace your <LanguageTargets ...> with <LanguageTargets>$(MSBuildExtensionsPath)\$(VisualStudioVersion)\Bin\Microsoft.CSharp.targets</LanguageTargets>
It makes it compile on my machine, maybe it helps you, too.

@sharwell

This comment has been minimized.

Copy link
Member

sharwell commented Feb 5, 2018

@onovotny

This comment has been minimized.

Copy link
Member

onovotny commented Feb 5, 2018

@Latency I would strongly suggest you use my MSBuild.Sdk.Extras package instead of adding that code to your own project. I have the WPF workarounds/"stuff" in there based on @sharwell and others' work. If there's other issues/enhancements, I'm happy to take PR's to fix.

My objective with that package is to fill the box and make it clean/simple to use with SDK style projects until there's direct support from Microsoft.

@onovotny

This comment has been minimized.

Copy link
Member

onovotny commented Feb 5, 2018

@sharwell I'll give you the same advice too for ILSpy ;) Iet's keep our efforts/workarounds consolidated if we can.

@Latency

This comment has been minimized.

Copy link

Latency commented Feb 7, 2018

@onovotny I will be happy to give that a try.. It looks solid!

To be clear, I am removing the entire <ItemGroup> section and the <LanguageTargets> line also as shown in my snip-it with this?

On initial compile.. it appears to pass the pre-checks. Since, my project is broke down for reconstruction on a major build ATM, I have lots of debugging to do.. and can not validate this!

What I can tell you is that something is missing from being able to compile the XAML files now after using your .nupkg.

I am getting missing references to override OnClosing() in a few of my XAML files and about 100 less errors than my version which seems suspicious. I am not sure what order the compiler is checking things here.

Q: I assume that I would need to resolve these OnClosing() issues before seeing the other 100 problems with the project that still remain to be debugged?

Q: What am I missing now and which of these rules I posted redundant in your package? (too busy to investigate)

I have had to revert to keeping the rules from my above listed example to finish debugging my project until I can get a more clarity on which rules I must keep in conjunction with your Extensions package.

Q: Is the Workaround .nupkg of yours deprecated and been replaced with the Extensions one now?

Q: For Blend 2017, it appears it is not supporting the new build configuration formats. Any thoughts regarding that? Are we supposed to wait for a fix from Microsoft on this?

@bergmeister

This comment has been minimized.

Copy link

bergmeister commented Nov 13, 2018

Tried to convert a XAML project to the new project format today and neither the LanguageTargets nor the MSBuild.Sdk.Extras worked although I also use the latest SDK. Given that .Net Core 3.0 is going to come soon, when are we going to see support for this?

@gulbanana

This comment has been minimized.

Copy link

gulbanana commented Nov 14, 2018

There is imperfect XAML support already in the 3.0 nightly builds - pre-alpha stuff, but it’s definutely being implemented. I would expect full support (designer etc) to require vs2019. In the meantime, the workarounds people have described above are still functioning; I have a bunch of WPF libraries and applications using SDK projects.

@davkean

This comment has been minimized.

Copy link
Member

davkean commented Nov 14, 2018

Project system support, as per our roadmap https://github.com/dotnet/project-system/blob/master/docs/repo/roadmap.md, is in the 16.x timeframe.

@jjmew jjmew modified the milestones: 16.0, 16.1 Dec 18, 2018

@davidwengier davidwengier added this to Winforms/WPF in David Wengier Mar 26, 2019

@jjmew jjmew modified the milestones: 16.1, 16.2 Apr 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.