|
I think you just like being argumentative and abrasive with me in general.
Code Project is the 7th recommended link, at least for me:
c - Google Search[^]
|
|
|
|
|
Slacker007 wrote: I think you just like being argumentative and abrasive with me in general.
I don't normally even look at who posted a message before I reply.
Slacker007 wrote:
Code Project is the 7th recommended link, at least for me:
c - Google Search[^]
If you want to duel anecdotes, the last question I threw at Google (a basic syntax lookup) was still in my search box, code project didn't make a showing until page 3.
razor show raw html - Google Search
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
|
|
|
|
|
Perhaps we ought to change the meaning of the term "LOW LEVEL LANGUAGE" whereby it refers to the user's abilities?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Well, if someone is new to Calculus, then should we expect them to be "high level" at the beginning? of course not.
|
|
|
|
|
I don't mind these questions so long as the asker is up front about this being a homework assignment. It changes how we answer from "give a man a fish" to "teach a man to fish".
|
|
|
|
|
All of my packages need an update, according to NuGet.
I'm on .NET Core 3.1 and .NET 5 was apparently just released.
So all my packages should go from 3.1.x to 5.0.0, according to NuGet.
Except that when I update, my software breaks because THIS IS NOT A .NET 5 PROJECT!
I've had this issue with .NET Core 1.x -> 2.1 -> 2.2 -> 3.0 and -> 3.1
The worst part is, I do need an upgrade from 3.1.x to 3.1.y, but that's not an easy (or obvious) task now as it selects the latest version by default (which is 5).
How difficult can it be to only target packages for the project's .NET version?
ing NuGet
|
|
|
|
|
I had the same problem when EF Core 3.0 was first released - my .NET Framework project kept trying to update, and failing because the update required .NET Standard 2.1.
I also have to be extremely careful with any projects referencing EPPlus v4. I don't want to upgrade to v5, since it's now a commercial product, but NuGet keeps offering to update the package.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
There's a checkbox "Include prerelease", they should add "Include major updates" and "Include commercial updates" (or maybe some license picker).
That should not even be hard to implement.
|
|
|
|
|
Use NiGet instead
|
|
|
|
|
I prefer Ecky-ecky-ecky-ecky-ptang-zoom-boing-mumble-mumbleGet instead, which comes with twice as many shrubberies.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Ni!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I remember when people said NuGet would revolutionized development... sigh...
I'd rather be phishing!
|
|
|
|
|
It did... But not all revolution was a huge success...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Yeah, sometimes you end up with a Stalin!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
It did!
In a way that the French revolution did for the elite
|
|
|
|
|
when you create the project (and even later you cand do this, after proj created) you can target a specific version via creating a new globaljson file and using the --sdk-version flag.
dotnet new globaljson --sdk-version 3.1.101 --output ProjectName
This created a global.json file with:
{
"sdk": {
"version": "3.1.101"
}
}
|
|
|
|
|
I'm not sure how this is supposed to work, but I've added the global.json file on solution and project level, but it does nothing for my list of NuGet updates
|
|
|
|
|
Did you 1) clean the solution 2) rebuild
It _should_ stick you to a specific version of the .NET Core and then only retrieve those versions and associated packages related to those versions.
But, maybe not.
more here...
global.json overview - .NET Core CLI | Microsoft Docs[^]
|
|
|
|
|
Yep, even restarted VS, cleaned, rebuilt, tried adding rollForward latestFeature, but NuGet is still bugging me for v5.0.0
|
|
|
|
|
You could try Paket - I've heard it's better for version pinning & not changing versions of things unless you really ask it to...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thanks, didn't know that.
I guess I'll stick to NuGet though, because that's the devil I know
|
|
|
|
|
It's payment to use idioticly designed nuget (thanks MS clowns!). If they were aware of the REAL ENTERPRISE development, they will know: NEVER EVER update libraries w/o necessarity. Esp. at "friday builds". DLLs should be updated ONLY after testing in a separate environment (separate from main development env). In other words, any updates MUST be offline and manual. I wish to know that stupid teenager who decide to "update all libs and build" not asking developer. Total nonsense!!
|
|
|
|
|
|
Sander, sorry, but your thinking looks childish. OF COURSE you need I-net to download libs, BUT you need it only during session. After that you can bring libraries to other OFFLINE PC and do update. You probably will be surprised, but in some workplaces there is no access to Inet at all.
Anyway, forcing user to be always online is crazy.
Also, why do it manually when you have tools that do the update for you?
Because you never develop serious software. Imagine author of the lib made... breaking changes! HOW do you know about that if you blindly trust "update for you"?
And not only that. Imagine lib was infected. Or obtained additional (and dangerous) dependency. Or hell knows what, what is UNDESIRABLE for your project. Don't think all developers are smart! They CAN make mistakes and you will be the victim of this.
Now imagine you have $1,000,000 contract, you need to supply s/w, but... you cannot - because you rely on "silent updates" and broke the build. CONGRATS, you f**** up your contract and loose all money.
Any other naive questions "why"??
As a professional developer, one of your skills must be "CONSERVATIVE". No any jumps w/o reason. No following hype. If you have stable process, it should stay same stable.
My complaint is only that NuGet proposes updates that would not run on my version of .NET
Pray that only this EASY problem appeared. Problems can be much worse and "silent updates" is the reason. It's like allowing children to "play" on your PC! Don't complain they updates your Windows 7 till 10!
|
|
|
|
|
Thornik wrote: Sander, sorry, but your thinking looks childish. It may look that way, but I assure you it is not
Thornik wrote: in some workplaces there is no access to Inet at all Sure, always a hassle to work at those places! It makes sense for factories, but for most of the office personnel it's complete overkill and costs more in terms of trouble than it gains you in terms of security.
Thornik wrote: Anyway, forcing user to be always online is crazy. We can agree on that!
Thornik wrote: Imagine author of the lib made... breaking changes! HOW do you know about that if you blindly trust "update for you"? That's why you test it.
Perhaps we have different definitions of "manual updates".
For me, manually means editing your project files, something I sometimes do.
Automatically is letting NuGet install the version(s) I told it to install by pressing a button.
No silent updates or any of that in my software.
And no breaking changes either.
Going from jQuery v1.1 to 1.2, only after carefully reading the changelog and testing.
Going from jQuery 1.x to 2.x or 3.x, no way in hell.
Going from .NET package 3.1.1 to 3.1.2, sure, because breaking changes are rare for patches and your compiler will probably catch them.
Going from .NET package 3.1.x to 3.2.x or even 5.x, no way in hell unless a platform upgrade is required.
Thornik wrote: CONGRATS, you f**** up your contract and loose all money. Most companies aren't to keen on looking for new suppliers.
In my experience, you can mess up really bad and multiple times before they ditch you.
And those mess ups rarely have to do with updates.
More like manual mistakes like deleting a database table in production
Thornik wrote: Problems can be much worse and "silent updates" is the reason. The only silent updates I know of are those of Windows, and that's not something I maintain for my clients
Never an issue with NuGet in any case.
|
|
|
|