MSBuild 15.0 (Visual Studio 2017) error MSB4067 for SSDT (SSRS and SSAS) projects: "The element <State> beneath element <Project> is unrecognized"

Question

MSBuild 14.0 (the version included with Visual Studio 2015) logs warnings (MSB4078) when building a solution which contains SSDT projects (rptproj or dwproj projects). For example:

warning MSB4078: The project file "Reports.rptproj" is not supported by MSBuild and cannot be built.

This is fine, MSBuild does not support SSDT projects, and we have to fall back to building them with Visual Studio (i.e. devenv.com). See, for example, this answer.

When using MSBuild 15.0 (the version included with Visual Studio 2017), however, building the same solution file gives the following error:

Reports.rptproj(3,3): error MSB4067: The element <State> beneath element <Project> is unrecognized.

While I could remove the SSDT projects from the build configuration, that is not ideal, as I want them to be built when building the solution from within Visual Studio.

Is there a way to downgrade the error MSB4067 to a warning, or to skip certain projects when building a solution?

Million

Talk to its vendor. As MSBuild is open source now you can do this at its GitHub repo. – Rudiment

Thanks - I have now raised an issue on the MSBuild GitHub repo – Million

Answer 1

Update (October 2017)

The latest version of Microsoft Reporting Services Projects for Visual Studio (1.18) adds MSBuild support for SSRS projects. With this installed, SSRS projects can be updated to a format supported by MSBuild, which prevents this problem from happening.

---

Original Answer

This is a bug in MSBuild 15, labelled for fix in "foundation update 2".

A workaround as given in the GitHub issue thread by one of the MSBuild maintainers is:

Place a file with these contents next to your .sln file with the special name:

after.{yoursolutionname}.sln.targets

<Project InitialTargets="WorkAroundMSBuild2064">
 <Target Name="WorkAroundMSBuild2064">
  <!-- Work around https://github.com/Microsoft/msbuild/issues/2064 by
   removing *.rptproj from the generated solution metaproject. -->
  <ItemGroup>
   <ProjectReference Remove="%(ProjectReference.Identity)"
                 Condition="'@(ProjectReference->'%(Extension)')' == '.rptproj'" />
  </ItemGroup>
 </Target>
</Project>

This seems to work provided that there are no Project Dependencies from other .csproj projects to the .rptproj projects.

Million

And now everybody will be waiting a MSBuild supprot for .dtproj and for eternity – Illegitimate

@Illegitimate 's comment seems valid, only the workaround worked for .dtproj – Tedra

Answer 2

Skipping projects can be done with /ignoreprojectextensions:.rptproj, but I still get the warning (on VS2015) so presumably you would still get the error.

What is possible is to specify a list of the ones you do want to build with

msbuild /t:myCsProj /t:mySqlProj /t:myOtherProjThatIsntaRptProj

Whether or not this is viable, of course, depends on how many "other" projects you have in your solution.

Alternatively, there are some ways of bodging MSBuild to be able to cope with other project types (e.g. https://speaksql.wordpress.com/2013/06/07/a-journey-to-db-deployment-automaton-ssis-build-using-msbuild/).

I've seen this approach "in the wild" a couple of times, but only ever for SSIS. I have heard it can be made to work for SSRS/SSAS too though.

Neom

Can confirm that /ignoreprojectextensions:.rptproj does not prevent the error for MSBuild 15. I suppose an alternative option to specifying all the projects is to define a new solution configuration which excludes the non-MSBuildable projects, and build in that configuration with /p:Configuration=NewConfiguration – Million

That does leave a bit of scope for "user error" though, viz the users selecting the wrong configuration when building from Visual Studio and wondering why the rptproj didn't build. Swings and roundabouts, I guess. – Neom

Yeah I agree, it's not ideal, but it might be the best workaround for me. Annoyingly, it's not very viable to specify individual projects for my specific use case - in addition to there being quite a lot of projects, we store the desired project platform/configuration information at the solution level (a solution configuration). You seemingly can't specify a solution platform & configuration when building an individual project... – Million