project-system: New .csproj cannot reference a traditional .csproj

[I can’t find instructions on which repo to post this in. I’m happy to move it if need be.]

https://github.com/jnm2/misc-codesamples/raw/master/Bug reports/.NET/MSBuild old csproj issue.zip

Repro

To see the problem, build the .sln in Visual Studio. It fails with no errors.

Or, run the following from the VS2017 developer command prompt:

msbuild "MSBuild old csproj issue.sln" /t:restore
msbuild "MSBuild old csproj issue.sln" /t:clean

The clean fails (as do subsequent cleans and builds) with errors similar to:

“MSBuild old csproj issue.sln” (clean target) (1) -> “NonGuiTestProject\NonGuiTestProject.csproj” (Clean target) (2) -> “WinFormsLibrary\project.json” (Clean target) (4:2) -> WinFormsLibrary\project.json(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.

Dilemma

This is purely net462 stuff. .NET Core and .NET Standard are not in the picture here. This makes it difficult to search for help on this issue because .NET Core information is inapplicable. MSBuild 15 can build traditional .csproj + project.json just fine. And that’s a very good thing.

The GUI projects can’t migrate away from .csproj + project.json (NuGet v3) because CPS does not support them yet. Moving back to packages.config (NuGet v2) is not an option for a plethora of reasons, not least of which is that our application depends on packages that require project.json or later.

The non-GUI test project should be free to move forward to CPS .csproj (NuGet v4). The reason I’m undertaking the migration now is that all the test projects fail to build under MSBuild 15. They contain boilerplate from the VS2015 template such as <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> which works fine with MSBuild 14 and fails with MSBuild 15. Our new build server purposely has only Visual Studio 2017 installed, not VS2015, but this forces me to change all the test projects to play well with MSBuild 15. Since I have to spend time learning how to clean them up, I intended to save time by making our planned move to CPS now.

I have no idea what’s going on. Please provide a workaround and a fix. I have been planning and anticipating for ages to be able to migrate our console, class library and test projects to the new .csproj. It solves a number of issues for us. Not being able to move forward at all is incredibly disappointing.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 36 (18 by maintainers)

Commits related to this issue

Most upvoted comments

MSBuild would be the correct place to file this.

Given we’ve got NuGet bugs tracking your issue, I’ll close this out.

Nitpick: I’d like msbuild /t:clean to reset the state of the working tree in such a way that it’s as though I’d never built before. It only has one job, right? It doesn’t seem to be fulfilling it.

We are using Legacy + PackageRef with MSAL here: https://github.com/azureAD/microsoft-authentication-library-for-dotnet

There are some workarounds needed, but it does work…

All PackageReference features work for packages. Transitive project-to-project references don’t work, so your legacy project will need a p2p ref for each of those that it needs – just like today.

You don’t need to use the CPS projects to use PackageReference. All of the existing project types support it, just add the line manually the first time. Once you do, NuGet will add/update others.

I found a workaround: every new .csproj project must directly reference every transitively-referenced project.json project to avoid this bug. That’s better than not being able to move forward but it’s a lot of noise that does not truly represent necessary references.