.NET 4.0

I'll only jizz in my pants when it comes out and has at least a service pack or 2 behind it.
 
dequadin said:
If you (like me) are still in a .NET 2.0
Click to expand...

Still on .Net 2.0 :eek:

Not using Linq, or Entity Framework... or WPF / WCF / WF?:eek::eek:

Havent tried them out at least?:eek::eek::eek:

Dude... unless ur a linux developer... you need to start doing some reading / playing around... ur missing out.

Ons a side note... glad to see PLINQ ("Parallel Extensions - .AsParallel()") has been spruced up a bit and is finally ready for inclusion into the framework. The Beta was awesome to play with:P Haven't played around with 4.0 yet, but will definitely get to the bottom of dynamics etc when I have a chance.
 
I honestly don't see the big fuss about LINQ and Lambdas. I think that if you are a proper C# programmer, you would be able to easily adapt to newer versions / features. No amount of knowledge of WPF / WCF / WF / LINQ / Whatever-.NET-features will ever be able to replace the programming skill of a dedicated C# developer.

Also, I tend to stick to intense stored procedures for by data filtering and database interactions. Makes unit testing A LOT easier and pretty much makes LINQ redundant for me.

All that said, I have to admit that I'm also still on .NET 2.0 and have played around with newer tech like LINQ, WPF and MVC. It's all just a bit of "meh" to me. MVC holds some potential though...
 
all our new projects are 3.5, legacy is mostly 2.0 and that which isn't is redone to either 3.5 or 2.0 depending on the need to do it.

i use very little lambda, but no linq/database in a code-
 
dequadin said:
The biggest problem being we have to target the 2.0 framework.
Click to expand...

I've been there. Worked for a company where we had no time to work on the new tech... and did most of the work in stored procs (this is mostly the case in Web environments). While it's essential that you have an in-depth knowledge of the c# language... don't think that that stops at for loops. FarligOpptreden refers to the "skill of a dedicated C# developer". In my view that is knowing the full tool set.

The point that i'd like to make is that even if you don't need to use the new stuff now, you probably will have to at some point (only, you might not know that it will help you because you don't know its strong and weak points).

When you sit around a boardroom table (or in-front of a client), and they ask you to design a long running workflow... do you want to leave it to then to find out whether WF could have saved you weeks?

The investigation alone will take you weeks... time that you are not likely to waste. You might decide it's a waste of time and put in your own workflow, only to hassle through the same stuff the M$ team worked through when building workflow. Or, you might decide to take the leap then... only to find WF doesn't provide you the visibility that you need in tracking your WF tasks.

You can't make good decisions on which tech to use if you don't know them.

FarligOpptreden, while I understand your argument (worked on stored proc intensive systems) it doesn't hold too much water. Stored procedures are great... but to stick your entire system in your database makes debugging difficult, and scalability a nightmare.

Anyway, that's my POV. Use it, don't use it.
 
shogun said:
I've been there. Worked for a company where we had no time to work on the new tech... and did most of the work in stored procs (this is mostly the case in Web environments). While it's essential that you have an in-depth knowledge of the c# language... don't think that that stops at for loops. FarligOpptreden refers to the "skill of a dedicated C# developer". In my view that is knowing the full tool set.

The point that i'd like to make is that even if you don't need to use the new stuff now, you probably will have to at some point (only, you might not know that it will help you because you don't know its strong and weak points).

When you sit around a boardroom table (or in-front of a client), and they ask you to design a long running workflow... do you want to leave it to then to find out whether WF could have saved you weeks?

The investigation alone will take you weeks... time that you are not likely to waste. You might decide it's a waste of time and put in your own workflow, only to hassle through the same stuff the M$ team worked through when building workflow. Or, you might decide to take the leap then... only to find WF doesn't provide you the visibility that you need in tracking your WF tasks.

You can't make good decisions on which tech to use if you don't know them.

FarligOpptreden, while I understand your argument (worked on stored proc intensive systems) it doesn't hold too much water. Stored procedures are great... but to stick your entire system in your database makes debugging difficult, and scalability a nightmare.

Anyway, that's my POV. Use it, don't use it.
Click to expand...

Have you worked much with clients? They change the WF so much that it literally takes weeks (even months) just to settle on something. So having a fore-thought on this, when we do get a contract and start assessing the client's needs and pulling up a project outline, we tend to start at the foundation. The database.

With experience you can design a pretty robust database, capable of changing to whatever the client's next brain-fart may be. So building on top of that... damn easy.

I've seen people take 3 months to develop 1 feature, whereas it will literally take me 3 days instead. Without any fancy Microsoft flow with wings and a kiss from mom every second F5 :)

My stuff is in 3.5 atm, enjoying the json capability of web services and lovin' it.
 
shogun said:
Or, you might decide to take the leap then... only to find WF doesn't provide you the visibility that you need in tracking your WF tasks.
Click to expand...

Oh dear... my point has been completely missed. There is no point arguing.
 
@shogun:

Stored procedure debugging is dead easy: Server Explorer -> Right-click Procedure -> Step Into Procedure. Line-by-line debugging to your heart's content.

As Acid mentioned, you tend to start at the beginning, which is the database. A scalable solution is dependent on scalable data structures. If you plan and build your database accordingly, you can very easily build a scalable workflow solution. Been there, done that. Changing the workflow for any of our numerous clients now entails a database entry or 2. No changes to source-code and no recompiling.

Yes, the new features in successive versions of .NET can make life easier for developers, but there really is no substitute for understanding how everything works in the background and even how you would build your own workflow / "LINQ" / MVC-esque framework.
 
I got mostly .net 2 projects . Was suppose to hand over to maintenance.. but that are so far behind now we (I) have to do support on them.

DId some Silverlight work. It's cool, but downloading Silverlight pluging etc... don't know hey. (from bandwith point of view and clients installing another plugin etc)

Played with Linq (but still like stored procs for filterting).

What I like about .net 4. The frieking control_parent_id_number_1 can be changed. I really like that (small , but very very good). And yes , I know about clientId etc. (before someone post links to it:D)

Looking into MVC. Can be very good (smaller markup which is always a win).

Did some other small .net 3.5 stuff, but nothing WOW...
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X