Msbuild: 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 :+1:

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

Condition="'@(ProjectReference->'%(Extension)')' == '.rptproj'" />
Condition="'@(ProjectReference->'%(Extension)')' == '.dtproj'" />

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