|
I was assuming some non-commuting driving, as well. 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Old Commute: roughly 90/minutes, assume no public transit problems
New Commute: roughly 18 min.
I essentially have added an extra day of life to each week.
If they transfer me 'back' - I'm outta here.*
* It's only fun if it's fun.
| 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 are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
Regardless of the version, are you capable of performing the tasks assigned?
Yes, newer version may have newer features, but are they necessary to perform the task?
|
|
|
|
|
Tim Carmichael wrote: Regardless of the version, are you capable of performing the tasks assigned?
"Sort of." Some OS projects I want to use are built for at least C# 6.0, which means I would have to go through and revert the code back to C# 5.0. And I'm not wasting my life doing that because the IT people refuse to upgrade their remote build processes.
The irony is that while we're using VS2015, we have to set the the target C# version to 5.0!!!
|
|
|
|
|
Tim Carmichael wrote: you capable of performing the tasks assigned?
Any real programmer should be capable of performing any task in pure assembly language. That being said, just because one can/is capable, doesn't mean he should.
|
|
|
|
|
Tim Carmichael wrote: Regardless of the version, are you capable of performing the tasks assigned?
Yes, newer version may have newer features, but are they necessary to perform the task?
In the short term these questions are reasonable. In the long term? Not so much.
The more any IDE/framework/package/library/etc ages, the less likely it is to upgrade cleanly when jumping multiple versions. Old features are deprecated and later removed, etc., forcing extensive rework. As Murphy says, pretty much anything that can go wrong, will go wrong.
"well, just re-write it!"
Every time someone says that I roll my eyes. It's rarely that simple. All too often the organization is either behind or barely keeping up on current things, so adding a rewrite in just doesn't fit. Ideally I agree with re-writing, but my idealism died a long time ago ...
On the other hand, starting with a relatively new version of everything is a good choice. It puts off the need to upgrade longer than starting with older version(s). When the newest version becomes stable (in the case of Microsoft, after the 2nd service pack is released ) compile the program in the new version. If the compile is clean, keep it. If it's not clean, look at the problems and triage.
Another reason for keeping current is hiring. Need new people? Good luck finding someone good who wants to work in technology that is 3 to 5 revs back. Been there, it truly sucks to find an excellent candidate with all the right skills and great references ... who looks at me like I'm nuts when I tell 'em what versions that company mandated. 
My current project is VS2015, C# 6, .NET 4.6. Once the project goes to Production, we'll evaluate if going to VS2017/C# 7/.NET 4.6.2 is a good idea. We will not upgrade in mid-development -- there's nothing in the newer version we need although we know we don't need the headache of a mid-stream upgrade. Once the product goes to production we'll evaluate the newer versions. It is likely that the next project will be VS2017/etc., although at this time CORE is not on the plate as we don't need it.
|
|
|
|
|
So, we went from DLL Hell, to IDE Hell, to IDE+C# Version Hell...
Since the first one affected USERS, it had to be fixed.
But I cringe at the versioning going on with .NET and C# versions.
And how old projects never recompile cleanly on a new VS version.
Thankfully we have VMs.
But I totally understand managing the build cycles and defining how/what we support.
Otherwise you get a mismatch of requirements for the products across the enterprise.
So much complexity...
|
|
|
|
|
Honestly, C# isn't that bad. My biggest headaches were trying to staff a Java project where the client mandated all components were versions 3 to 6 years old. Kept finding good people who had no interest in working with old technology.
As both a consultant and an FTE, I agree with that. We need to focus on building and maintaining our resume so that we remain marketable. Working in "ancient" technology doesn't often help in finding that next contract/job.
|
|
|
|
|
|
Visual Studio 2008 C#, .NET Framework 3.5 SP1. We bought VS2015 two years ago, but never managed to budget the time for the update and the required regression testing  .
Software Zen: delete this;
|
|
|
|
|
C# 6.0 with VS 2015. 
I am quite happy with these versions and currently see no need to go to either C# 7+ or VS 2017 based on the projects we are currently doing.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
I am currently using C#7 for my project. Though the "cool" features don't come in play much. Also, with a newer tech. people look for excuses to use the newer feature even when a more familiar way would have sufficed.
|
|
|
|
|
GKP1992 wrote: Though the "cool" features don't come in play much.
My favorites are the null continuation and tuple features. ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
|
|
|
|
|
They're cool, aren't they? I like'em too, in addition to the new async return type. I do not like the local functions feature though, can't see why they made it so.
I am not the one who knocks. I never knock.
In fact, I hate knocking.
|
|
|
|
|
|
|
Its hard to fix things that aren't broken...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
abmv wrote: Its hard to fix things that aren't broken...
What's broken is we're all using VS 2015 but the remote build process is still building with C# 4. So, if you don't remember to set the "use C# version" under build -> advanced to 4.0, it's easy to write a lot of code using C# 5 or 6 features, only to discover the remote build fails.
Or worse, as in my case, you find a snazzy open source package that uses C# 6.0 syntax.
|
|
|
|
|
Well its a matter team consensus..its better to get to C# latest when their is time than later brood over it.
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Our build server is set up for C#5, but I just include the latest Microsoft.Net.Compilers nuget package into my project and the build server uses that version to build my code. So, I have never had to change the build server and can always use the latest version of C#.
|
|
|
|
|
Member 12512543 wrote: Our build server is set up for C#5, but I just include the latest Microsoft.Net.Compilers nuget package into my project and the build server uses that version to build my code.
That's sneaky. I will have to try that.
|
|
|
|
|
c# 4, 5 and 6. We are not using 7 yet
|
|
|
|
|
4.5.1 though the next project will be .Net Core 2. Oh joy.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif)
'ing archaic.
