Build error MSB4067 (UnrecognizedChildElement) when building a solution with rptproj or dwproj projects

[AndrewBennet]

When using MSBuild 15.0, cleaning or building a solution which contains rptproj or dwproj projects gives the following error:

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

When using MSBuild 14.0, the behaviour is better: it logs warnings (MSB4078) about unsupported projects:

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

The latter behaviour is more desirable (for me, at least): I would like to able to build a solution in a configuration which includes the .rptproj files. This would allow me to include these projects when building the solution in Visual Studio, and to be able to use the same configuration when building the solution via an MSBuild script.

Is this change of behaviour a bug? The message certainly seems like it is attempting to parse the rptproj file into some structure to which it doesn't belong. If it is not, is there a way to downgrade the error MSB4067 to a warning, or to skip certain projects when building a solution? The /ignoreprojectextensions:.rptproj option does not prevent the error.

Note: this issue relates to this Stack Overflow post.

[DaveSlinn]

I recently added our .rptproj back into our solution file once I saw the availability of the Reporting Services extension for VS 2017. Our solution builds fine on the dev boxes, but is broken on our build server - even though I have installed the Reporting Services Projects on the build machine as well. It's concerning that no one from the team has commented for almost 2 months.

[MgSam]

This is a big breaking change. We too now have broken solutions on our build machines because of this. Can someone please triage?

[rainersigwald]

Thanks for the report!

MSBuild has some code that attempts to detect whether projects referred to from the solution are MSBuild projects or some other format.

In #1089, this logic was simplified to support the new simplified project files, which removed a check that the project specified the MSBuild namespace.

A simple .rptproj looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" ToolsVersion="2.0">
  <DataSources />
  <Reports />
</Project>

