@srivatsn commented on Thu Jun 22 2017
Add a XAML file to a CPS-based project.
Expected: file.g.i.cs should be generated in the obj directory during a design-time build so that intellisense knows about the types defined the XAML.
Actual: It's not generated and there are squiggles about missing definition for InitializeComponent etc.
Cause:
The old project system used to run the Compile target in a single msbuild instance and other targets to get outputgroups in a different instance. CPS batches them all and runs all targets in a single msbuild instance.
The generation of the .g.i.cs is done by a target called DesignTimeMarkupCompilation and that wants to run only during a DT build - to do that it only runs if $(BuildingProject) == 'true'`. Normally BuildingProject is false. However there's a target to get the PDB output group that sets it to true. Since it's the same msbuild instance that runs both targets, DesignTimeMarkupCompilation is being skipped.
Not sure what the right fix is here - the DesignTimeMarkupCompilation can check the $(DesignTimeBuild) property instead of BuildingInProject. Or maybe CPS needs to batch the targets into multiple batches.
A workaround to get this working is to add something like this to the project or to some import:
<Target Name="WorkaroundForXAMLIntellisenseBuildIssue" AfterTargets="_CheckCompileDesignTimePrerequisite">
<PropertyGroup>
<BuildingProject>false</BuildingProject>
</PropertyGroup>
</Target>This explicitly sets BuildingProject to false just before we run the CompileDesignTime target.
@srivatsn commented on Thu Jun 22 2017
@tmat - can you please put in this workaround in the repo toolset when you move project system repo to repo toolset? Since we have a few XAML files, today if we have full solution analysis on, then there will be errors in the error list about missing InitializeComponent etc.
Also @jaredpar - you'll need this as well for your branch that's moving roslyn to cps to avoid errors with full solution analysis on.
@jaredpar commented on Thu Jun 22 2017
@srivatsn thanks for the heads up.
@tmat commented on Thu Jun 22 2017
@srivatsn Sure.
@tmat commented on Thu Jun 22 2017
I tried to add it but it broke the build. Xaml code behind is not generated at all to the obj dir during regular build
@srivatsn commented on Fri Jun 23 2017
I added this to the project-system repo's targets files and I don't see any build breaks and it works fine in the IDE for me. We can take a look tomorrow.
@jaredpar commented on Fri Jun 23 2017
The Roslyn build succeeded with this change as well.
@davkean commented on Tue Sep 12 2017
Moving this to a tracking bug as the underlying cause is: dotnet/msbuild#2417.
@davidwengier commented on Sun Jul 21 2019
Design time builds in Roslyn.sln no longer have anything that sets BuildingProject to true. I don't think this workaround is necessary any more, and I don't think this problem exists any more.
If I'm mistaken, feel free to re-open.
@tmat commented on Sun Jul 21 2019
@davidwengier The workaround is still present in Arcade SDK: https://github.com/dotnet/arcade/blob/dd885745172424fc8df97295514f693efaec8d24/src/Microsoft.DotNet.Arcade.Sdk/tools/Workarounds.targets#L16-L24
@davkean commented on Sun Jul 21 2019
@davidwengier BuildingProject is set to true when output groups are merged with design-time build, as called out in the linked msbuild bug above: dotnet/msbuild#2417.
@davidwengier commented on Sun Jul 21 2019
Under what circumstances does that happen though? The list of targets in the top comment on that issue is not the list of targets that I'm seeing during a design time build. If this is dependant on project configuration, any hints you can give me to reproduce the issue would be greatly appreciated. This issue only mentions full solution analysis which I have turned on.
@davkean commented on Sun Jul 21 2019
Two ways to approach this, go and figure out a feature that uses Output Groups and have it triggered in such a way that its gets combined with the first design-time build, or hack it up so that a target we do call during the build, depends on an output group target. The latter is probably easier to trigger and reproduce.
@srivatsn commented on Thu Jun 22 2017
Add a XAML file to a CPS-based project.
Expected: file.g.i.cs should be generated in the obj directory during a design-time build so that intellisense knows about the types defined the XAML.
Actual: It's not generated and there are squiggles about missing definition for InitializeComponent etc.
Cause:
The old project system used to run the
Compiletarget in a single msbuild instance and other targets to get outputgroups in a different instance. CPS batches them all and runs all targets in a single msbuild instance.The generation of the .g.i.cs is done by a target called DesignTimeMarkupCompilation and that wants to run only during a DT build - to do that it only runs if
$(BuildingProject)== 'true'`. Normally BuildingProject is false. However there's a target to get the PDB output group that sets it to true. Since it's the same msbuild instance that runs both targets, DesignTimeMarkupCompilation is being skipped.Not sure what the right fix is here - the DesignTimeMarkupCompilation can check the
$(DesignTimeBuild)property instead of BuildingInProject. Or maybe CPS needs to batch the targets into multiple batches.A workaround to get this working is to add something like this to the project or to some import:
This explicitly sets BuildingProject to false just before we run the CompileDesignTime target.
@srivatsn commented on Thu Jun 22 2017
@tmat - can you please put in this workaround in the repo toolset when you move project system repo to repo toolset? Since we have a few XAML files, today if we have full solution analysis on, then there will be errors in the error list about missing InitializeComponent etc.
Also @jaredpar - you'll need this as well for your branch that's moving roslyn to cps to avoid errors with full solution analysis on.
@jaredpar commented on Thu Jun 22 2017
@srivatsn thanks for the heads up.
@tmat commented on Thu Jun 22 2017
@srivatsn Sure.
@tmat commented on Thu Jun 22 2017
I tried to add it but it broke the build. Xaml code behind is not generated at all to the obj dir during regular build
@srivatsn commented on Fri Jun 23 2017
I added this to the project-system repo's targets files and I don't see any build breaks and it works fine in the IDE for me. We can take a look tomorrow.
@jaredpar commented on Fri Jun 23 2017
The Roslyn build succeeded with this change as well.
@davkean commented on Tue Sep 12 2017
Moving this to a tracking bug as the underlying cause is: dotnet/msbuild#2417.
@davidwengier commented on Sun Jul 21 2019
Design time builds in Roslyn.sln no longer have anything that sets
BuildingProjecttotrue. I don't think this workaround is necessary any more, and I don't think this problem exists any more.If I'm mistaken, feel free to re-open.
@tmat commented on Sun Jul 21 2019
@davidwengier The workaround is still present in Arcade SDK: https://github.com/dotnet/arcade/blob/dd885745172424fc8df97295514f693efaec8d24/src/Microsoft.DotNet.Arcade.Sdk/tools/Workarounds.targets#L16-L24
@davkean commented on Sun Jul 21 2019
@davidwengier
BuildingProjectis set totruewhen output groups are merged with design-time build, as called out in the linked msbuild bug above: dotnet/msbuild#2417.@davidwengier commented on Sun Jul 21 2019
Under what circumstances does that happen though? The list of targets in the top comment on that issue is not the list of targets that I'm seeing during a design time build. If this is dependant on project configuration, any hints you can give me to reproduce the issue would be greatly appreciated. This issue only mentions full solution analysis which I have turned on.
@davkean commented on Sun Jul 21 2019
Two ways to approach this, go and figure out a feature that uses Output Groups and have it triggered in such a way that its gets combined with the first design-time build, or hack it up so that a target we do call during the build, depends on an output group target. The latter is probably easier to trigger and reproduce.