[Discussion] Installation Error when using NuGet's packages.config file

[mrdnote]

Hi, I wanted to give this package a try but during installation VS gives met this error:

Could not install package 'Nullable 1.1.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.7.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

[manuelroemer]

Hey, thanks for trying out the package!
This error probably occurs because your project is using a packages.config file for referencing NuGet packages. This file doesn't support some .nuspec features which I use for creating the Nullable package.

If that is the case, is it possible for you to upgrade your project to package references? VS 2019 (maybe earlier versions too) has a built-in conversion tool for that:

Please tell me if you cannot upgrade from the packages.json file, because in theory, it is possible to support the nuget.config file. So far, I have actively decided against it, because it has one ugly flaw: The attribute file then gets added to the project which I don't really like from a user perspective (see the image). But I am open for discussion, depending on the demand for it.

[manuelroemer]

Either way, I should have documented that one needs to use package references at the moment. Will do that later - thanks for raising this issue!

[mrdnote]

Thanks for the reply! I feel that, if a package is in the nuget gallery, the package should install whether using packages.json or package references. Can't you support both? Anyway, I will try to add the project to my solution.

[manuelroemer]

It is possible to support this, but there are also problems that come with it.

For one, if the package gets installed into a project with a packages.config file, this happens:

As you can see, the file gets added to the other project files i.e. it actively modifys the project and will always be visible to the user of the package.
For reference, here is a project which uses package references - the file doesn't get (visibly) added to the project here:

Also, if somebody deletes this file/folder, it will not be replaced via NuGet restore. Once downloaded, it will always have to stay there and will not be modified by any NuGet operation again, except when the package gets updated with a new Nullable.cs version.

This opens up a few questions:

1. Is packages.config really going to be used that often? After all, package references are the future - .NET Core and Standard uses them and "legacy" projects can use them too. To me, this seems to be the way to go.
2. Why use the package, if the file could just be copy&pasted manually?
3. Is it okay for you (and other users) if a "random NuGet package" suddenly adds files to your project? I personally wouldn't really like this.
4. How can it prevented that the package gets deleted by somebody who thinks that NuGet will just restore it?

Possible Solutions

I see two ways to solve this:

1. Don't support packages.config
This is what I have settled on so far - I don't really see any benefit from supporting it. But again, if this is a requirement, we may find a solution.
If this continues being unsupported, it must be documented though - here on GitHub and on nuget.org. Otherwise this can be really confusing.

2. Add the file to the project
As described above, the file would simply get injected into the project files.

What are your thoughts on this? Ideally, there'd be more people having a vote on this, but since this package is brand new and not very known so far, there are not going to be many views on this issue.

[mrdnote]

For what it's worth, I'm used to packages.config files being added to the project and I couldn't care less. If this is what the project needs to build, fine. But maybe I'm missing your point... Dave

…

On Mon, 30 Sep 2019 at 23:56, Manuel Römer ***@***.***> wrote: It is possible to support this, but there are also problems that come with it. For one, if the package gets installed into a project with a packages.config file, this happens: [image: grafik] <https://user-images.githubusercontent.com/30902964/65918984-5c749d00-e3db-11e9-84d0-6244f114349d.png> As you can see, the file gets added to the *other* project files i.e. it actively modifys the project and will always be visible to the user of the package. For reference, here is a project which uses package references - the file doesn't get (visibly) added to the project here: [image: grafik] <https://user-images.githubusercontent.com/30902964/65919296-271c7f00-e3dc-11e9-95f9-752ca41697ca.png> Also, if somebody deletes this file/folder, it will *not* be replaced via NuGet restore. Once downloaded, it will always have to stay there and will not be modified by any NuGet operation again, except when the package gets updated with a new Nullable.cs version. This opens up a few questions: 1. Is packages.config really going to be used that often? After all, package references are the future - .NET Core and Standard uses them and "legacy" projects *can* use them too. To me, this seems to be the way to go. 2. Why use the package, if the file could just be copy&pasted manually? 3. Is it okay for you (and other users) if a "random NuGet package" suddenly adds files to your project? I personally wouldn't really like this. 4. How can it prevented that the package gets deleted by somebody who thinks that NuGet will just restore it? Possible Solutions I see two ways to solve this: *1. Don't support packages.config* This is what I have settled on so far - I don't really see any benefit from supporting it. But again, if this is a requirement, we may find a solution. If this continues being unsupported, it *must* be documented though - here on GitHub and on nuget.org. Otherwise this can be really confusing. *2. Add the file to the project* As described above, the file would simply get injected into the project files. What are your thoughts on this? Ideally, there'd be more people having a vote on this, but since this package is brand new and not very known so far, there are not going to be many views on this issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=ABK6FKA3ICLZUTZJDXXE6YLQMJYYVA5CNFSM4I37MBCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD77HHCY#issuecomment-536769419>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK6FKDNT5Y3KGCIVIK7F2DQMJYYVANCNFSM4I37MBCA> .