The fact that its top-level element is <Project> now gets a false positive (I stepped through MSBuild 14.0.25420.1 and observed it failing out because the namespace didn't match).

/ignoreprojectextensions:.rptproj is deceptively unrelated; it controls MSBuild's search-for-a-project-to-build behavior when no project is specified on the command line, not what projects from the solution get built.

[rainersigwald]

Workarounds

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

• Build with devenv {path_to_solution.sln} /build
  • This uses Visual Studio to handle parsing the solution and building each individual project, so it will behave much more like "Build" from the UI.
  • This can be slower and harder to debug than using MSBuild.
• Use a solution configuration to prevent the .rptproj files from building
  • Some pros and cons discussed in the Stack Overflow question.

[rainersigwald]

Spoke to @AndyGerlicher about this. The more-permissive namespace check in the real MSBuild project parser requires that the namespace be either the MSBuild namespace or not specified. The same check could be applied in the solution parser.

[AndrewBennet]

Thanks for the workarounds! I'm trying out the after.solution.sln.targets one now.

I'm currently still hitting the issue at a later point in the build due to a solution Project Dependency: one of my csproj projects depends on an rptproj project (this was done to cause the build of the csproj to trigger the build of the rptproj).

The error shows the steps:

msbuild script -> solution file -> csproj.metaproj -> rptproj

Is there a way to similarly exclude rptproj references from the generate project metaproject? I tried the same pattern of after.project.csproj.targets alongside my csproj file, but it didn't work.

[rainersigwald]

@AndrewBennet Unfortunately, no, I don't see a nice way to prevent emitting those references into the .csproj.metaproj that is generated to handle the solution dependencies, and as you discovered that metaproject doesn't have extensibility hooks like after.project.sln.targets. I think you'll have to either drop the solution dependency or use a solution configuration to avoid the .rptproj.

[AndrewBennet]

OK - I'll remove the solution dependency for now. Thanks 👍

[reicher001]

Any updates or timeline on when this issue will be resolved?

[AndrewBennet]

Just discovered that the ability to build rptproj projects with MSBuild has been added in the last few weeks: https://blogs.msdn.microsoft.com/sqlrsteamblog/2017/09/25/msbuild-support-for-reporting-services-projects-now-available/

Have not tried this out yet, but upgrading the rptproj projects to the latest format would presumably get around this problem.

---

Update: Having updated the SSRS Visual Studio plugin and upgraded the SSRS projects to the latest format, this issue no longer occurs. I can restore the solution dependecies 🎉

[fenngineering]

Are .dtproj projects being added in the same fix?

[benjiadell]

Any updates for *.dtproj ? We have this issue on our customer and we need to build as soon as possible.

[richardlhughes]

I am seeing the same error with my .dtproj

Error MSB4067: The element <DeploymentModel> beneath element <Project> is unrecognized.

Should I open a new issue for building ispac's from dtproj?

[samsmithnz]

@richardlhughes: This workaround does work for dtproj too.

[donuwm]

@richardlhughes: This workaround does work for dtproj too.

Confirmed.

[StingyJack]

@rainersigwald - is this workaround still the only way to make this work on an Azure DevOps hosted build agent?

[shalmali30]

Workarounds

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

• Build with devenv {path_to_solution.sln} /build

  • This uses Visual Studio to handle parsing the solution and building each individual project, so it will behave much more like "Build" from the UI.
  • This can be slower and harder to debug than using MSBuild.

• Use a solution configuration to prevent the .rptproj files from building

  • Some pros and cons discussed in the Stack Overflow question.

HI, I am having .dtproj and .rptproj in a solution. i was getting errors for SSRS as well as SSIS. with this workaround, i could solve ssrs error message. Now SSIS is still there. I added :

Can you please let me know how to add .dtproj referance ?

[soroshsabz]

Is there any plan to resolve fundamentally this issue?

[madibaT]

Is there any update on this issue?

[soroshsabz]

@arielman what is helping TFS update 2 ?

[kartheekp-ms]

How about adding SkipUnsupportedProjects like SkipNonexistentProjects to MSBuild task? Related NuGet/Home#7796 FYI.. @dotnet/msbuild team

[aortiz-msft]

FYI.. @marcpopMSFT @dotnet/msbuild team this issue has 23 upvotes from the community in NuGet/Home#7796. In summary, NuGet.exe invokes msbuild.exe during restore to identify the project references for a project. As per @kartheekp-ms's analysis NuGet/Home#7796 (comment), it looks like something changed in msbuild version after 15.9 where msbuild.exe started returning a failure exit code when trying to read project references for a custom project (for example vdproj in this case). This happens even when ContinueOnError is set to WarnAndContinue (new behavior after 15.9 version). NuGet raises an exception in this case causing restore failures.

[thelaziestgenius]

@rainersigwald I'm upgrading some SSAS dwproj files from 2019 to VS 2022, and I'm getting a build failure that just says Object reference not set to an instance of an object.
Currently, there isn't an official extension to support loading up SSAS projects, but I did try to install the latest release candidate:
https://marketplace.visualstudio.com/items?itemName=ProBITools.MicrosoftAnalysisServicesModelingProjects

Is there a similar workaround to get the dwproj file to build and deploy in Visual studio 2022?

[rainersigwald]

@thelaziestgenius are you building from Visual Studio, or using MSBuild.exe on the command line?

[thelaziestgenius]

@rainersigwald

I'm building from Visual Studio. Is there a way to build in MSBuild.exe to get more logging?

[rainersigwald]

@thelaziestgenius If you're building from Visual Studio, you're not hitting the problem tracked by this issue, which manifests only for command-line builds. I think you'll have to ask in the support channels for that plugin.

[thelaziestgenius]

@rainersigwald I've reached out to the team that manages the Microsoft Analysis Services Projects extension.

I ran this command and got the following error:
msbuild "C:\Projects\SSAS.dwproj" /t:go /fl

Error:
MSBuild version = "16.11.2+f32259642"
Build FAILED.

"C:\Projects\SSAS.dwproj" (go target) (1) ->
C:\Projects\SSAS.dwproj(2,3): error MSB4067: The element beneath element is unrecognized.

0 Warning(s)
1 Error(s)

Time Elapsed 00:00:00.04

I've also tried running it with the 2022 exe explicitly:
MSBuild version = "17.1.0+ae57d105c" and got the same error.

[rainersigwald]

@thelaziestgenius that is not expected to work, because .dwproj files are not MSBuild projects; they are a different project format recognized by the Visual Studio plugin, which also handles building them.