Runtime: Presence of project.json breaks existing csproj tooling (and makes unexpected demands)

[mgravell]

I'm trying to transition multiple libraries to CoreCLR, moving to the DNX build tools.

Since the folder name defines the assembly/package name (not editable), and since **/*.cs is the default inclusion list, the natural thing to want to do is to add a project.json _alongside_ the pre-existing csproj. This is particularly valuable where not all parties are yet working with DNX.

Things go south very quickly, though, with errors from nuget package restore including errors about "runtimes", having to add explicit version numbers to project references, and complains about projects targeting multiple frameworks (which gets generated into {projectt}.nuget.targets).

Short term, del project.json /s, del project.lock.json /s (and del *.nuget.targes /s if you have already failed once) makes everything work - so it is the mere presence of those files that makes the csproj unhappy. And obviously you need to not push those deletions back to source control!

This means that the only way to transition to DNX tooling alongside csproj is:

• have the project.json in the {ProjectName} folder
• have the csproj in a _different_ folder
• edit the csproj to pick the files up from outside the tree, ideally using "../{ProjectName}/**/*.cs" so no more edits will be needed
  
  
  
  • (note you can do the same from project.json, but if you do that the IDE doesn't show them, where-as this at least does)
  
  
• accept the fact that adding new files via the csproj is a "no-no"

It is a bit of a faff.

Am I doing something insanely wrong here? I know csproj alongside project.json isn't the ideal end goal, but we live in the real world where most people aren't using pre-RC software ;p

[davidfowl]

Nah, we need to fix this. We're looking at allowing the folder name to be decoupled from the project name (there are some challenges with this) but we know we need to solve it.

[TheRealPiotrP]

@livarcocc is looking into this with @KrzysztofCwalina in regards to the corefxlab repo. I hope the same solution can be made to work here.

[khellang]

What's the status on this? It totally breaks migration scenarios where you're slowly porting things over to project.json, side by side with csprojs.

[mgravell]

@khellang I can't comment on the status, but u did discuss a workaround
approach in my blog series
http://blog.marcgravell.com/2015/11/the-road-to-dnx-part-1.html -
basically, I move the csproj _out_, and reference the files back in via
..\FolderName*__.cs

On Wed, 3 Feb 2016 11:53 Kristian Hellang [email protected] wrote:

What's the status on this? It totally breaks migration scenarios where
you're slowly porting things over to project.json, side by side with
csprojs.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/corefx/issues/4544#issuecomment-179183782.

[thecodejunkie]

While there are workarounds, they are just that - workarounds. I would still like to know if a fix has been created and if it will be released with rc2 ?

Thanks

[livarcocc]

We are not going to allow for folder customizations for v1.

[thecodejunkie]

@livarcocc what does that even mean? This is not about customization, this is the fact that the current implementation _breaks_ the *.csproj tooling if there is a project.json next to it. It's not a feature, it's a bug and one that causes friction for projects that are transitioning / for whatever reason need to support both formats

[davidfowl]

@jasonmalinowski @BillHiebert Can we add an msbuild property that disables project.json detection to allow this hybrid?

The problem is that there's different models:

csproj + project.json

$/Project1/
     Project1.csproj
     project.json

csproj + {ProjectName}.project.json

$/Project1/
     Project1.csproj
     Project1.project.json

xproj + project.json

$/Project1/
     Project1.xproj
     project.json

What this bug is about: csproj + packages.config (or not) transitioning to xproj project.json.

$/Project1/
     Project1.csproj
     Project1.xproj
     project.json

$/Project1/
     Project1.csproj
     packages.config
     Project1.xproj
     project.json

[davidfowl]

@mgravell @thecodejunkie Can you guys try adding <ResolveNuGetPackages>false</ResolveNuGetPackages> to the csproj file to see if that fixes things?

[thecodejunkie]

@davidfowl afraid I can't. We've had to resort to a horrible hack of moving the *.csproj (and related) files into a separate folder as this issue was blocking us. The result is a less than optimal project structure and the need to link all the files into the *.csproj, making it a bit tedious when you add new files (basically add them in your project.json solution and then open the other solution and link them)

[davidfowl]

This issue might be closable now :smile: BTW csproj -> xproj support is coming in Rc2

[sayedihashimi]

@davidfowl using <ResolveNuGetPackages>false</ResolveNuGetPackages> does workaround this issue. But IMO this is not an acceptable place for us to land. New features shouldn't break existing scenarios.

To me this looks like an issue with NuGet not with dotnet/VS. So we should see what @yishaigalatzer thinks here.

After learning about RestoreNuGetPackages to false I put together this MSBuild snippet that looks like it does the right thing.

  <PropertyGroup>
    <!-- default to false here, and enable inside of SetResolvePackages if project.json is a part of the project -->
    <ResolveNuGetPackages>false</ResolveNuGetPackages>
  </PropertyGroup>
  <Target Name="SetResolvePackages" BeforeTargets="BeforeBuild">
    <ItemGroup>
      <_projjsonfile Remove="@(_projjsonfile)" />
      <_projjsonfile Include="@(None)" Condition=" '%(None.Identity)'=='project.json' " />
    </ItemGroup>
    <PropertyGroup>
      <_hasprojjson>false</_hasprojjson>
      <_hasprojjson Condition=" '@(_projjsonfile)'!='' and Exists('%(_projjsonfile.FullPath)') ">true</_hasprojjson>
    </PropertyGroup>
    <PropertyGroup>
      <ResolveNuGetPackages Condition=" '$(_hasprojjson)'=='true' ">true</ResolveNuGetPackages>
    </PropertyGroup>
  </Target>

Why not take this approach inside of Microsoft.NuGet.targets instead of what we have today which is

<ResolveNuGetPackages Condition="'$(ResolveNuGetPackages)' == '' and '$(MSBuildProjectExtension)' != '.xproj'">true</ResolveNuGetPackages>

[yishaigalatzer]

@sayedihashimi in RTM today there are two features available

1. csproj + packages.config
2. csproj + project.json

We prefer project.json because it means that is the natural transition path from packages.config to project.json.

xproj is not in production, so I'm confused when you say new features break old features, that's just a misnomer.

Practically we want a solution where we can easily migrate from csproj + packages.config -> xproj, right?

There are two issues here:

1. nuget.exe restore prefers project.json to packages.config
2. msbuild wants to pickup a lockfile and add references if a lock file is available.

just like how nuget supports project.{projectname}.json, xproj could support the same thing, and game over no more collissions.

[sayedihashimi]

Practically we want a solution where we can easily migrate from csproj + packages.config -> xproj, right?

Yes, that's exactly what we are discussing here. With the existing implementation it makes it more difficult to go from csproj+pkgs.config -> xproj. Ideally users can add a project.json (for the .xproj version of the .csproj) and then use that to go from csproj+pkgs.config -> xproj. With the behavior we have now once project.lock.json is added to the folder where the .csproj is at, the behavior of VS when editing the .csproj is broken.

I think that it's fine to prefer project.json, if it's listed in the .csproj file. In this case the project.json file is not included in the project for the .csproj.

[yishaigalatzer]

@davidfowl and I discussed. We are not going to look into project.json is part of the project or not. The design will be to use {projectname} and make it work in the CLI and NuGet for CLI RTM.

CC @piotrpMSFT

[sayedihashimi]

@yishaigalatzer ok great, glad you guys were able to get something figured out, that is really great news.

Is this the right repo to be tracking this work? If so I'd like to update the milestone to be RTM.

[yishaigalatzer]

Please arrange a design meeting on Monday, we need to figure out what work gets done by CLI, NuGet and Anton

[NickCraver]

What's the status on this? What _should_ we be doing here? This is still a build blocker on porting projects with sanity. I currently can't build with a project.json present unless I move the project/folder structure all over the place.

To explain the frustration, in preview 2 tooling today:
I can't maintain a .NET Core solution and a .csproj solution easily, they have to be put in their own corners. I can't have just one solution because .csproj <-> .xproj still doesn't work, and some projects just can't be project.json. There's not really much of a choice for porting libraries, it's workarounds everywhere...and workarounds I'll have to undo manually later.

The pitch for getting started on project.json now and migrating back to .csproj later is basically "it's okay, you can just upgrade later"...well no I can't, not if I had to move folder structures all around to work around this issue. IMO, this should be much higher priority if we're still waiting many months for everything to go .csproj.

[clairernovotny]

@NickCraver Have you tried using Nuget restore from NuGet 3.5 beta 2? Using that version made restores with mixed project.json and csproj work for me.

[NickCraver]

I have tried with NuGet 3.5.0.1484 (is this Beta 2? VSIX seems to think so), the issue remains. You can easily repro by pulling the core-rtm branch and trying to build StackExchange.Redis.sln (not the .Core solution).
If you build StackExchange.Redis.Core.sln (or any project from dotnet), you'll run into https://github.com/dotnet/cli/issues/1342 which I guess is never getting fixed either. I don't think I'm being unrealistic or unfair in saying the tooling experience is extremely frustrating here.

[yishaigalatzer]

The suggestion is to convert your references to project.json (uwp style) first. Then rename it to projectname.project.json.

We will have a tool to do it automatically in 3.5 rtm.

[thecodejunkie]

Any updates on this? 10 months now :)

[cdrnet]

Any updates? This is still blocking existing multi-platform projects like Math.NET Numerics from supporting .Net Standard (and Core), despite being a perfect fit for the scenario.

[alexandrnikitin]

[tarekgh]

@davidfowl @livarcocc any update about this issue. should this issue get moved to other repro for better tracking?

[davidfowl]

This can be closed now that we have VS2017 tooling previews