New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASP.NET PackageReference Migration #860

Closed
AdamCaviness opened this Issue May 8, 2018 — with docs.microsoft.com · 13 comments

Comments

Projects
None yet
7 participants
Copy link

AdamCaviness commented May 8, 2018 — with docs.microsoft.com

I have the newly minted VS 15.7 and you did a fine job on the built-in migration tool. It worked great for class libraries and desktop projects. I'm looking forward to migrating ASP.NET projects ASAP. Thanks!


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@seangwright

This comment has been minimized.

Copy link

seangwright commented May 9, 2018

@AdamCaviness PackageReference should work fine in traditional full framework ASP.NET projects. I've converted many Web Forms apps from packages.config to PackageReference.

What currently is not supported is converting full framework ASP.NET apps to the new VS2017 project system (an SDK project). See more here dotnet/project-system#2670.

I have a lot of class library projects running on .NET 4.6.1 using the SDK .csproj format working nicely with my .NET 4.7.1 ASP.NET Web Forms projects using PackageReference.

I did these migrations before the tooling was available in VS using this VS extension https://marketplace.visualstudio.com/items?itemName=CloudNimble.NuGetPackageReferenceUpgrader.

@AdamCaviness

This comment has been minimized.

Copy link
Author

AdamCaviness commented May 9, 2018

@sgwatgit Thanks, you explain that pretty nicely. I wrote the feedback having already converted with the VS extension you mention. It did a pretty good job (the attribute syntax is different than the element syntax that the VS migration tool uses but no-big-deal). I backed out of the extension-based conversion because the VS 15.7 PackageReference integration gives such a nice experience with both the auto-removal of nuget packages and UI hints via References in SolutionExplorer. Because I'm new to ProjectReference, I backed out of that PackageReference conversion not knowing how soon the VS ASP.NET PackageReference migration may get baked in. I think after your suggestion I'll revisit it and commit to using the extension and just ignore the VS sugar. Thanks again.

@jemiller0

This comment has been minimized.

Copy link

jemiller0 commented Jul 11, 2018

When will migration to PackageReference in Visual Studio 2017 officially be supported? It is a major oversight and a major hassle having to deal with packages.config's DLL hell. Or at least provide instructions on how to do so manually. One should not have to rely on a third party extension to do this. The last time I created new .NET Framework library and console application projects which was just a few days ago, it was still not using PackageReference by default. I would like to see more attention paid to the full .NET Framework. Not everyone is using .NET Core. packages.config is a total pain. Especially when you are using packages like EF Core which pull in a ton of dependencies.

@cremor

This comment has been minimized.

Copy link

cremor commented Jul 12, 2018

@jemiller0 Visual Studio 2017 15.7 does offer official support for migration to PackageReference. You don't need an extension for that. See the documentation linked in the initial comment of this issue.

You can also configure Visual Studio to use PackageReference by default for new projects. Just change the setting in Tools - Options - NuGet Package Manager.

@jemiller0

This comment has been minimized.

Copy link

jemiller0 commented Jul 12, 2018

I somehow left out that what I was talking about is support for PackageReference in ASP.NET/.NET Framework projects. I already have it working for my other projects. Thanks for the info about being able to set the default.

This comment has been minimized.

Copy link

NicolasDorier commented Jul 31, 2018 — with docs.microsoft.com

The way I migrated my ASP.NET project to PackageReference is by making VS think it is a project library.

  • Open the csproj
  • Replace the ProjectGuid by <ProjectGuid>{7C796B6B-86B5-4C57-ADAA-12CF1FECDA71}</ProjectGuid> and remove ProjectTypeGuids
  • Now right click on reference, you should be able to migrate
  • Put back the previous ProjectType and ProjectTypeGuids

Enjoy!

This comment has been minimized.

Copy link
Contributor

Thieum commented Aug 6, 2018 — with docs.microsoft.com

@NicolasDorier - the problem with this, is that some packages won't play well on reinstall, aren't they ?

Microsoft.CodeAnalysis.Analyzers v1.1.0
install.ps1 script will be ignored when the package is installed after the migration.

Microsoft.CodeDom.Providers.DotNetCompilerPlatform v1.0.8
install.ps1 script will be ignored when the package is installed after the migration.
'content' assets will not be available when the package is installed after the migration.
XDT transform file 'content\net45\web.config.install.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net45\web.config.uninstall.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net46\web.config.install.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net46\web.config.uninstall.xdt' will not be applied when the package is installed after the migration.

Newtonsoft.Json v9.0.1
install.ps1 script will be ignored when the package is installed after the migration.

This comment has been minimized.

Copy link
Contributor

Thieum commented Aug 6, 2018 — with docs.microsoft.com

Latest version seems to pop warnings still:
Microsoft.CodeAnalysis.Analyzers v2.6.1
install.ps1 script will be ignored when the package is installed after the migration.

Microsoft.CodeDom.Providers.DotNetCompilerPlatform v2.0.0
install.ps1 script will be ignored when the package is installed after the migration.
'content' assets will not be available when the package is installed after the migration.
XDT transform file 'content\net45\app.config.install.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net45\app.config.uninstall.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net45\web.config.install.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net45\web.config.uninstall.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net46\app.config.install.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net46\app.config.uninstall.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net46\web.config.install.xdt' will not be applied when the package is installed after the migration.
XDT transform file 'content\net46\web.config.uninstall.xdt' will not be applied when the package is installed after the migration.

@NicolasDorier

This comment has been minimized.

Copy link

NicolasDorier commented Aug 7, 2018

@Thieum yes, but these are the limitation of the PackageReference system. You can see more info here.

@jemiller0

This comment has been minimized.

Copy link

jemiller0 commented Aug 7, 2018

I really wish Microsoft would get this fixed. Not all of us are using .NET Core, or are going to be anytime soon. I'm tired of .NET Framework users being treated as second-class citizens. packages.config is total pain. IMHO, Microsoft should put more resources to solving this. Meanwhile, they are off working on any number of less important features. That's fine, but, fundamental issues like this should be focused on first.

@NicolasDorier

This comment has been minimized.

Copy link

NicolasDorier commented Aug 8, 2018

Problem is that .NET Framework feel the weight of years of backward compatibility.
.NET Framework has the reputation, of being rock solid on time. I am quite sure a project I developed on .NET 2.0 would have no problem to get migrated (maybe even compile fine!) on Visual Studio 2017.

This is an important achievement for businesses whose software will run for decades when the former developers left the company. This is impressive achievement if you ask me.

.NET Core has none of those issues.
That said, I wish I will never have to touch .NET Framework again, long life to .NET Core!

@jemiller0

This comment has been minimized.

Copy link

jemiller0 commented Aug 14, 2018

Any word on when this will be officially supported? I see that VS 15.8 is out and I see no mention of it. It seems like Microsoft is adding all kinds of other whizbang features and ignoring fundamentals like this. packages.config is a total pain. Please fix this.

@karann-msft karann-msft added the Feature label Aug 16, 2018

@karann-msft

This comment has been minimized.

Copy link
Collaborator

karann-msft commented Aug 16, 2018

All of this is good feedback. Please use this issue NuGet/Home#5877 for product feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment