Dependency conflict when project.json references csproj

[Eilon]

Moved from aspnet/Mvc#4680
By @pantonis

---

Steps to reproduce

Use the app from https://github.com/pantonis/AspNetRC2EFCore

It is a simple web app (project.json) that references a class library (csproj + packages.config) using this syntax:

  "frameworks": {
    "net46": {
      "dependencies": {
        "ClassLibrary1": {
          "target": "project"
        }
      }
    }
  },

Expected behavior

Everything should compile and run.

Actual behavior

An exception of type 'System.IO.FileLoadException' occurred in Microsoft.Extensions.Configuration.FileExtensions.dll but was not handled in user code

Additional information: Could not load file or assembly 'Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Environment data

dotnet --info output:

N/A

[davidfowl]

/cc @emgarten @yishaigalatzer

This is the problem that happens when we don't read the packages.config as part of the dependency walk.

[pantonis]

Please fix this asap. I think it is a very important bug and the workaround as described by @Eilon in aspnet/Mvc#4680 (comment) is a little bit messy especially when it involves large projects.

I think 99% of the existing projects out there use .csproj class libraries. So there should be a way of smooth transition to asp.net core. I already saw a lot of people complaining about incompatibilities between .csproj and .xproj.

Thanks.

[nemenos]

Yes, please, fix this asap. This bug is blocking us all

[yishaigalatzer]

You should be able to move your class library to use project.json to define dependencies while still maintaining the csproj file, this should unblock you (and give you other goodness).

See:
https://oren.codes/2016/02/08/project-json-all-the-things/

Get Outlook for Androidhttps://aka.ms/ghei36

On Tue, May 24, 2016 at 7:33 AM -0700, "nemenos" <[email protected]mailto:[email protected]> wrote:

Yes, please, fix this asap. This bug is blocking us all

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/dotnet/cli/issues/3205#issuecomment-221290318

[yishaigalatzer]

You can also define the dependencies just like you would do in any asp.net 4 web application you would build

[dmikov]

