Nuget Package should not add relative paths in csproj imports

[shmao]

@mrchief reported issue https://github.com/dotnet/roslyn/issues/9390

When a NuGet package has a .props file in its \build folder, NuGet manager add a Import entry in .csproj file and the entry looks like below,

<Import Project="..\packages\Microsoft.Net.Compilers.1.1.1\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.1.1.1\build\Microsoft.Net.Compilers.props')" />

The Import entry uses relative path. This does not work when the project is built outside of Visual Studio and especially when a build.proj file (outside of source folders) is used instead of .sln file, for example,

root
  -- src
      -- projA
      -- projB
      repo.sln
  build.proj

In the example, the build.proj is in a different location than repo.sln's.

Perhaps a better solution would be to use $(SolutionDir) in the Import entry.

[yishaigalatzer]

When projects are moved around, adding relative paths no longer work, but also $solutiondir might not work.

The solution for this issue is to move to use project.json based projects instead of packages.config, where all packages are placed in a global packages folder.

[yishaigalatzer]

Closing this as by design (although I agree the design of changing your project when you install a nuget package is unfortunate)

[roalz]

I wish I could just "close by design" my bugs in the face of my customers... Wouldn't it be ok to replace relative paths with a macro/variable (i.e. NugetPackagesDir), and maybe set it the same as $(SolutionDir) by default?

[xperiandri]

Any changes? What about adding options to choose from? Is this feature very complicated to implement?

[yishaigalatzer]

We are not investing in this area, moving to a transitive restore, resolves this issue and since that is the way forward all our efforts go there.

[mrchief]

What is a "transitive restore" and how does it fix this issue? Just curious!

[harikmenon]

Here you go. Here is a primer about it http://docs.nuget.org/consume/ProjectJson-Intro . Transitive restore is a feature of project.json which is the new way of managing dependencies using NuGet. We will also be releasing a tool in the very near future that will enable you to upgrade your packages.config project to project. json.

[mrchief]

This is just the way new core projects work (picking up refs and using folders as project, so everything flows seamlessly). How does this fix the issue for existing csproj based projects?

[harikmenon]

Almost all msbuild based projects like csproj can move over to project.json in VS 2015 and above and get it to work. Here is a detailed walk through of the steps required to do so

https://github.com/NuGet/Home/wiki/Converting-a-csproj-from-package.config-to-project.json

project.json way of managing dependencies is not limited to net core projects. Let me us know if you need more info.

[mrchief]

That is a welcome change. I didn't know about that until now. Thanks for pointing it out!!

The biggest ones are the MVC/Web API/Web Forms applications that pull in dependencies like jQuery, or expect nuget packages to modify web.config automatically for them.

This is a great relief at least for stuff like jQuery. I already started using gulp/bower/cdn for managing libs like jQuery/bootstrap etc but existing packages bringing them again n again was plain annoying. I'm glad for this feature not working in the latest! :smile:

Now, how does packages that bring in other stuff like BCL build or XDT transforms etc. going to work? Does it mean that until their authors adopt to new system, the end users are effectively blocked from moving to new project.json format?

[xperiandri]

That is cool! So which types of projects are supported? WPF? WinRT? Windows Phone? In a sample framework assemblies are referenced in csproj. Is it still the same?

[harikmenon]

@mrchief : XDT transforms on content files should work, it just wont change your app.config or web.config or any other files already in you project. Source and content files can be added to your build using content files, it just wont get physically added to your project. Essentially our promise is to not modify files in your project. @xperiandri : per spec

https://github.com/NuGet/Home/wiki/NuGet-Upgrader:-Helping-to-move-to-NuGet-3.0

WPF WinForms Console App Class Libraries PCLs Windows Service VS Extensibility Test Web (ASP.NET 4) Android iOS Office Projects VS Extensibility WCF Workflow Test

not looking into bringing in support for

Windows 8.1 Store and Phone Silverlight Lightswitch

[harikmenon]

Let us know if you have any feedback on the list.

[mrchief]

@harikmenon Thanks for taking time to answer these. Few more questions and bear with me if these are already addressed in docs.

XDT transforms on content files should work,

Those are usually done via MSBuild targets that get added to csproj files.

Essentially our promise is to not modify files in your project.

So how will those get setup?

it just wont change your app.config or web.config or any other files already in you project

So if I have a version x of a package which does that currently, going forward, in the new system, how will version x work? I mean who will make the changes in the config files?

[harikmenon]

The package needs to document the necessary details and the consumer will have to modify those changes.

[roalz]

Does this "transitive restore" and project.json work for native C++ projects (vcxproj) ?

[mrchief]

The package needs to document the necessary details and the consumer will have to modify those changes.

Ouch! :smile:

[xperiandri]

@harikmenon, could you explain how will be changed a project model according to this post on MSDN blog. Because this paragraph adds a lot of questions.

Q4 2016 / Q1 2017 This will be the first minor update, mainly focused on replacing .xproj/project.json with .csproj/MSBuild. Project format update should be automatic. Just opening a 1.0 project will update it to the new project format. There will also be new functionality and improvements in the runtime and libraries.

[harikmenon]

The long term plan is to move package dependencies into the project file. There will only be a single PackageReference entry and no duplicated data. This does not change our assertion around adding content files directly in the project and modifying it. Does that help? We are still figuring out the right path to get our customers there.

[xperiandri]

So you mean that moving to project.json will be beneficial any way as then it must be automatically converted into a new model because whatever it will be as the new model will provide the same approach of dependency specification and resolving. Is this correct?

[harikmenon]

Yes. Possibly with more features since we will be part of MSBuild and that supports things like conditional references.

[harikmenon]

To be clear packages.config is not equivalent to project.json since there are fundamental differences here. MsBuild way of managing dependencies will be a evolution of the project.json method.

[xperiandri]

I tried to use project.json within portable library but got error: error : Your project is not referencing the ".NETPortable,Version=v4.5,Profile=Profile75" framework. Add a reference to ".NETPortable,Version=v4.5,Profile=Profile75" in the "frameworks" section of your project.json, and then re-run NuGet restore. Although I do

[xperiandri]

Is it possible to build a NuGet package from csproj with project.json?

[ChristophHornung]

Since the project.json format seems to be abandoned or at least not the default in Visual Studio 2017 will this be re-opened?