-- Tel / WhatsApp: +31 6 38293316 Email: [email protected] Web: www.dnote.nl Facebook: www.facebook.com/DnoteSoftware

[manuelroemer]

My point is basically to explain why packages.config is not supported so far and to spark discussion on whether that should change.

If this is what the project needs to build, fine.

That's good to hear though - if you are fine with not using packages.config, I'd rather not do an update of the package at the moment and instead listen if there are others who also report this problem.

I will leave this issue open so that others can still leave their thoughts on this topic. If there is enough feedback, I will go ahead and make the jump to support packages.config. But I need more people who need this before making this change (after all, support for packages.config will have to stay forever to not cause breaking changes).

Thank you again for your feedback, it is very much appreciated!

[mrdnote]

If this is what the project needs to build, fine.

I was referring to files being added to the project :) You're right, let's see what other people think. When I have some time, I will try out using package references. Dave

…

On Tue, 1 Oct 2019 at 10:48, Manuel Römer ***@***.***> wrote: My point is basically to explain why packages.config is not supported so far and to spark discussion on whether that should change. If this is what the project needs to build, fine. That's good to hear though - if you are fine with not using packages.config, I'd rather not do an update of the package at the moment and instead listen if there are others who also report this problem. I will leave this issue open so that others can still leave their thoughts on this topic. If there is enough feedback, I will go ahead and make the jump to support packages.config. But I need more people who need this, before making this change (after all, support for packages.config will have to stay forever to not cause breaking changes). Thank you again for your feedback, it is very much appreciated! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=ABK6FKHDRGQDHEKPPKZGMZ3QMMFFRA5CNFSM4I37MBCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAAP5NA#issuecomment-536936116>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK6FKBCYTSNAM2U3YSZG73QMMFFRANCNFSM4I37MBCA> .

-- Tel / WhatsApp: +31 6 38293316 Email: [email protected] Web: www.dnote.nl Facebook: www.facebook.com/DnoteSoftware

[manuelroemer]

Oh, sorry, I misunderstood that - my bad.

Thanks for still giving this a shot via package references! Keep me updated if it works or if you run into any problems.

[manuelroemer]

I have revamped the README a little bit to give more details about the installation and requirements of the package.

In addition, I have written a few Installation Guides in the wiki - these should give enough information about how the package is ideally used.
I hope that these will be helpful for getting started with it!

[chucker]

Is packages.config really going to be used that often?

FWIW, there are legacy project types where packages.config is mandatory, most prominently ASP.NET (non-Core). (Technically, that issue is about the new project format, but I believe it also affects PackageReference support?)

[manuelroemer]

That's a fair point - I wasn't aware of packages.config being a requirement in old ASP.NET projects.

Do you know if nullable reference types in general (so not just the attributes, but also the ? annotations in general) work correctly in those ASP.NET projects? I'm asking because from my experience, using nullable reference types with the old csproj format is quite a hassle, since it requires you to write #nullable enable in every file (because otherwise Visual Studio complains).

If nullable reference types do work and if people actually want to use them, making the attributes available in a packages.config project is certainly something worth considering.

[chucker]

First, to clarify on the earlier point: when trying to migrate, you get a message box saying:

Project is not eligible for migration. Either the project is not packages.config based or doesn't support PackageReference yet. Visit https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference for more information.

The linked page states:

Migration is not currently available for C++ and ASP.NET projects.)

---

Do you know if nullable reference types in general (so not just the attributes, but also the ? annotations in general) work correctly in those ASP.NET projects?

Yes. As you said, you have to use the per-file #nullable enable syntax. They originally promised support in the old project system, but they have apparently changed their minds about that.

But, the per-file (or per-section) syntax does work — mark a file nullable, and CS06xx warnings start appearing in that file.

(Just tested with an ASP.NET MVC project, old csproj format, on .NET Framework 4.6.1 with VS 2019 16.4.0 Preview 5.0.)

[manuelroemer]

Project is not eligible for migration. Either the project is not packages.config based or doesn't support PackageReference yet. Visit https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference for more information.

Migration is not currently available for C++ and ASP.NET projects.)

This is really unfortunate. After all, this package would work perfectly fine with package references. It's a shame that it's not possible to migrate ASP.NET projects to these (yet).

Given this information, I'm going to think again about adding support for packages.config. The way it would work is not ideal, but it's probably better than having no support at all.

Thanks for telling me this! I wasn't aware that the workaround of migrating to package references is not possible with old ASP.NET projects.

[manuelroemer]

The new version 1.2.0 supports packages.config projects.
Please note that the recommended way for consuming this package is still package references. Using packages.config has a few flaws and therefore introduces possibilities for user errors (for example that the NullableAttributes.cs file can be modified or deleted).

I have done my best to test the new version with several project types using packages.config. I am sure that I have not covered every single situation though. If you notice any problems with a specific configuration, please create a new issue so that it can be fixed.