views:

75

answers:

2

Currently we are doing a payroll application in Microsoft Visual Studio 2008 (.Net 3.5) using some of the latest features like WCF, WF and the development for the same has almost completed.

However, clients have shown their interest in migrating the developed payroll application in Microsoft Visual Studio 2008 (.Net 3.5) to Microsoft Visual Studio 2010 (.Net 4.0).

I don't have an idea about the expected challenges in the migration or if its just going to be very smooth.

Any thoughts or comments?

+2  A: 

4.0 is a superset of 3.5 so there should be no challenges. All of you 3.5 code will work as it had when built with VS 2008.

If you do a Google search you'll find many articles titled something like "What's new in 2010". You won't find things like "What's Different"

Except for this little tidbit From MSDN:

The .NET Framework 4 is highly compatible with applications that are built with earlier .NET Framework versions, except for some changes that were made to improve security, standards compliance, correctness, reliability, and performance.

The .NET Framework 4 does not automatically use its version of the common language runtime to run applications that are built with earlier versions of the .NET Framework. To run older applications with .NET Framework 4, you must compile your application with the target .NET Framework version specified in the properties for your project in Visual Studio, or you can specify the supported runtime with the Element in an application configuration file.

The see the article

Also:

If your application or component does not work after .NET Framework 4 is installed, please submit a bug on the Microsoft Connect Web site.

That tells me that 4.0 is meant to be perfectly backwards compatible, and if not, then it's something they need to fix.

Paul Sasik
I'm not sure this is entirely accurate... looking for a reference...
John Weldon
@John: Successive releases of .NET since 2.0 have only expanded the library. The IDE may have changed or been tweaked but the FCL has only been added on to.
Paul Sasik
I don't think so... If you examine even System.Core.dll, it depends on version 4.0 dll's all the way down to mscorlib
John Weldon
Good update; according to that article it's compatible, but not a superset.
John Weldon
@John: how would that affect compatability? And, do you have some reason to believe they haven't learned their lesson since the .NET 1.1-2.0 migration fiasco?
John Saunders
@John Saunders, My original point was simply that the .NET 4.0 is not a *superset* of .NET 3.5. That doesn't mean there *are* incompatibilities, it just means there *could* be.
John Weldon
@John W: Maybe superset isn't the best choice of word. Not sure what else to call it though. Extension? Addition? I meant to imply that functionality was added and nothing in the APIs (except perhaps beneath the covers) changed.
Paul Sasik
@Paul, makes sense.
John Weldon
One thing that came to my mind is this article, maybe it is helping: http://blogs.msdn.com/b/shawnfa/archive/2009/05/21/security-policy-in-the-v4-clr.aspx
PetPaulsen
+1  A: 

If you're using IdeaBlade, expect a ruckus; other than that the transition for us was smooth as can be.

VS2010 did introduce a memory leak with the debugger and forces me to restart VS2010 about twice a day :/

The update to 4.0 with ninject was painless and quick.

Gnostus