|
glennPattonInThePubAGAIN wrote: one of the WW2 generation
I'm living next to one of those; they don't build them like that anymore. In his 70ies and having trouble walking, but still more powerfull than I'll ever be.
I wish your dad lots of good health, and I'm convinced that there must be some employer looking for an experienced worker. Keep shooting, it can't rain forever.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks!
|
|
|
|
|
glennPattonInThePubAGAIN wrote: just needed somewhere to moan
Moans are always welcome, regardless of the cause. 
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
It is a light, regardless of whether the job is there or not... you still have your Dad to talk to. Cherish the time; it passes all to quickly.
|
|
|
|
|
Hmmm, I'm starting to see that, thanks!
|
|
|
|
|
Best wishes to your father, my old man had a mild (if there is such a thing) stroke last year, fortunately he was near a hospital at the time and received prompt treatment he's now 95% recovered, so there is hope. Also, good luck on the job prospect!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Cheers!
|
|
|
|
|
glennPattonInThePubAGAIN wrote: just needed somewhere to moan!
That's what we are here for 
All the best for you and your family, Glenn
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
<rant>
At first NuGet seemed a good idea - the kind of package management Node and Rust have taken for granted for ages.
Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities.
Many of my projects reference Newtonsoft Json.Net 10.0.3. Somehow NuGet resolves this with version 6.0.x. FFS - thats 4 major versions out-of-date.
Been using OWIN packages, and getting similar issues. Still haven't got to the bottom of this one.
The whole thing is beginning to remind me of DLL Hell and ActiveX components under VB6.
WTF happened? I thought .NET was designed to get us away from this excrement.
(Love the fact the editor here includes <rant>, but not the matching end tag)
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
The New Nuget Marketing Brochure
Works when it works.
Total chaos when it doesn't --- and you're alone when it doesn't. 
|
|
|
|
|
As I said, they've managed to reinvent DLL hell.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
The only thing worse than NuGet is when people don't realise you don't need a NuGet package to use JSON 
modified 22-Jun-17 10:11am.
|
|
|
|
|
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Immanentize the Eschaton!
|
|
|
|
|
Thing is, it is used by default in some of Microsoft's own project templates and packages. Sometimes you don't have much choice.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
F-ES Sitecore wrote: you don't need a NuGet package to use JSON
I've only just recently started using Newtonsoft for JSON. I assumed there was probably another way to get it besides NuGet, but I haven't had the time to research alternatives. Can you take a moment to describe your workflow in this regard?
|
|
|
|
|
You can use things like DataContractJsonSerializer to work with JSON, there are other built-in classes too depending on what version of .net you're using.
|
|
|
|
|
Rob Grainger wrote: Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities.
Recently? I've never had NuGet behave properly. And that BS about changing something in some config file to override the version number, well, it's just that, BS.
My SOP:
- If I can, I compile the source directly and add to my project the necessary DLL's. This is often fraught with problems, as people can't seem to provide source code that actually compiles, or doesn't compile with the .NET framework that I'm using, or doesn't provide a SLN file, or has all sorts of project kruft that I don't need or care about.
- Failing #1 (happens often enough) I create a separate project, do the PM NuGet BS, grab the DLL's from the appropriate .NET version folders, put them in a "Libs" folder that my real project then references, and delete the temporary project.
And the very elephanting last thing I need/want is for some package to update itself, breaking code, breaking other dependencies, etc.
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I do exactly the same - I have a project called NuGet - I don't bother deleting it. The last thing I need is to open an old project and have that $#%@^&*ing thing wander of and update packages.
It never really worked smoothly for us, this may have been caused by the corporate centurion dissalowing the connection in the early days.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks for the ideas - that may help.
Have to agree on Point 1 too - that and Blog posts with source code the author can never have got working.
Think I have a CP article coming from my recent experiences though - getting good Integration testing working on the MVC stack.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
One problem with NuGet is Visual Studio itself. It assumes you will organize everything at the solution level, so if you're working with a code base with multiple solutions, there are package folders littered everywhere!
Then there are out and out bugs in MSVS. Try centralizing your downloaded packages into one package folder and it all starts going south...
Anyway I've done pretty much what Marc describes above.
I create a ThirdParty solution that I use to download all NuGet packages I want to use. They all get downloaded into the ThirdParty solution's package folder, where literally everything in the package folder gets put into source control.
This pattern allows me to download and keep multiple versions of the same NuGet package so that legacy applications are able to use an older version if, for some reason, it is withdrawn.
From there, any other solutions that want to use a NuGet package will simply use a file reference for the dll directly from the ThirdParty package folder.
Source code from other vendors are included as projects to the ThirdParty solution and again those libraries can be referenced from a solution as a file reference.
|
|
|
|
|
|
I've had problems in both cases.
Thanks for the links though.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
|
Another thing you might want to consider is taking the specific packages you want your project(s) to use, and building your own custom NuGet feed with them. Granted, it's a bit of a hassle, but at least you'll have full control of the packages.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