+1 it is blocking issue for us as well (I can do it in VS, but build server crashes) and no - the wrapper kinda work (didn't for dll, does for project /shrug). Going to try @yishaigalatzer suggestion now.
Well that didn't work, because it automatically switched the project to use xproj, which unfortunately (always catch 22) doesn't support custom tools on grammar files and t4 templates, so no code generated as a result.

[amcdnl]

+1 Blocker for me

[ghost]

This is blocking us as well. New application xproj wants to consume three csproj-based libraries which are not maintained by us as they live in our code-base as git submodules. So where changing the dependency lib projects is not an option, the new project system is off the table?

First:

dotnet restore fails Unable to resolve 'csproj-based-project-name' for .NETFramework, Version=v4.5`` see #6224: same for 4.5.1, 4.5.2, 4.6, 4.6.1.

Then:

dotnet run/build fails fails error NU1001: The dependency csproj-based-project-name could not be resolved.

All this is happening in CLI.

From VS, the whole solution compiles and project runs.

[guardiannite]

+1 Would like fix. The work-around is working for me, except I don't get any intellisense for my project references. o.O

[kt215]

+1 Blocker

[rrelyea]

Tracking as NuGet issue.

[sayedihashimi]

@rrelyea what's the NuGet issue?

[joelverhagen]

@sayedihashimi, NuGet/Home#2865.

[yishaigalatzer]

@dmikov moving to project.json next to the csproj doesn't move you to xproj. It is only used to define the nuget package dependencies.

If you can share your project here (or [email protected]), and we can try converting it for you.

[ghost]

@yishaigalatzer, we are using libraries as submodule which we don't own. So getting every upstream repo owner to agree on having project.json for our use-case with all of their csprojs is not a viable option and expensive thing to achieve, especially when everything is building with VS just fine.

This seems very much like a dotnet cli bug or one of its constituents.

[tomten]

Are there any non-project.json workarounds for this?

We have a simple ASP.NET Core RC1 web application (with csproj dependencies) that builds and publishes fine using msbuildand dnu, but that we cannot upgrade to ASP.NET Core RTM if there is no way to do command-line builds.

I'm on Windows, so any workaround requiring nugetand msbuildis fine.

[tessierp]

Any solution for this problem? I'm using the latest and still cannot do a dotnet restore with csproj based projects.

[gmartinezsan]

Hitting this too. Any news?

[yishaigalatzer]

I wouldn't expect progress on this until we make the move to msbuild

[bandito22]

+1

Seems like a pretty fundamental requirement!

[RussKahler]

+1 This is a blocking issue for us too.

[matthieupetite]

+1 this is a blocking issue for use... any workaround ??

[RussKahler]

I have no work around at this time. This is a blocking issue and has been since we upgrade to 1.0.0 in June. I have no way to get my CI server running.

Russ

From: mat4oppia [mailto:[email protected]]
Sent: Monday, October 17, 2016 5:02 AM
To: dotnet/cli [email protected]
Cc: Russell Kahler [email protected]; Comment [email protected]
Subject: Re: [dotnet/cli] Dependency conflict when project.json references csproj (#3205)

+1 this is a blocking issue for use... any workaround ??

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/cli/issues/3205#issuecomment-254165536, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVs7TOxKGwGd6koc_KV7iXu_ayaDMcGSks5q00e0gaJpZM4Ikz13.

[IngbertPalm]

Have a look at Scott Hanselman's blog. Maybe this can help you.

[RussKahler]

My solution builds in Visual studio just fine. It does not build on the my tfs 2015 build server using a new build agent. I am using the Visual Studio build task and it fails saying it cannot resolve the csproj projects. See attached image. The Server.API is my xproj whil the unresolved projects are the csproj.

[cid:[email protected]]

Russ

From: Ingbert Palm [mailto:[email protected]]
Sent: Monday, October 17, 2016 8:37 AM
To: dotnet/cli [email protected]
Cc: Russell Kahler [email protected]; Comment [email protected]
Subject: Re: [dotnet/cli] Dependency conflict when project.json references csproj (#3205)

Have a look at Scott Hanselman's bloghttp://www.hanselman.com/blog/HowToReferenceAnExistingNETFrameworkProjectInAnASPNETCore10WebApp.aspx. Maybe this can help you.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/cli/issues/3205#issuecomment-254209191, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVs7TJOZiJdwz8tD_oFwEOrlCdyGWw6Zks5q03nrgaJpZM4Ikz13.

[IngbertPalm]

Don't use the Visual Studio build task. Use the msbuild task.
Also don't select the option to restore the nuget from within the task. It's deprecated.
Use a dedicated nuget restore task.
It's also important to use nuget version 3.4.4 or higher.

[RussKahler]

We have the 3.5 version of nuget downloaded. I have a dedicated new task in place running that version of nuget. I will try changing my build task.

Russ

From: Ingbert Palm [mailto:[email protected]]
Sent: Monday, October 17, 2016 9:10 AM
To: dotnet/cli [email protected]
Cc: Russell Kahler [email protected]; Comment [email protected]
Subject: Re: [dotnet/cli] Dependency conflict when project.json references csproj (#3205)

Don't use the Visual Studio build task. Use the msbuild task.
Also don't select the option to restore the nuget from within the task. It's deprecated.
Use a dedicated nuget restore task.
It's also important to use nuget version 3.4.4 or higher.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/cli/issues/3205#issuecomment-254217963, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVs7THiiMij0T_lAuXaWzPJ47pHsq84zks5q04GigaJpZM4Ikz13.

[ad-ab]

I am not sure if my input will be helpfull or not, but we also strugled with getting our build server to build a solution with xprojs referencing csprojs in the same solution. From what we gathered on the internet there was a solution of installing visual studio on the build machine which we didn't want to do.
In the end we managed to get the build server to restore packages and build correctly.

We use TeamCity, but i suppose the core of the issue is the same.
We use nuget restore. Nuget version 3.5.0 - rc1.
We actually use visual studio build option in TC.
and we HAD TO elevate rights to the user account running the builds.

Hope this helps

[RussKahler]

I have to run a dotnet restore via a powershell command after the nuget restore as my xproj do not get a project.lock.json file and my msbuild errors out with an error suggesting to run the dotnet restore. the problem is, the dotnet restore does not resolve the csproj files and the build does not resolve the csproj types.

[pgatilov]

For all struggling with the Unable to resolve 'csproj-based-project-name' for '.NETFramework, Version=vX.X' issue, please make sure

1. you use nuget 3.4.4 (as per Scott Hanselman's post) or 3.5.*
2. you run nuget restore <.sln file path>

Running msbuild afterwards should succeed.

You should not need to run dotnet restore, because nuget should write correct project.lock.json.

Simply running nuget restore in a xproj file folder does not work, because it tries to restore packages for the project only and does not see other projects. Seems like a different command is triggered.

We have this simple sequence running on CI server just fine. Using nuget 3.5.0.1737 (aka 3.5.0-rc.1) + ASP.NET Core 1.0.1, targeting .NET 4.6.1. Our xproj references several csproj. Not sure if it works if you have a more complicated case like xproj -> csproj -> xproj.

It's extremely confusing that there seems to be no place that explains this carefully. Hope it helps.

[matthieupetite]

Hello pgatilov... thanks for the advice I will try that on my build server today and check that my nuget version is ok.
Meanwhile we succeed to enable the build on the TFS Build agent by using the dotnet restore restore.dg stuff but it's a bit tricky as we need to manage the build configuration. For that we use a PowerShell script that update the project.fragment.lock.json on the fly.

Here is the script if someone need that:

`$content = gc -Path "./build/project.fragment.lock.json.token"
$content = $content.Replace("BUILDCONFIGURATION", $env:BuildConfiguration)
sc -Path ./project.fragment.lock.json -Value $content

dotnet restore restore.dg
dotnet build`

We add a directory in the .net core web site which contain that script and a project.fragment.lock.json.token which is a copy of the projet.fragment.lock.json augmented with a BUILDCONFIGURATION token.

Hope it helps...

[matthieupetite]

Hello I've just finished my test... IT COMPILE :) thanks an lot pgatilov

[RussKahler]

Do I have to get rid of all package.config files or can I have my csproj using package.config and my xproj using project.json. I thought that last time I ran just a nuget.exe restore (my sln file) that I did not get project.lock.json files in my xproj folders.

Russ

From: Pavel Gatilov [mailto:[email protected]]
Sent: Tuesday, October 18, 2016 12:00 AM
To: dotnet/cli [email protected]
Cc: Russell Kahler [email protected]; Comment [email protected]
Subject: Re: [dotnet/cli] Dependency conflict when project.json references csproj (#3205)

For all struggling with the Unable to resolve 'csproj-based-project-name' for '.NETFramework, Version=vX.X' issue, please make sure

1. you use nuget 3.4.4 (as per Scott Hanselman's post) or 3.5.*
2. you run nuget restore <.sln file path>

Running msbuild afterwards should succeed.

You should not need to run dotnet restore, because nuget should write correct project.lock.json.

Simply running nuget restore in a xproj file folder does not work, because it tries to restore packages for the project only and does not see other projects. Seems like a different command is triggered.

We have this simple sequence running on CI server just fine. Using nuget 3.5.0.1737 (aka 3.5.0-rc.1) + ASP.NET Core 1.0.1, targeting .NET 4.6.1. Our xproj references several csproj. Not sure if it works if you have a more complicated case like xproj -> csproj -> xproj.

It's extremely confusing that there seems to be no place that explains this carefully. Hope it helps.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/cli/issues/3205#issuecomment-254406995, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVs7TIq71NH2jR-BA__EqnvCk4ss8caEks5q1FJZgaJpZM4Ikz13.

[pgatilov]

Our xproj uses project.json, csproj use package.config. No issues.

[RussKahler]

Well I have made some progress. I found that the nuget restore task provided in the build process task list does not specify which nuget.exe to use. We have the 3.5 nuget.exe in our .nuget folder in our solution but the build task was not using. In digging through the logs I found the task was using a nuget.exe that was downloaded with my build agent. In the build agent folder (..)\Agent\Worker\Tools there was a nuget.exe that was version 3.2.2 which does not use the project.json files. After updating this nuget.exe my xproj project.json are now building project.lock.json. Now my projects referencing my csproj files are now working and building. I still have an issue with a xproj that needs to run a gulp task post build is not doing so. Need to research that now.

Thanks everyone for your help.

[rashadrivera]

Hello All,

Has this issue been resolved? It is very hard to understand what steps we need to implement to just get a Hello World style ASP.Net Core app to reference a .Net Framework 4.x assembly. If possible, could someone confirm resolution and/or give use a concise list of steps?

Thanks again.

[davidfowl]

It'll be fixed when we move the project files back to csproj.

[RussKahler]

rashadrivera,
If you look at pgatilov Oct 17 answer and mine from Oct 18. There are two keys to get the compiling to work on your build server.

1. you need to manually run the nuget.exe restore before you compile on the build server. See the Oct 17 discussion on that.
2. See my answer on the Oct 18. the build agent downloaded onto your build server is probably an older version of nuget.exe (should be in your Agent install folder ..\Agent\Worker). Mine which I setup in Sept of this year still had a nuget.exe that was versioned 3.2.1 which is before the version mentioned above that correctly resolves .csproj projects.

[Alezis]

We get stuck with the same issue. Our ASP.NET Core app (Web API) references csproj (shared library that used by client).
And we get the same issue on TFS 2015 build server.
I read everything in this thread and others, tried various workarounds, but nothing works.
On build server I updated Nuget.exe to 3.5.0.1938. When I run 'nuget.exe restore [My Solution file.sln]'
got "classic" 'Unable to resolve '' for '.NETFramework,Version=v4.6.1'.' The same error when I execute it via build step in build definition. Some folks mentioned that nuget 3.5 should work, but not in my case. So question is what I do wrong ? Should it work or not ?

I know about this bug NuGet/Home#2865, but don't quite understand: is it closed ?

These days restoring via msbuild is working for me. It deprecated (as I found somewhere), but it works for me.

[pgatilov]

@Alezis you should run nuget restore <.sln file path>. Just running nuget restore does not work.

See https://github.com/dotnet/cli/issues/3205#issuecomment-254406995

[Alezis]

@pgatilov. Sorry, I new on github. Due to formatting my comment missed [My Solution file.sln]. Fixed.
Obviously, I run with sln file specified.

[Alezis]

Just tried NuGet 3.4.4 and 3.5.0 against my sln file. Same result.

My ASP.NET Core API includes these csproj files as follows:

"frameworks": {
        "net461": {
            "dependencies": {
                "MySDK": {
                    "target": "project"
                },
                "MyWeb.API.Models": {
                    "target": "project"
                }
            }
        }
    },

[pgatilov]

@Alezis, that's weird, it should work. Does the sln file contain those referenced projects? Does your xproj contain them? Ours has

  <ItemGroup>
    <ProjectReference Include="..\Project1\Project1.csproj" />
    <ProjectReference Include="..\Project2\Project2.csproj" />
    <ProjectReference Include="..\Project3\Project3.csproj" />
  </ItemGroup>

(names replaced). So, the referenced projects are present both in project.json, and in .xproj. Might be important. I would recommend using Add Reference dialog in VS to correctly reference projects.

[Alezis]

@pgatilov, I checked and didn't find all those references in my xproj files. I added it manually and NuGet 3.5 restored everything without errors. Thanks for help.

We are using only VS 2015 (c 14.0.254431.01 Update3) to manage project files.
Just tried add some extra csproj to the same xproj and found that project.json was updated, but xproj was not. It looks project.json is updated once I added my reference, but xproj is not updated. Sometimes it updates once I hit "Save All" in VS, but sometimes - not. Some issue with keeping both files in sync here.

[Alezis]

I got another issue. Interesting thing. I have following project graph

xproj1->xproj2->csproj1 and csproj2

xproj1 - are unit tests for our asp.net core (xproj2). As suggested @pgatilov I have edited xproj2 and added references to csproj1 and csproj2. Now when I run nuget.exe restore [my.sln] I got error that xproj2 is not resolved. I did the same for xproj1 and added ref to xproj2:
<ItemGroup> <ProjectReference Include="..\..\..\MyWeb.API\MyWeb.API.xproj" /> </ItemGroup>
And nuget restored packages, but now VS 2015 can't build this project.
I got this error:
1> C:\Program Files\dotnet\dotnet.exe build "D:\MyProj\Tests\Unit Tests\MyWeb.API.TDD" --configuration Debug --no-dependencies 1>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets(262,5): error : Object reference not set to an instance of an object.
How to resolve this ?
Is is acceptable to reference xproj from xproj ?
(project.json is targeting everywhere net461)

[RussKahler]

Yes, we do that same thing. in our solution. We have xunit tests that reference our xproj which in tern references csproj. Couple of things to make sure.

• Your csproj should only reference .Net system references and nuget packages. You cannot use directly assembly references at all.
• Don't worry about build server until you get VS to build
• open a cmd prompt in the xproj folder and run dotnet build command there. sometimes you will see more details that way then what VS is providing.
• remove references and put them back one at a time so you know what the problem project is.

[mikael0hlsson]

I had the same problem moving from project.packages to project.json. Solved it with the help of pgatilov comment above. Removed the project from the solution then re-added it. Thanks alot!