-
Notifications
You must be signed in to change notification settings - Fork 8
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
[Discussion] Installation Error when using NuGet's packages.config file #1
Comments
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! |
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. |
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
|
My point is basically to explain why packages.config is not supported so far and to spark discussion on whether that should change.
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! |
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
|
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. |
I have revamped the In addition, I have written a few Installation Guides in the wiki - these should give enough information about how the package is ideally used. |
FWIW, there are legacy project types where |
That's a fair point - I wasn't aware of Do you know if nullable reference types in general (so not just the attributes, but also the If nullable reference types do work and if people actually want to use them, making the attributes available in a |
First, to clarify on the earlier point: when trying to migrate, you get a message box saying:
The linked page states:
Yes. As you said, you have to use the per-file 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 |
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 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. |
The new version 1.2.0 supports I have done my best to test the new version with several project types using |
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.
The text was updated successfully, but these errors were encountered: