|
So, an OutOfGinAtribute()
|
|
|
|
|
Even when it is referred to by other code?
|
|
|
|
|
PIEBALDconsult wrote: not-yet-ready-for-primetime
Seems to be a natural state for all the code in the world. The opposite ReadyForPrimetimeAttribute or just WorkingAttribute belongs to science fiction.
|
|
|
|
|
PIEBALDconsult wrote: But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it.
OMG. No.
Is there ever any code you don't intend to rework?
Over time my code would evolve into endless warnings every time I compiled it. Until I turn it off, making it completely pointless.
|
|
|
|
|
Sure, yet some are worse than others, or at least some times I know what I want to do when I have the time.
|
|
|
|
|
I use #warning directives in my C# for this. Their messages show in every compile including product builds, so I can't forget things that need to be reviewed. It's nagging without being obstructive.
Software Zen: delete this;
|
|
|
|
|
Even when referencing something in a DLL?
|
|
|
|
|
For developing at my desk, the warning message is only issued when compiling the DLL, obviously. Our automated build process builds all parts of the product from source which causes the warnings to be in the build log. Both results are sufficient to help me keep track of items for later changes.
The exceptions to both of these cases are third-party libraries supplied without source code. We use several of those to control hardware we buy off-the-shelf.
Software Zen: delete this;
|
|
|
|
|
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc.
Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet!
Advertise here – minimum three posts per day are guaranteed.
modified 3-Mar-21 14:58pm.
|
|
|
|
|
Never used it. Worthless. Leave it for the cargo-cultists.
|
|
|
|
|
PIEBALDconsult wrote: Never used it.
PIEBALDconsult wrote: Worthless.
How would you know it is worthless, if you never used it?
|
|
|
|
|
By reading the reviews of those that have.
They list the aims, advantages, pitfalls and disadvantages.
I too, fail to see the overall experience as being worthwhile.
|
|
|
|
|
For a long time I tried to stop the use of NuGet packages, but after a bunch of new colleagues arrived they had their way and now the builder is totally dependent on NuGet and the internet.
And of course they were totally surprised that suddenly version conflicts arose.
But on the positive side: I must admit that last year I tried to get the new NpgSql driver for PostgreSQL working and could not get it done without using NuGet.
I even have plans to create a privat NuGet server, see: private-nuget-servers[^]
So as the saying goes: "Go with the flow" ...
|
|
|
|
|
I've had a few run-ins with NuGet during my career, but apart from one time, nothing I couldn't fix.
What really bothers me is that it tells me to update to package v5.0.0, which I know to be built on .NET 5.0, while my project is .NET Core 3.1.
That's not compatible, yet it wants me to update... 
It shouldn't be that difficult to recognize my .NET version and then only show me updates for that particular version, or so you'd think.
|
|
|
|
|
Technology exists not to "being fixed", but to HELP development! If nuget has defect in working principles, I see no reason even mention this tool.
|
|
|
|
|
If technology could never be fixed we'd all be out of a job dead (probably) 
|
|
|
|
|
We just moved from 2.x to 5.
Good luck when you get there, take booze!
veni bibi saltavi
|
|
|
|
|
I'll skip 5 as it's not an LTS release.
Although the move from 3.1 to 5 should be pretty painless... In theory 
One of my customers, the only one with a software (1-man) team of their own, is on .NET 5 and so far it looks exactly like my 3.1 code 
|
|
|
|
|
Sander Rossel wrote: It shouldn't be that difficult
Do you realize what you just wrote!!!!!
Everyone who's read is is now doomed to a hell of unsolvable problems for all eternity. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
How are you using NuGet? All I do is right-click my project in Visual Studio, Manage NuGet Packages and then install what I need. It's much easier than going out to find the vendor's website, downloading an sdk, and adding references in Visual Studio.
And mine don't ever try to update so new versions or url changes don't affect me. I've been using it for the last couple of years and have not had the problems you mentioned so you must be doing something wrong. 
|
|
|
|
|
Wait until you use 3rd party libs that need different versions of dll's, then it's party time
|
|
|
|
|
A lot of proprietary libraries. Third party stuff. Microsoft Azure stuff. Packaging my own old libraries in a NuGet library... At least for me the whole process feels painful and time-consuming.
There is only one Vera Farmiga and Salma Hayek is her prophet!
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Deyan Georgiev wrote: Third party stuff. Microsoft Azure stuff.
That's me too.
|
|
|
|
|
We're using them quite intensively.
We create and consume them for internal libraries (for C# and C++ projects) with Azure DevOps feeds and use public nugets available on nuget.org feed
No big issues so far.
For C++ packages, there seems to be a push to vcpkg.
But heck .. xkcd: Standards
I'd rather be phishing!
|
|
|
|
|
To avoid version conflicts, create your own local NuGet repository and only install from that. That will keep NuGet from automagically "upgrading" your packages, and allow you more control over your upgrading process (upgrade only when you want to).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
