I was asked to list some pain points to updating to PackageReference

[bradphelan]

https://twitter.com/adgrv/status/915682007664824320

Package Reference

Note we have a very large solution with 50 sub projects. The main point is the unbearable slowness and continual stalling of visual studio 2017 during restore operations.

This is the number one pain point. Every time a small change is made to a project file VS2017 stops the world and starts "restoring packages" and then after that is done it stalls again to update some UI state. At this time VS is unusable. The editor and all UI is blocked. This should not happen.

The worst is if updating a nuget package from version A to version B. If the nuget package exists in 30 projects it seems that nuget restore is run 30 times instead of at the end. It is faster to pull up VIM and do a search and replace over 30 csproj files, updating the version from within the package reference tags then manually trigger a package restore, dump the solution from VS and reload than to rely on VS to manage it.

My guess is that there are listeners triggered on changes to each project file and as each project file is updated VS goes boom and runs a full reload and then for the next project and so on instead of waiting for the full update to pass.

I suggest

(1) Ensure that all package restore is done on a background thread (2) Ensure that batch operations disable package restore until the operation is over.

SDK Projects

First point is that SDK projects relative to old projects are beautiful to behold. Finally a build file for humans. Nice work. Of course it feels half done as only dot net core/standard got the full love. Our application is a desktop WPF app ( legacy ?? ). I have found work arounds

https://github.com/aienabled/WpfNetStandardSample

but that took a while of googling to discover and there is a core bug in visual studio that makes even this work around problematic. That issue is listed here

https://github.com/aienabled/WpfNetStandardSample/issues/1

My biggest wish would there to have been an automatic upgrade or at least a hand holding wizard that would neatly arrange and format the new SDK format for us. Desired features

(1) Identify transitive references and eliminate (2) No redundant ItemGroups and empty tags #makehumanreadable (3) Result should be sorted #makehumanreadable

Some of the above I have done with some VIM macros but it's still mostly manual work.

CLEAN doesn't CLEAN

Right click rebuild on a project doesn't delete the obj directory. When making large scale changes to the project file, things seem to get out of sync with what is in the obj directory. I'm not sure what it is but sometimes the project will compile when it shouldn't and vice versa. A

gci -rec -filter obj | rm -rec -force

cleans that up but it shouldn't be necessary.

[BrunoJuchli]

The missing WPF support and swallowed build errors are blockers for us, too. Our solution has 59projects, 4 of them WPF, 1 console application and the rest are libraries.

I'd be fine with manually converting the project, as we have quite some build customizing going on, and with the new Directory.Build.props / .targets we'll most likely modify that, too - thus we'll have to touch the project files, too. I envision that our csproj files will basically all be identical but for the Package and Project references.

[bradphelan]

@BrunoJuchli The workaround for missing errors support is https://github.com/aienabled/WpfNetStandardSample/issues/1#issuecomment-334165102

[rohit21agrawal]

@bradphelan - we are currently investing our resources into making the transition from packages.config to packageReference easier for developers by building a tool and solving existing ecosystem problems. Here is the tracking bug for this : https://github.com/NuGet/Home/issues/5877 . The tmp_proj compilation issue that you are having is also being actively worked upon by @nkolev92 .

I would also like to clarify that it is possible to have PackageReferences in your project without your project being a NETCore SDK based project. Here is an example of such a project in NuGet's repository itself : https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Clients/NuGet.Console/NuGet.Console.csproj

[bradphelan]

@rohit21agrawal Thanks for the pointers. However we extensively use ReactiveUI.Fody and for some reason they claim that they can't support old style csproj with new style PackageReference .

https://github.com/Fody/Fody

So I've taken the deep dive and converted everything. I'm about 50% done. It's slow work but the results I think are worth it.

[rohit21agrawal]

we will reach out to them to see what's blocking them from working on old .csproj format with new PackageReference style.

Until then, please keep the feedback coming so we can make this transition as seamless as possible :)

[bradphelan]

Another friction point. Intellisense in csproj file. It's great that we get intellisense for nuget packages but it is missing for project references. Also the matching should be fuzzy and case insensitive as I don't always remember the exact name of a package.

[bradphelan]

Another point. Globbing and dependencies is hard to figure out. See this question I have asked

https://stackoverflow.com/questions/46584499/how-to-add-a-glob-for-resx-files-for-new-sdk-csproj-file

[davidfowl]

Most of these other complaints have nothing to do with package reference specifically...