.NET 4.0 and Visual Studio 2010

Sometimes it feels like you’ve been hit by a car, sometimes it feels like a freight train. Either way, if you’re in this industry and you’re not ready for change or if you’re not crazy enough to “know  you can figure it out” then its time to get out…

Why?

.NET 4.0 and Visual Studio 2010 are already on their way.

I haven’t even upgrade to 2008 yet…

I know, and neither has the rest of the world. This is possibly one (of many) instance where companies might just skip 2008 and go to 2010 because of the release cycles. At this point they’re getting so close that its impossible to keep up. A colleague I was working with and I were talking about how Redhat suffered from this same rapid release cycle. Back in the days before Redhat slowed its releases down you would see a new Redhat OS released every couple of quarters. No business in their right mind would keep up with a release schedule that could possibly introduce problems with system integrity.

New Things Coming to .NET 4.0 and / VS 2010

The real big thing here is: ALM (Application Lifecycle Management)

You have the:

• Architecture Explorer
• Design Diagrams (we already have some of these but more are to come)
• Better collection of test data
• Test Impact View: Run tests that are affected by a code change. This is huge, so instead of running your 1000 unit tests to make sure your change didnt affect anything (which you should still do IMO anyway) the big blue is telling you to “just run what’s changed”. Some instances are very difficult to test, especially when using reflection or if you’re using string literals to build things (which is bad anyway … more on this at a later time).
• Gated Check in – Makes sure that the code passes a # of tests prior to the code being committed to the system. Similar to Open Gauntlet.
• Branch Visualization – This is super nice. Be able to see how and what your branches are touching and/or connected to. Screencast here.
• Build Workflow – I’m not really sure what this is going to do but my guess is that it will allow you to identify build steps in order to successfully build things. Hopefully streamlining the MSBuild process a bit more.
• More modeling – In my opinion this is more Oslo related stuff. More modeling from a higher level to let your architects see what’s “really” happening. However, this is very subjective at this point … more on this later.
• Eliminating the “no-repo” bugs. Again… this is completely subjective. I’m afraid this is not possible… how can you possibly remove the no-repo bugs? You cant. There will ALWAYS be a time when a bug occurs in a certain instance with a certain config that is darn near impossible to repo.