none
If I target .net 4.0 but run on a machine that has .net 4.5 will .net 4.0 WPF bugs still be there?

    Question

  • I am interested in installing the Visual Studio 11 Beta (and the actual release when it comes out).

    But I am one of the unlucky that has to support Windows XP installs for 2 more years. 

    We run an N Tier shop.  (SQL 2008 -> Entity Framework/WCF -> WPF)  I would like to use .net 4.5 for the middle tier (Entity Framework and WCF).

    But I am worried.  There are several bug fixes in .net 4.5 for WPF. 

    If I develop a WPF application (using Visual Studio 11) that targets .net 4.0, will those bugs still happen on a machine that has .net 4.5?

    I am concerned that I will make my .net 4.0 application (that, unknown to me, uses one of those "fixed" bugs) and think it all works great (because I have .net 4.5 installed). 

    Then, when it is run on a Windows XP machine with only .net 4.0 on it, there will be bugs that make me look bad.

    If I "Target" 4.0, am I really getting 4.0 (Bugs and all)?




    • Edited by Vaccanoll Wednesday, May 30, 2012 4:04 PM
    Tuesday, May 29, 2012 4:20 PM

Answers

  • For those who read this post, here is the problem with the .NET 4.5 In-Place Upgrade:

    It assumes that the developer is happy to have .NET 4.0 bugs fixed when developing "Targeting .NET 4.0" (with .NET 4.5 installed).

    But the developer NEEDS to see them. They need to break while debugging so that workarounds can be put in place (or features postponed/canceled). 

    Because if you develop "Targeting .NET 4.0", then you clearly plan to run on a machine that DOES NOT HAVE .NET 4.5!

    Here is an example that explains this:

    A WPF developer creates an application using the new Visual Studio 2012 (which requires .NET 4.5).  The developer targets the application to .NET 4.0 (because his company still has a lot of Windows XP machines).

    During development an ObservableCollection is bound, grouped and sorted.  The developer does not realize that this causes a severe bug in .NET 4.0.  And since since .NET 4.5 is installed on his development machine, this bug will not show up during his debugging.

    When the application is released, it will fail when run on a Windows XP machine (because XP cannot run .NET 4.5).

    The bugs fixed by .NET 4.5 are a HUGE problem.

    Because unless I know and watch out for all of them (and Microsoft will not post a bug fix list) then I can't know that I am not having bugs hidden from me by .NET 4.5 while I develop.

    These hidden bugs are the real problem of the in-place upgrade.  The problem no one will talk about.

    So my options are to:

    1. Ban .NET 4.5 from my company.

    2. Try and set every developer up with a Windows XP box to remote debug on (and hope and pray that they follow that practice (not likely))
        [UPDATE: Remote Debugging to Windows XP is not supported in Visual Studio 2012.]

    3. Add an extra layer of Windows XP compatibility testing and hope that it catches everything (think of all the checks you do while debugging and think if any post development testing step will really replace that.)

    None of these are good options. But even though I want to go with #2, my management has told me they are going with just banning .NET 4.5 (and VS 2012).

    While I don't like it, I am grateful my company recognized this problem before we went and upgraded all our developers and started seeing bugs in production.

    I anticipate the "Target .NET 4.0" feature will really catch a lot enterprises off guard and cause some production downtimes.

    ------

    Note:  Even though the In-Place Upgrade is going to cause problems for my company, I worry even more that Microsoft will put .NET 4.5 in a Windows 7 Service Pack and force us to upgrade!  That would be a HUGE mess.

    • Marked as answer by Vaccanoll Friday, June 08, 2012 10:53 PM
    • Unmarked as answer by Vaccanoll Friday, June 08, 2012 10:53 PM
    • Marked as answer by Vaccanoll Monday, June 11, 2012 3:45 PM
    • Edited by Vaccanoll Tuesday, July 31, 2012 5:45 PM
    Friday, June 08, 2012 10:52 PM
  • Calmly describe your situation, making it clear how much it would cost you to change your environment to not have these problems.

    Tried that. Microsoft ignored us.

    Complain in Connect, not in the forums.

    Tried that. Microsoft responded with, "Connect is for future versions, not for fixing bugs." On top of that, they recently embarked on a purge of the connect site, deleting a huge number of bug reports which they'd previously ignored.

    Here's something I wish that people like you would get: Telling us we're doing it wrong, or that our customers are living in the dark ages, doesn't help. Telling us to change the way we work, or to force our customers to spend time and money to upgrade their systems, just because Microsoft wants to kill XP, is not an answer.

    • Marked as answer by Vaccanoll Thursday, August 16, 2012 6:40 PM
    Thursday, August 16, 2012 5:20 PM
  • Please vote for this: Support a .NET 4.0 Service Pack on Windows XP Supporting those .NET 4.0 Bugs Fixed in .NET 4.5
    I agree!  Maybe if we get enough votes for this we can get to where we can use Visual Studio 2012.
    • Marked as answer by Vaccanoll Thursday, September 06, 2012 7:40 PM
    Tuesday, September 04, 2012 10:49 PM

All replies

  • Hi,

    The behavior depends on the runtime assemblies. .NET Framework 4.5 is an in-place update that replaces the old .NET Framework 4.0 assemblies. So

    >If I develop a WPF application (using Visual Studio 11) that targets .net 4.0, will those bugs still happen on a machine that has .net 4.5?

    No as 4.5 assemblies have fixed these bugs.

    >If I "Target" 4.0, am I really getting 4.0 (Bugs and all)?

    If your application run on 4.0 environment (a machine that has only .NET 4.0 Framework installed) you'll still get these bugs.

    You can get more information about .NET 4.5 comaptibility via:

    http://blogs.msdn.com/b/dotnet/archive/2011/09/26/compatibility-of-net-framework-4-5.aspx

    >I am concerned that I will make my .net 4.0 application (that, unknown to me, uses one of those "fixed" bugs) and think it all works >great (because I have .net 4.5 installed). 

    >Then, when it is run on a Windows XP machine with only .net 4.0 on it, there will be bugs that make me look bad.

    Yes this could be an issue. To make sure your application behaves the same way in dev time and run time you probably need another dev machine that has only .NET Framework 4.0 installed for testing purpose (and use remote debugging if needed, etc.).


    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.










    Thursday, May 31, 2012 7:45 AM
    Moderator
  • And that's the final nail in the coffin for .NET 4.5 and VS11. >:(

    If we have just one application which one customer is running on XP or 2003, we can't install 4.5/VS11 without breaking our ability to maintain that application.

    Setting up another dev machine or VM to maintain 4.0 applications means doubling our licensing costs - two copies of Windows, two copies of Visual Studio, two copies of ReSharper, etc. - as well as the added inconvenience of constantly switching machines.

    Friday, June 01, 2012 6:23 PM
  • Did you really just say what I think you did? Really?

    4.0 to 4.5 is a bigger and less compatible update than from 2.0 to 3.0. It's got more BCL updates from 4.0 than from 3.5 to 4.0. And it's not even installed side-by-side like 1.0, 1.1, 2.0, 3.0, 3.5 and 4.0 were. 4.5 has just become a liability and a maintenance nightmare. Thanks!

    Just a heads up: .NET 4.5 has just been banned from each and every server and workstation at our shop. Just now. Just like that. Apart from WPF, this just killed any possibility of upgrading to ASP.NET 4.5 as well.

    I wish I could feel better about that, but it's still us being screwed over rather than you.

    Friday, June 01, 2012 11:36 PM
  • another interesting aspect of this is that it now impossible to safely develop .NET 4.0 apps on Windows 8 as you cannot just install 4.0 on Windows 8.  you are forced to using 4.5 which will give you invalid test results if you are targeting XP and .NET 4.0.  So Windows 8 must be banned as well in this scenario.
    Sunday, June 03, 2012 1:44 PM
  • Hi,

    If you don't like remote debugging how about copy the .NET 4.0 WPF assemblies to the dev machine and reference them instead of the 4.5 ones? (That said, testing on the same OS of end users' should still be a recommended approach). If you have other ideas you're also appreciated to submit via below site. It is the official channel to inform our product team.

    http://visualstudio.uservoice.com/forums/121579-visual-studio


    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.





    Monday, June 04, 2012 3:10 AM
    Moderator
  • Ah, you mean like the suggestion Make .NET 4.5 work on any OS that supports 4.0? Which is only the top 1 voted suggestion under the .NET category?

    [sarcasm] I don't know how we could have overlooked that... [/sarcasm]

    Judging by the top voted suggestions across the main categories, you're not exactly listening to user voices, now are you?

    Monday, June 04, 2012 9:39 AM
  • @Allen Chen-

    Will that work?  Can I get ONLY .NET 4.0 assemblies running (for debugging my app) on a machine that has .NET 4.5 installed?

    If so, that is an example I would LOVE to see.  If we can get everything from System to WPF libraries running .NET 4.0 that would solve the problem.

    Basically it would force a Side-By-Side scenario for my development purposes.

    Have you done this?  Or was this random musings?  If you have done it, can you please post a walk through on how I could do it?  (So I get ALL assemblies using.NET 4.0, not just a few WPF ones.)

    I would accept that as a valid answer to this problem.

    Thanks

    Monday, June 04, 2012 5:57 PM
  • Hi,

    My bad it doesn't work. I justed tried that. I thought it should work after uninstalling the .NET 4.5 assemblies from GAC and put the 4.0 ones in the app's private path. But the test result shows it doesn't. Let me consult internally to see how to handle this. Will get back ASAP.


    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, June 05, 2012 7:06 AM
    Moderator
  • Ah, you mean like the suggestion Make .NET 4.5 work on any OS that supports 4.0? Which is only the top 1 voted suggestion under the .NET category?

    [sarcasm] I don't know how we could have overlooked that... [/sarcasm]

    Judging by the top voted suggestions across the main categories, you're not exactly listening to user voices, now are you?

    No I don't mean that. The issue you mentioned is about supporting .NET 4.5 on some OS that is not supported at this moment (though it probably may also help on your scenario) while yours is a different one (In .NET 4.5 environment, get a way to let WPF application reference .NET 4.0 assemblies at runtime). I think you'd better add a new idea on that site.


    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.





    Tuesday, June 05, 2012 7:14 AM
    Moderator
  • I beg to differ.

    The problem described here is caused by the intentional and artificial blocking of updates/service packs for .NET on specific operating systems. (And .NET 4.5 is a service pack for .NET 4.0, regardless of the spin you create.)

    Under normal circumstances (that is without blocking updates), the bug would be fixed by installing the latest updates and/or security fixes. Installing the latest updates and/or security fixes is the norm. And customers running into specific bugs solved in updates can be told to update.

    However, you are intentionally denying customers the choice of installing the bug fixes.

    So now the problem arises that we need to support both buggy and fixed versions of the "same" runtime version of the CLR for several years to come. While at the same time making it nigh impossible to actually debug the buggy frameworks, as your latest and greatest OS and development environment require the fixed version of the framework, while it is impossible to run other build versions of GAC libraries for debugging.

    So blocking updates to .NET 4.5 for XP and 2003 machines in combination with replacing 4.0 causes this question.

    This problem is quite unique for .NET 4.5, mind you. As for Java, C++/MFC, Ruby, Python, Perl, etc., etc., it has never been the case that a patch/update/upgrade of a existing version of the runtime libraries was blocked for specific OS versions. Plus, new versions were always released side-by-side, with the old version remaining as-is to avoid version incompatibilities. This was also the case for .NET. Up until 4.5 that is.

    .NET 4.5 should never, ever have been an in place upgrade. It violates just about every rule of versioning even Microsoft itself advocates. You do not add new features to libraries (or OS requirementsfor that matter) while retaining the same version designation.

    Tuesday, June 05, 2012 9:18 PM
  • For those who read this post, here is the problem with the .NET 4.5 In-Place Upgrade:

    It assumes that the developer is happy to have .NET 4.0 bugs fixed when developing "Targeting .NET 4.0" (with .NET 4.5 installed).

    But the developer NEEDS to see them. They need to break while debugging so that workarounds can be put in place (or features postponed/canceled). 

    Because if you develop "Targeting .NET 4.0", then you clearly plan to run on a machine that DOES NOT HAVE .NET 4.5!

    Here is an example that explains this:

    A WPF developer creates an application using the new Visual Studio 2012 (which requires .NET 4.5).  The developer targets the application to .NET 4.0 (because his company still has a lot of Windows XP machines).

    During development an ObservableCollection is bound, grouped and sorted.  The developer does not realize that this causes a severe bug in .NET 4.0.  And since since .NET 4.5 is installed on his development machine, this bug will not show up during his debugging.

    When the application is released, it will fail when run on a Windows XP machine (because XP cannot run .NET 4.5).

    The bugs fixed by .NET 4.5 are a HUGE problem.

    Because unless I know and watch out for all of them (and Microsoft will not post a bug fix list) then I can't know that I am not having bugs hidden from me by .NET 4.5 while I develop.

    These hidden bugs are the real problem of the in-place upgrade.  The problem no one will talk about.

    So my options are to:

    1. Ban .NET 4.5 from my company.

    2. Try and set every developer up with a Windows XP box to remote debug on (and hope and pray that they follow that practice (not likely))
        [UPDATE: Remote Debugging to Windows XP is not supported in Visual Studio 2012.]

    3. Add an extra layer of Windows XP compatibility testing and hope that it catches everything (think of all the checks you do while debugging and think if any post development testing step will really replace that.)

    None of these are good options. But even though I want to go with #2, my management has told me they are going with just banning .NET 4.5 (and VS 2012).

    While I don't like it, I am grateful my company recognized this problem before we went and upgraded all our developers and started seeing bugs in production.

    I anticipate the "Target .NET 4.0" feature will really catch a lot enterprises off guard and cause some production downtimes.

    ------

    Note:  Even though the In-Place Upgrade is going to cause problems for my company, I worry even more that Microsoft will put .NET 4.5 in a Windows 7 Service Pack and force us to upgrade!  That would be a HUGE mess.

    • Marked as answer by Vaccanoll Friday, June 08, 2012 10:53 PM
    • Unmarked as answer by Vaccanoll Friday, June 08, 2012 10:53 PM
    • Marked as answer by Vaccanoll Monday, June 11, 2012 3:45 PM
    • Edited by Vaccanoll Tuesday, July 31, 2012 5:45 PM
    Friday, June 08, 2012 10:52 PM
  • Throwing my voice behind this as well.

    If the information in this thread is accurate about how .NET 4.5 interacts with an existing install of .NET 4.0, this is REALLY bad.  You can say Windows XP is a really old operating system, etc, etc, and you would be right.  But, ultimately, our clients are the ones who pay the bills, and our clients still have a LOT of Windows XP and Server 2003 machines (Windows 7 and Server 2008 ones are just starting to show up).

    If installing .NET 4.5 and/or Visual Studio 2012 (I assume the new VS will automatically install the new .NET 4.5) means we can no longer reliably develop .NET 4.0 applications for our clients, then we will not upgrade.  In fact, we will probably not be able to upgrade until after the last Windows XP / Server 2003 machine is no longer in production use by our clients.  It was suggested above that Windows 8 might also "come with" .NET 4.5.  If that is the case, then that is another upgrade we will not be able to consider.

    Saturday, June 09, 2012 3:32 PM
  • First off, I agree that this is certainly an issue.  However aren't we as software developers really caught between a rock and a hard place here?  Many of you are saying you will not install or develop with anything that installs .NET 4.5 because of bug fixes in .NET 4.5 that would hide issues with your application on a system with .NET 4.0 (and not .NET 4.5).  But isn't the reverse true as well?  If you solely develop against .NET 4.0 you are still going to have to test with .NET 4.5 to make sure your app works with .NET 4.5.  You can't control whether the .NET 4.5 framework gets installed on an end-user's system so ultimately you are going to have to test your app with .NET 4.0 and .NET 4.5.  I agree that this stinks, but I am not sure how banning Visual Studio 2012, Windows 8 and .NET 4.5 is going to lessen the testing burden that is being placed on development teams with Microsoft's decision to do an in-place upgrade of the .NET 4.5 framework.

    Shane

    Wednesday, June 13, 2012 3:21 AM
  • First off, I agree that this is certainly an issue.  However aren't we as software developers really caught between a rock and a hard place here?  Many of you are saying you will not install or develop with anything that installs .NET 4.5 because of bug fixes in .NET 4.5 that would hide issues with your application on a system with .NET 4.0 (and not .NET 4.5).  But isn't the reverse true as well?  If you solely develop against .NET 4.0 you are still going to have to test with .NET 4.5 to make sure your app works with .NET 4.5.  You can't control whether the .NET 4.5 framework gets installed on an end-user's system so ultimately you are going to have to test your app with .NET 4.0 and .NET 4.5.  I agree that this stinks, but I am not sure how banning Visual Studio 2012, Windows 8 and .NET 4.5 is going to lessen the testing burden that is being placed on development teams with Microsoft's decision to do an in-place upgrade of the .NET 4.5 framework.

    Shane

    While I cannot speak for others, our software is developed for specific clients, not the general public - you can't go to some store and buy our software, so we do not need to worry about what random user somewhere does to their machine.  Our clients do not typically go off and install new software on an existing machines unless there is a need for it.  Frequently, that need comes from us (such as when we asked them to install .NET 4.0 when we upgraded from .NET 2.0).  In this case - we essentially CAN control whether the .NET 4.5 framework gets installed - and we will have to make a point to tell them NOT to install it.
    Wednesday, June 13, 2012 1:43 PM
  • Hi,

    Can the "Windows XP Mode" be utilized to run the application using FW 4.0 on Windows 7?  If I understand it correctly, the "Windows XP Mode" is an XP virtual machine running on the Windows7 system.  Therefore, FW 4.5 cannot be used in this VM.  Thus, running the application in "Windows XP Mode" will essentially run it in with FW4.0.

    I've got a similar need to test FW4.5 and FW4.0... I'm installing "Windows XP Mode" to see if I can get things set up for a fairly simple way of testing using both frameworks.  Testing FW4.5 will run the application directly on Windows7, testing FW4.0 I'll run the application in "Windows XP Mode".

    Using a VM is quite a bit like using another system... but then again, it's just one "box".   In terms of licensing costs, "Windows XP Mode" is provided for Windows7 Professional/Ultimate/Enterprise editions, I have an MSDN subscription so the Visual Studio license isn't going to be a concern for me, anything else, though... that's an interesting issue.   The inconvenience, I am hoping, is going to be reduced to changing windows, not machines.

    Reece

    Thursday, June 14, 2012 12:25 AM
  • Hi,

    This will defiantly give us problems and a lot of extra work. I just made a statistic check of what OS our customers are running our software on and it looks like this:

    May 2012- Server Side:
    55% - Windows Server 2003
    22% - Windows Server 2008 R2
    16% - Windows Server 2008
    07% - Windows SBS 2011

    May 2012 – Client Side:
    55% - Windows XP
    47% - Windows 7
    04% - Windows Vista

    and one year ago it looked like this

    May 2011- Server Side:
    77% - Windows Server 2003
    13% - Windows Server 2008
    08% - Windows Server 2008 R2
    02% - Windows SBS 2011

    May 2011 – Client Side:
    72% - Windows XP
    23% - Windows 7
    05% - Windows Vista

    Our customer base is 100% manufacturing companies. Of course the usage of Windows XP and Windows Server 2003 are going down but it will still take several years before we can stop support Windows XP and Windows Server 2003.

    Thursday, June 14, 2012 6:05 AM
  • >Then, when it is run on a Windows XP machine with only .net 4.0 on it, there will be bugs that make me look bad.

    Yes this could be an issue. To make sure your application behaves the same way in dev time and run time you probably need another dev machine that has only .NET Framework 4.0 installed for testing purpose (and use remote debugging if needed, etc.).

    I'm puzzled by this answer, and indeed, by the whole question. .NET 4.5 is advertised as a side-by-side installation, but if you look on a machine that has both 4.0 and 4.5 installed, in the folder...

    C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\

    ...you'll see folders for 4.0 and 4.5, with different DLLs in them. They seem to be two separate installations.

    Moreover, Scott Hanselman points out on his blog that you can see if you are running 4.0 or 4.5, as if you try to use something from 4.5 and you're using 4.0 (such as the new System.Web.ModelBinding class), you'll get an error. That sounds like if you're targetting 4.0, you're actually using the 4.0 DLLs, and so would see any bugs that existed in 4.0. I just tried this, and verified that it is correct.

    Please can you clarify this?


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, June 14, 2012 3:27 PM
  • Reference assemblies contain no actual implementation, only the public method signatures (check with ildasm if you don't believe it). The actual assemblies are in \Windows\Microsoft.NET\Framework\v4.0.30319 and the GAC for 4.0 and newer in \Windows\Microsoft.NET\assembly. You can clearly see that there are no separate files for 4.0 and 4.5.

    VS uses the reference assemblies so you only see signatures that are available for your target framework of choice at design time, but in the actual build only the strong name is preserved and the assembly is loaded from GAC at runtime.

    Thursday, June 14, 2012 5:35 PM
  • Hi Greg,

    Thanks for the reply, I didn't know that about the assemblies. That would explain how Scott Hanselman was able to do his trick, because he was using something that just didn't exist in 4.0, so there won't have been a signature for it in the reference assembly. With something that does exist, but has a different implementation, both reference assemblies will end up pointing at the same actual implementation.

    Did I get that right? Thanks again.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, June 14, 2012 5:39 PM
  • But what Scott Hanselman did not show was Fixed Bugs (the point of this thread).  I made a point of this in the comments (which was ignored).

    If you try to use a NEW FEATURE of .net 4.5 while targeting .net 4.0 then you are property blocked and protected.

    But if you use a fixed bug there is no such protection.  The amount of fixed bugs is very large (it has been 2 years since a release).  And Microsoft will not release a full list of fixed bugs.  So really you have NO IDEA how much you are relying on these changes while you debug.

    And really the line between fixed bugs and features is blurry (they are both code changes). 

    The key point is that if you run .net 4.5 on your development machine then you will not see the bugs that your XP users will see.  This is because you will be running a different version of .net (4.5).

    And the really insidious thing here is that you don't even have to install Visual Studio 2012 for this disaster to happen.  Once you upgrade to .net 4.5, then even Visual Studio 2010 will use the new .net binaries.

    Thursday, June 14, 2012 5:49 PM
  • Yup, that's the point I was making (and asking for confirmation I got it right).


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, June 14, 2012 6:27 PM
  • Yes, that's the way it works. It's the compiler that actually blocks you from using the .NET 4.5 API not the runtime. When you're using reflection to detect a .NET 4.5 feature, you're working around the compiler block.
    Friday, June 15, 2012 2:36 PM
  • Is this really that different from previous upgrades?

    • .NET 3.0 was .NET 2.0 SP1 plus some additional assemblies. If you installed it, your .NET 2.0 applications would start using the service pack versions.
    • .NET 3.5 was .NET 2.0 SP2 plus .NET 3.0 SP1 plus some additional assemblies. If you installed it, your .NET 2.0 applications and .NET 3.0 applications would be using the service pack versions.
    • .NET 4.0 used a different CLR, so I don't know that it upgraded any of the .NET 2.0, 3.0 or 3.5 assemblies
    • It appears that .NET 4.5 is something like .NET 4.0 SP1 plus some additional assemblies.

    Am I missing something?

    I could be missing something like an official statement from Microsoft.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Wednesday, June 20, 2012 6:15 PM
  • John Saunders,

    The issue is supported operating systems. 

    When .NET 3.0 was released it dropped support for Windows 2000.  It was released in November of 2006.   At that time Windows 2000 was running on 8% of PC Computers.

    .NET 4.5 is dropping Windows XP support.  Assuming .NET 4.5 releases soon, the usage of Windows XP on PC Computers is 26.8% - 44.85%

    So 8% vs 27%-45%

    A full half to quarter of the PC market vs less than a tenth.

    So, while Microsoft has done this "Bug Hiding" before the impact was always been minimal (less than a tenth).  This time it has a huge impact. (1/4 to 1/2 depending on if you believe w3schools or Wikipedia).

    The "whys" here are interesting (ie failure of Vista, enterprises slow to upgrade Operating Systems).

    But in the end it does not matter.  The result is the same.  Microsoft is dropping an operating system that is still used by a massive number of Customers.  And the "mult-target" feature for those customers is dangerous at best (for reasons described in the "accepted answer").

    Wednesday, June 20, 2012 6:53 PM
  • Is this really that different from previous upgrades?

    • .NET 3.0 was .NET 2.0 SP1 plus some additional assemblies. If you installed it, your .NET 2.0 applications would start using the service pack versions.
    • .NET 3.5 was .NET 2.0 SP2 plus .NET 3.0 SP1 plus some additional assemblies. If you installed it, your .NET 2.0 applications and .NET 3.0 applications would be using the service pack versions.
    • .NET 4.0 used a different CLR, so I don't know that it upgraded any of the .NET 2.0, 3.0 or 3.5 assemblies
    • It appears that .NET 4.5 is something like .NET 4.0 SP1 plus some additional assemblies.

    Am I missing something?

    The big difference is that .NET 3.0 and .NET 3.5 was avalible to all OS that supported .NET 2.0.

    .NET 4.5 is NOT avalible to all OS that is supported by .NET 4.0. So the big difference is that the bugfixes for 4.0 that is included in 4.0 will no reach computers running Windows XP and Server 2003.


    • Edited by Thomas B Wednesday, June 20, 2012 6:55 PM
    Wednesday, June 20, 2012 6:55 PM
  • Ok, so there's no technical difference, only a difference in support?

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Wednesday, June 20, 2012 7:02 PM
  • Ok, so there's no technical difference, only a difference in support?

    I would say that there is a big technical difference. The customers will be running different versions of .NET 4.0 and we as software developer cant do anything about it. For previous versions we could allways require .NET 3.5 to be installed, but we cant do that with .NET 4.5. The result is that we can by "misstake" develope software that is dependent of the bugfixes in .NET 4.0 (included with .NET 4.5), then on customers XP and 2003 the customers will get problems.

    I my case 55% of our customers computers are runing XP and 2003 server and that will ofcourse give us big problems.

    Wednesday, June 20, 2012 7:09 PM
  • BTW, that's not a "technical" problem.

    Also, BTW, if you run your automated tests on systems which do not have .NET 4.0 installed, then you won't have a problem with depending on bug fixes. In fact, since Windows XP is so old, I can't imagine why you're not using it for running all of your tests, automated or not.

    Whether it was this version, or some other version, it was pretty clear that there would eventually be a version of .NET that did not support Windows XP and Server 2003. Whenever that happened, you would have to be developing using the version of .NET that your customers would ultimately be using. I don't see why it's so unexpected.

    I mean, have you been telling your clients that Microsoft would be supporting Windows XP forever, so they didn't ever have to worry about it?


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Wednesday, June 20, 2012 9:18 PM
  • The reason it is unexpected is because in the past Microsoft has waited until the OS is in single digit usage before dropping it from .NET.

    Windows XP still has a commanding portion of the market.  (At least a quarter of ALL PCs.)



    • Edited by Vaccanoll Wednesday, June 20, 2012 9:24 PM
    Wednesday, June 20, 2012 9:22 PM
  • I have not problem with .NET 4.5 not releaseing to old OS. What i would like is that bugfixes for .NET 4.0 should be released for all OS that supports .NET 4.0, not only for Vista and older.

    Regarding to clients using XP. I have several large customers (10000+ employees) and these customer have alot of XP still running, and I am pretty sure that I can't push them to change OS on there computers even if I liked to :)

    Wednesday, June 20, 2012 9:23 PM
  • I mean, have you been telling your clients that Microsoft would be supporting Windows XP forever, so they didn't ever have to worry about it?

    It's not a case of what we tell our clients. Many of them are very happy with XP, and see no reason to spend money to upgrade. A lot of people were seriously put off by Vista, which is presumably why XP has hung on so long.

    I can tell my clients to upgrade until I'm blue in the face, but they will simply ask me why they should spend the money. Microsoft needs to face the facts - a significant amount of people are still using XP, so even if they decide to drop support for it, they simply cannot release something that is going to cause problems on this scale.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Wednesday, June 20, 2012 10:07 PM
  • Update: I've reported this issue to our product team. So please be ensured that our product team is aware of this issue. At this moment, unfortunately, no more information can be shared.

    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.






    Thursday, June 21, 2012 6:33 AM
    Moderator
  • Whenever that happened, you would have to be developing using the version of .NET that your customers would ultimately be using. I don't see why it's so unexpected.

    The problem is that we can't develop using the version of .NET that our customers will be using on a PC which has .NET 4.5 installed.

    4.5 replaces 4.0; if you install 4.5, you cannot develop for 4.0 on that PC.

    The only "solution" is to maintain two PCs per developer - one for 4.5 and one for 4.0 - along with the associated hardware and licensing costs.

    And yes, I'm aware you could use a VM, but you'd still need hardware capable of running that VM, and you'd still need licenses for Windows, Visual Stuido, ReShareper, etc.

    Thursday, June 21, 2012 11:37 AM
  • Thanks for this thread, you probably saved me a lot of pain. I was planning on moving my development to .NET 4.0 after the VS11 release. I am in a similar situation as yourself - my customers are manufacturing companies, they have a very slow lifecycle. There are lots of XP machines and there will be lots of XP machines for the foreseeable future. I can't double the testing process and I can't have mysterious production bugs. I guess I'll either stick with VS10 and be very careful not to accidentally install .NET 4.5 somehow, or, more likely, just target 3.5. Microsoft is nailing one bad decision after the other these days.
    Thursday, June 21, 2012 12:11 PM
  • Microsoft is nailing one bad decision after the other these days.
    To be fair someone should contact the marketing department at Microsoft and tell them that for once they are not to blame :-)
    Thursday, June 21, 2012 12:15 PM
  • There is definitely a need for a .NET 4.0 Service Pack 1 with only bug fixes, that can be installed on the same platforms as .NET 4.

    When developing one screen, I used three bug fixes without knowing it just because I had .NET 4.5 installed. The three bugs that are fixed for me were:
     - Changing the items source of a WPF ListBox with multi-selection enabled and previously selected items causes an exception when you select a new item.
     - Setting IsEnabled = false on a WPF DataGrid sets the SelectedItem to null (this is a change in behavior). [Connect Link]
     - Making a WCF call in a Task can cause the SynchronizationContext to become null. [Social Link]

    I was really angry when I discovered all of this was failing without .NET 4.5. Mind you, this was a simple screen in a simple application. I don't know of the other hundreds of bug fixes / changes in behavior you could potentially encounter.

    While I'm glad those bugs are fixed, I really need to be able to rely on the fix rather than having to work around them. I have now totally wiped VS2012 and .NET 4.5 from my computer and don't plan on reinstalling them soon: it's way too risky. While using a XP VM with .NET 4 is feasible, it's a solution to a problem that shouldn't exist.



    Thursday, June 21, 2012 4:46 PM
  • John Saunders,

    This is partly a technical issue and partly a support issue.  The "issue" is divided into three parts.  If any of the parts are missing then this issue goes away:

    1. The next version of .net is an in-place upgrade over the previous version of .net. (This allows for "bug hiding".)
    2. The next version of .net drops an operating system that was supported in the previous version of .net.  (This creates a platform for the bugs to hide on.)
    3. The operating system that is dropped is still heavily used by customers.  (This means that someone cares that the bugs are hiding.)

    As I said above, if you lose any of those parts then there is no problem .  Past upgrades of .net have never had all three of these together at one time.  So there has never been a problem.

    But now the upgrade from .net 4.0 to .net 4.5 has all three of them.  That is the "difference from previous upgrades".  And it leads to the issues that Julien Lebosquain saw. 

    And I think as VS 2021 goes live it will start happening a lot (and create a fair amount of negative press for VS 2012 and .net 4.5), unless Microsoft owns up to the problem and at least makes an announcement to warn developers about it.

    Thursday, June 21, 2012 6:18 PM
  • Richard, you can develop using the version of .NET that your customers will be using, by not installing .NET 4.5 on those systems. If there were a .NET 4.0 SP1, and if your customers had not yet installed it, then you would need to develop (or at least, test), on a system which did not have 4.0 SP1 installed.

    Let's also keep in mind what the specific impact of this problem is. You could ship code that you think works, but it would actually fail on the customer site. If the only bugs in your code come from differences in .NET Framework version, then you've got some really great code! The mitigation involves doing exactly what you would do if this were a bug that you had introduced into your own code: you would fix the bug.

    And, yes, you might have to use a VM for that. You'd want a machine running Windows 7 so that you could use Windows Virtual PC, and you'd want to have enough memory, and you'd want to have an MSDN subscription that would take care of the license costs.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Thursday, June 21, 2012 7:41 PM
  • Thanks for separating the issues.

    I think you'll find that the problem isn't as widespread as you may think. Although there do seem to be pockets where Windows XP is still in wide use, you may find that most developers have been more fortunate than you in terms of their customers.

    Also, many developers use separate systems for build and test. The choice of desktop development environment doesn't have quite the same impact in that case.

    Finally, although you've had a nasty surprise, I think the ultimate impact won't be that great, even before Microsoft comes up with .NET 4.0 SP1: you'll find many of these bugs during UAT, or at worse, during the first few weeks that the new version is out at your customers' sites. You'll fix them, and get the new version out, and be done.

    And just think: you'll be able to blame Microsoft!


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Thursday, June 21, 2012 7:47 PM
  • >>You'll fix them, and get the new version out, and be done.

    That will not be the case for us.  We are a medical company that cannot be so tolerant of bugs.  Other industries may be more easy going on bugs, but we cannot be.

    After I relayed the information about the in-place upgrade of .net 4.5 to my management team, they blocked .net 4.5 from our entire corporation.



    • Edited by Vaccanoll Thursday, June 21, 2012 11:38 PM
    Thursday, June 21, 2012 11:36 PM
  • If there were a .NET 4.0 SP1, and if your customers had not yet installed it, then you would need to develop (or at least, test), on a system which did not have 4.0 SP1 installed.

    Actually we wouldn't - we would tell our customers to install 4.0 SP1.  And that would work because a SP1 release that only fixed bugs would not drop Windows XP / Server 2003 as supported operating systems (unlike the 4.5 release which adds new features).

    Let's also keep in mind what the specific impact of this problem is. You could ship code that you think works, but it would actually fail on the customer site. If the only bugs in your code come from differences in .NET Framework version, then you've got some really great code! The mitigation involves doing exactly what you would do if this were a bug that you had introduced into your own code: you would fix the bug.

    I don't think anyone here is pretending we release things without ANY bugs.  That's crazy!  And if someone is saying that, they are a better developer than I!  But, part of our job in serving our clients is to head off as many of these bugs as possible before they go into production.  What has been identified here is a potential cause for a number of problems, so we are trying to head it off.

    Thursday, June 21, 2012 11:48 PM
  • "Cannot release bugs"? In that case, I would have thought your development processes would not depend on which version of .NET is running on a Developer machine.

    I would also have thought that your customers would wish to be running on a supported operating system. What's the EOL for Windows XP? 4/8/2014?


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, June 22, 2012 1:27 AM
  • What you say makes sense. I would just suggest that you do your testing on a system running the same service packs as your customers, regardless of which version you use for development. Similarly, your build machines might want to be restricted as to which .NET version they run.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, June 22, 2012 1:29 AM
  • What you say makes sense. I would just suggest that you do your testing on a system running the same service packs as your customers, regardless of which version you use for development. Similarly, your build machines might want to be restricted as to which .NET version they run.

    I think another concern I understand here is that one can't use VS2012 (and all of its compelling new features). VS2010 is also too buggy and too slow compared to VS2012. So one have something better (VS2012), but can't use it because of these technical issues.

    Friday, June 22, 2012 1:45 AM
  • Sorry, I don't get that. Why can't you use VS2012 on your desktop, but use VS2010 to build?

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, June 22, 2012 2:43 AM
  • Sorry, I don't get that. Why can't you use VS2012 on your desktop, but use VS2010 to build?

    Well, it surely can be done. But that way, the workflow become less straightforward than it used to be. Would it be more fun to do that instead of doing dev and build in the same VS?

    Friday, June 22, 2012 4:33 AM
  • Sorry, I guess I take TFS and automated builds for granted.

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, June 22, 2012 5:05 AM
  • Sorry, I guess I take TFS and automated builds for granted.

    Despite the use of separate build and test machines, won't you verify first what you've done on your dev machine? Or are you letting the build and test machines tell you later, especially in a scheduled build and test?

    Friday, June 22, 2012 5:10 AM
  • I am likely to verify on my local machine, in which case (with .NET 4.5 or .NET 4.0 "SP1") the code will work.

    I will then check in the code and the CI build (running .NET 4.0) will run the unit tests.

    If those pass, then I'll deploy to the Integration environment and test what I've done. If I'm luckly, I'll now find the bugs that were hidden by .NET 4.5/.NET 4.0 SP1.

    And next, QA will test it, and will be much more likely to find the bugs.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, June 22, 2012 5:14 AM
  • From a corporate standpoint, this is an enormous problem. All existing 4.0 applications would have to be tested against the 4.5 framework to ensure they still work before 4.5 (or Win 8) could be rolled-out. Has Microsoft really thought this through?
    Friday, June 22, 2012 11:09 AM
  • I am likely to verify on my local machine, in which case (with .NET 4.5 or .NET 4.0 "SP1") the code will work.

    I will then check in the code and the CI build (running .NET 4.0) will run the unit tests.

    If those pass, then I'll deploy to the Integration environment and test what I've done. If I'm luckly, I'll now find the bugs that were hidden by .NET 4.5/.NET 4.0 SP1.

    And next, QA will test it, and will be much more likely to find the bugs.

    1. Verified on my machine (while I am coding that part of the feature) = $
    2. Found by the automated build (after I think I am done with that part of the feature) = $$
    3. Found by QA (after the whole feature is done) = $$$

      Also, some of the "hidden bugs" are hard to find bugs.  Things a QA department (or me writing unit tests) may not always think to test (that is why they got past Microsoft in the first place).  These bugs will only come out via the harsh use of a production user or the close lens of a Developer carefully stepping through the lines of code (ie debugging).

    4. So, Found by users = $$$$$$

    Rework gets more and more expensive the further it happens from when I actually do the work.  While I WANT to code with VS 2012 and use Async/Await.  It is just not worth the cost (in both rework and damage of bugs in production).

    • Edited by Vaccanoll Saturday, June 23, 2012 5:16 AM
    Saturday, June 23, 2012 5:13 AM
  • I am likely to verify on my local machine, in which case (with .NET 4.5 or .NET 4.0 "SP1") the code will work.

    So how would you do debugging (in verifying step) in this circumstance? Would you debug in a remote machine installed with .NET 4.0 only instead?

    Saturday, June 23, 2012 7:44 AM
  • This is what the "You Are Doing It Wrong" crowd doesn't get.  It's not that there aren't ways to test and debug this issue.  The problem is that the further away from the developer's box this gets, the more costly it is to a company!  This is something that should be found in local builds when the developer is testing her own code on her own box.  There is no reason this has to float up to the unit tests and QA to discover.

    Worse, those not familiar with the issue will likely spend hours trying to figure out why the heck the "4.0" XP is different from the sort-of "4.0" Windows 7 machine.  Not everybody follows developer forums and blogs.  Some people have work to do.

    I get so tired of somebody pointing out a perfectly valid issue/bug in forums and then know-it-alls jumping in and telling everybody they are doing it wrong and IF ONLY they did it the "right" way it's not an issue.

    This particular issue is not a show stopper, but it is going to cost a lot of companies a lot of unnecessary money.  I'm just glad I found out about it now, so I can tell my coworkers and project leads about it in time.


    Monday, June 25, 2012 2:30 PM
  • I'm in the same situation.

    Our customers are in the manufacturing branch. Production machines are updated not very often, and even new machines will be set up using XP because some programs they need to use are not ready for W7. (In fact, on some machines NT4 or even DOS is still in use!)

    W7 is just starting now, and we can not force our customers (which are way bigger than we are) to upgrade the OS.

    But what we can do is to require some prerequisites like a .NET Framework or an service pack.

    So my favorite would be that .net 4.5 is released for XP SP3 as well, so we could just install it and all above mentined problems are gone.

    I could imagine, that this is against the marketig strategy of MS, which in fact I can understand.

    So an alternative would be (as already mentined above) to create something like .net 4.1 which only contains the 4.5 bugfixes, but not the new features.
    We can then set this update on our system requirements for XP, and our customers will install it. (we did the same when we started to use .net 4.0 as well)

    If none of these two above is posible, then we will not be able to safely use VS2012 (unfortuenatelly).

    About buildserver and automated testing:
    We use a TFS server for source code and change tracking. But our development team is so smal, and our budget for servers and maintainance as well, that it is currently impossible to set up build and test servers. A lot of our SW needs special hardware (IO-Boards, Automotive gateways, ...), so it would be really hard to implement automated tests for this, which runs on every machine or VM.
    So none of the above mentined alternative test scenarios would work for us.

    Sunday, July 01, 2012 9:52 AM
  • I could imagine, that this is against the marketig strategy of MS, which in fact I can understand.

    Whilst I'm not happy about this situation, I think this comment is unfair. Microsoft (like any company on a similar situation) will only have a limited amount of resources to put into supported older OSs. The older they get, the less support they will give. This is a natural outcome of the way the world works. As time goes on, the older OSs get used less and less, and it becomes less viable to keep supporting them. When faced with the choice between implementing a new feature in .NET that doesn't work on older machines, or implementing it for the benefit of the majority, they would generally be correct in doing the latter.

    Where they seem to have got it wrong this time is that they obviously underestimate the number of people still using XP. Coupled with the fact that .NET 4.5 is an in-place installation, then people are facing problems.  To say that they did this deliberately to force people to upgrade is perhaps unfair.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Sunday, July 01, 2012 1:22 PM
  • Whilst I'm not happy about this situation, I think this comment is unfair. Microsoft (like any company on a similar situation) will only have a limited amount of resources to put into supported older OSs.

    I think you understood me wrong. I meant that I understand MS, why they do not want to support and old OS like XP anymore. I also do not like it when I have to support a product which is 10 or more years old. But if the customer requires it, then I do it.

    But, the problem of upgrading from XP to W7 is not only money. Also the breaking changes (drivers, ...) are a big problem. not everything can be solved with the XP mode.

    Sunday, July 01, 2012 2:18 PM
  • Thanks for separating the issues.

    I think you'll find that the problem isn't as widespread as you may think. Although there do seem to be pockets where Windows XP is still in wide use, you may find that most developers have been more fortunate than you in terms of their customers.

    Also, many developers use separate systems for build and test. The choice of desktop development environment doesn't have quite the same impact in that case.

    Finally, although you've had a nasty surprise, I think the ultimate impact won't be that great, even before Microsoft comes up with .NET 4.0 SP1: you'll find many of these bugs during UAT, or at worse, during the first few weeks that the new version is out at your customers' sites. You'll fix them, and get the new version out, and be done.

    And just think: you'll be able to blame Microsoft!

    John,

    I don't think the problem here is about Microsoft supporting XP forever - I certainly wouldn't expect them to, and neither should anyone else (although its usage may be a little more widespread than you think!).

    The problem is the method of versioning Microsoft have chosen to use for this latest release of the framework.  Had they opted to release it as .NET 5.0 and then stated explicitly that it will not be supported on XP that would be fine as far as I'm concerned.  It's this side-effect targeting where running a .NET 4.0 app on a machine with 4.5 installed could result in different behaviour, which is not desirable.

    At least if you have the ability to lock your app to specific versions you can predict behaviour (and thus support it). Just seems like they've made a very odd decision which results in a worst-of-all-worlds solution, when there were much better/easier ways for them to do it.

    Thursday, July 05, 2012 4:58 PM
  • The solution to this would have been simple.  Two possibilities spring to mind:

    - Release this version of the framework as .NET 5.0, tell XP users to get bent and either upgrade to Vista/7 or miss out.

    OR

    - Ensure this release is fully XP compatible.  Call it whatever they want, 4.1, 4.5, 4.0 SP1, but ensure it runs on all the same machines that 4.0 could.

    What certain people in this thread perhaps don't appreciate is that not everybody lives in a big corporate environment with TFS and test servers and QA departments and automated nightly builds etc.  Some people are in small shops, others still are one-man-teams that are selling their software to home users.  XP still has a significant enough market share for this to be a big problem.  It simply should not have been done in this manner.

    Thursday, July 05, 2012 5:07 PM
  • Option 3: If for some technical reason it's not possible to make 4.5 run on XP/2003, release 4.0 SP1 for those systems which includes the bug-fixes and as many of the breaking changes as possible.

    With the current system, I can foresee a situation in eighteen months time when some of our customers want to deploy Windows 8 on some of their PCs, but either they leave some PCs on XP, or other customers do. In that situation, all our developers would need two PCs - one to support .NET 2.0, 3.5, 4.0 on Vista or higher, and 4.5; the other to support 4.0 on XP/2003.

    If I was paranoid, I might think that was the plan - to make developers buy more Windows and Visual Studio licenses to keep the revenue stream flowing. But Microsoft wouldn't do that, would they?

    Monday, July 09, 2012 12:02 PM
  • If I was paranoid, I might think that was the plan - to make developers buy more Windows and Visual Studio licenses to keep the revenue stream flowing. But Microsoft wouldn't do that, would they?

    No, they never would! Because 'every developer has a Visual Studio subscription' which allows to install Visual Studio in all Versions and Windows in all Versions for testing and development reasons. ;)

    Or are there any developers out there without subscription !? ;)

    Tuesday, July 10, 2012 10:06 AM
  • Seems I'm late to this .NET 4.5 thread party. 

    I've found a severe issue with the .NET 4.5 in-place upgrade, where it all out breaks my applications that deal with C++/CLI binding. Any system with .NET 4.5 installed makes my commands never enable. I've made a test application which people can try out.

    Download it here from my skydrive. 

    Basically what worked from .NET 3.0 to 4.0 for me no longer works at all in 4.5

    Edit: I've opened a connect issue for this here.
    • Edited by jippers Tuesday, July 17, 2012 3:57 PM added the connect issue
    Monday, July 16, 2012 6:34 PM
  • These forums are not a mechanism for reporting bugs. You should use http://connect.microsoft.com/visualstudio.

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Monday, July 16, 2012 7:48 PM
  • These forums are not a mechanism for reporting bugs. You should use http://connect.microsoft.com/visualstudio.
    I think the point was more trying to raise Microsoft's attention on the issue. Just reporting a bug is likely to produce little effect. If MS see discussions here, and see the pain this is causing, they might just listen.

    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Tuesday, July 17, 2012 8:21 AM
  • "Just reporting a bug", is precisely the way to produce the effect of the bug getting fixed.

    Also, FYI, I was responding specifically to the post from "jippers", where he was effectively reporting a bug through the forums. There is a mechanism for getting bugs reported on Connect in to the product group, so that they can be prioritized and fixed. By reporting the bug on Connect, and including a link to this discussion in the Connect bug, then posting a link to the Connect bug in this thread, you produce the maximum effect.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Tuesday, July 17, 2012 3:54 PM
  • Sorry, I should have added the connect issued I had opened a couple days prior. I've added it to my post above. Also you can check it out here
    Tuesday, July 17, 2012 3:58 PM
  • Update: I've reported this issue to our product team. So please be ensured that our product team is aware of this issue. At this moment, unfortunately, no more information can be shared.

    Allen Chen [MSFT]

    Allen Chen,

    I was looking at Microsoft's Compatibility page for Visual Studio 2012 and I saw that "Remote debugging and profiling tools [are] not available for targeted platform [Windows XP]"

    Am I correct in understanding that Visual Studio 2012 will not even support a Remote Debugging connection to Windows XP?

    That means the ONLY solution is to have two completely separate development machines (one for .NET 4.0 and one for .NET 4.5).  That means double the hardware and double the licenses just to be able to use .NET 4.5.

    This is crazy.  Didn't anyone at Microsoft think this through?

    Your last reply seemed to be offering a glimmer of hope here that something might be done.  You said "no more information can be shared".  That implied that there was more information out there that could be a fix for this issue.

    Please, please, please hear the cries of your users and throw us a bone here.  I don't need ful .NET 4.5 support for xp (though it would be nice).  I just want to be able to install it with out messing up my .NET 4.0 development.

    Vaccano


    • Edited by Vaccanoll Friday, July 20, 2012 12:15 AM
    Thursday, July 19, 2012 8:58 PM
  • Let's conclude that 4.5 on Windows XP is not going to happen. But you can still try to push Microsoft to backport bugfixes to 4.0.

    If you have an MSDN subscription file a support incident for the bugs you would like to see fixed. Share the details of your bugfix request here so other people can file a support incident too with the same information. If enough people do it...

    Wednesday, August 01, 2012 8:33 AM
  • If enough people do it...

    Microsoft will still ignore us.

    Wednesday, August 01, 2012 12:40 PM
  • If enough people do it...

    Microsoft will still ignore us.


    They have to answer each support incident.
    Wednesday, August 01, 2012 4:45 PM
  • They have to answer each support incident.
    Yes, but sadly "We aren't going to fix it" is also an answer

    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Wednesday, August 01, 2012 5:17 PM
  • They have to answer each support incident.

    Yes, but sadly "We aren't going to fix it" is also an answer
    Doesn't mean we should stop trying. Microsoft has changed their minds in the past.
    Wednesday, August 01, 2012 6:05 PM
  • This also effects us as an .NET ISV. Can Microsoft please let us know their decision since .NET 4.5 has RTMEd? NuGet + this topic goes to show that the versioning system/process is broke.

    -Blake Niemyjski (Software Development Engineer)

    Wednesday, August 01, 2012 6:19 PM
  • I really do not understand Microsoft decisions any more. The company had a good reputation about making developer's life easier (yes, the developers that develop and thus, help to expand, THEIR platform) but i see that this is not the case any more...Ok, DO NOT make 4.5 supports XP if you want so for your politics reasons, but..."in-place- upgrade" so we have different files on our dev-machine (for .net 4) from our end (XP) users ) ??

    My work is in C# and i am one of those that *have* to install the new VS version, not because i care about new 4.5 stuff (i don't) but because i care more and more about C++ and VS 2012 brings enought this on the table for it.

    So, i have my dev machine with VS 2010 and all my C# work and i want to use VS 2012. I also have a spare, clean, machine so i can install it (VS 2012) there. I do not want to mess with TFS-Lab-Test-whateverothername test/build environment. I plan to move, eventually, my projects to the new machine (and new VS) and when i make some changes at some C# code, i will then transfer my project to the old machine (VS 2010), execute and test it there before o deploy to my (internal) company users.

    Do you think that such a (lame, i know) scenario would work ?


    • Edited by King Kikapu Monday, August 06, 2012 9:39 AM
    Monday, August 06, 2012 7:21 AM
  • My plan was to uninstall VS2010 and installed VS2012 while letting my existing application version in 4.0 and continue development on new IDE till 4.5 get matured and we can able to convince production upgrade to 4.5 as well. In our location there are lots of Xp machine as well as some Windows 7 machine.

    But now i see

    "Remote debugging and profiling tools [are] not available for targeted platform [Windows XP]"

    Any workaround for above mentioned restriction?


    Kamran Shahid Principle Engineer Development (MCP,MCAD,MCSD.NET,MCTS,MCPD.net[web])

    Thursday, August 09, 2012 5:41 AM
  • My plan was to uninstall VS2010 and installed VS2012 while letting my existing application version in 4.0 and continue development on new IDE till 4.5 get matured and we can able to convince production upgrade to 4.5 as well. In our location there are lots of Xp machine as well as some Windows 7 machine.

    But now i see

    "Remote debugging and profiling tools [are] not available for targeted platform [Windows XP]"

    Any workaround for above mentioned restriction?


    Kamran Shahid Principle Engineer Development (MCP,MCAD,MCSD.NET,MCTS,MCPD.net[web])


    If you install VS2012, you will also "get" .net 4.5, i.e., your .net 4 dll will be replaced and you will then have the mentioned problem...
    Thursday, August 09, 2012 10:11 AM
  • The only configuration (that I could see working) for .net 4.0 (but not XP) using Visual Studio 2012 is to have two development machines (they can be virtual):

    First Machine

    • Install Visual Studio 2012 (and by extension .net 4.5)
    • Windows 7 (Or Higher)
    • Code Here

    Second Machine

    • Windows Vista (or Higher)
    • Remote Debugger
    • .net 4.0 (Do not allow .net 4.5)
    • Debug Here

    Notes:

    • This is not a Windows XP solution.  Just .net 4.0
    • You have to resist the temptation to just debug on your First Machine
    • I have not tested this because:
    1. My boss does not think our developers will be able to resist the temptation (to just debug on the first machine).
    2. It is a pain to setup a second machine for something I will not use.

    • Edited by Vaccanoll Thursday, August 09, 2012 4:49 PM
    Thursday, August 09, 2012 4:28 PM
  • I really hope they end up releasing a patch for 4.0 on XP to at least bring it up to spec with the core CLR of 2012's 4.0 framework.  That would ease the situation considerably if you could make it a pre-req of your installer, but even that's tricky due to the way they've woven it into the 4.5 release.  There really should have been a 4.0 SP1 that was compatible with XP, Vista & 7 and included all the 4.0 fixes currently installed by 4.5.
    Thursday, August 09, 2012 9:57 PM
  • I really hope they end up releasing a patch for 4.0 on XP to at least bring it up to spec with the core CLR of 2012's 4.0 framework.  That would ease the situation considerably if you could make it a pre-req of your installer, but even that's tricky due to the way they've woven it into the 4.5 release.  There really should have been a 4.0 SP1 that was compatible with XP, Vista & 7 and included all the 4.0 fixes currently installed by 4.5.

    It would be nice if this happened. 

    But I don't see how it can.  Microsoft has painted them selves into a corner with all their bad decisions.

    The big one that messes this up is that .net 4.0 and .net 4.5 have the same version number (for reasons that pass my understanding). 

    Assuming they had a reason for this (beyond hating all developers that have to have users with both .net 4.0 and .net 4.5 installed), then they can't just release a new .net 4.0 release.

    Well... I guess they could.  They could just keep the same version number (again).  Heck, we are so far down this messed up versioning hole, might as well do it.

    Thursday, August 09, 2012 10:59 PM
  • King Any Idea then what can I do?

    Kamran Shahid Principle Engineer Development (MCP,MCAD,MCSD.NET,MCTS,MCPD.net[web])

    Friday, August 10, 2012 9:49 AM
  • The solution to this would have been simple.  Two possibilities spring to mind:

    - Release this version of the framework as .NET 5.0, tell XP users to get bent and either upgrade to Vista/7 or miss out.

    OR

    - Ensure this release is fully XP compatible.  Call it whatever they want, 4.1, 4.5, 4.0 SP1, but ensure it runs on all the same machines that 4.0 could.

    What certain people in this thread perhaps don't appreciate is that not everybody lives in a big corporate environment with TFS and test servers and QA departments and automated nightly builds etc.  Some people are in small shops, others still are one-man-teams that are selling their software to home users.  XP still has a significant enough market share for this to be a big problem.  It simply should not have been done in this manner.


    I don't buy this argument. There are numerous free tools for creating builds and you can get bare bones PCs for dirt cheap.  Visual Studio has built in testing tools (or again more free ones online) so I really don't see how you have to be a big corporation to use proper coding practices.
    Thursday, August 16, 2012 12:58 PM
  • The solution to this would have been simple.  Two possibilities spring to mind:

    - Release this version of the framework as .NET 5.0, tell XP users to get bent and either upgrade to Vista/7 or miss out.

    OR

    - Ensure this release is fully XP compatible.  Call it whatever they want, 4.1, 4.5, 4.0 SP1, but ensure it runs on all the same machines that 4.0 could.

    What certain people in this thread perhaps don't appreciate is that not everybody lives in a big corporate environment with TFS and test servers and QA departments and automated nightly builds etc.  Some people are in small shops, others still are one-man-teams that are selling their software to home users.  XP still has a significant enough market share for this to be a big problem.  It simply should not have been done in this manner.


    I don't buy this argument. There are numerous free tools for creating builds and you can get bare bones PCs for dirt cheap.  Visual Studio has built in testing tools (or again more free ones online) so I really don't see how you have to be a big corporation to use proper coding practices.

    Sure auto build and testing software is available for free and PCs are cheap.

    But the manpower to setup and maintain these is not. Also writing automated tests costs a lot of time too. Sometimes it's hard or even impossible to implement them. Especially if you need special or rare hardware to do so (Like a car or parts of it which are not yet available on the market).

    This is the world where I work: Low budget, too little time to do it right always, and a boss who gets a 'green' panic attac on every pc that needs to run additionally.

    Thursday, August 16, 2012 1:12 PM
  • Here's something I wish that many in this thread will get:

    Yes, there are still many developers who have to (or who feel they have to) develop on a single PC. There are still many companies who run on Windows XP.

    But this intersection, small shops with customers running Windows XP, is very much a minority case.

    Additionally, I think too much is being made of this problem. Let's say you accidently shipped a bug because "it worked on your .NET 4.5 PC" but not on .NET 4.0 on a customer's XP system. Just exactly how big a tragedy is that?

    Finally, far too many on this thread are not being constructive. You're just whining. Instead, if you want to see things change, then help Microsoft change them. Calmly describe your situation, making it clear how much it would cost you to change your environment to not have these problems. Clearly state the business cost of shipping one of these bugs. Complain in Connect, not in the forums. Publicize your Connect articles in the forums, in order to solicit votes.

    You might also take this opportunity to point this thread out to your XP customers. If they thought it was "OK" to continue running XP, you can show them that Microsoft really isn't going to go out of its way to solve XP-specific problems, so maybe they should plan to upgrade before the end of the decade.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Thursday, August 16, 2012 3:04 PM
  • XP is still very much in use in some sectors. Our customers are manufactoring comapnies over 50% of our customers client computer are still running XP and over 50% of the servers are still running Windows Server 2003. We have customers with 10 employese to 50.000 emplyes, and I would say that it is normaly the bigger companies that still use XP.

    One other thing to think about is where in the world you are. If you for exampel have customers in Chine then you know that XP much more used than in Europe.

    Convincing companies like VOLVO, SANDVIK and other big companies to updgred there XP computes is not easy, belive me I have tried.

    I acceppt that 4.5 don't get support for XP and Win2003, but then why make it an update for 4.0. Why not release it as 5.0 then we whould not have this problem at all. That is what most people are complaining about.

    Thursday, August 16, 2012 3:12 PM
  • Here's something I wish that many in this thread will get:

    Yes, there are still many developers who have to (or who feel they have to) develop on a single PC. There are still many companies who run on Windows XP.

    But this intersection, small shops with customers running Windows XP, is very much a minority case.

    Additionally, I think too much is being made of this problem. Let's say you accidently shipped a bug because "it worked on your .NET 4.5 PC" but not on .NET 4.0 on a customer's XP system. Just exactly how big a tragedy is that?

    Finally, far too many on this thread are not being constructive. You're just whining. Instead, if you want to see things change, then help Microsoft change them. Calmly describe your situation, making it clear how much it would cost you to change your environment to not have these problems. Clearly state the business cost of shipping one of these bugs. Complain in Connect, not in the forums. Publicize your Connect articles in the forums, in order to solicit votes.

    You might also take this opportunity to point this thread out to your XP customers. If they thought it was "OK" to continue running XP, you can show them that Microsoft really isn't going to go out of its way to solve XP-specific problems, so maybe they should plan to upgrade before the end of the decade.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    I'm not trying to wine here, but I want to answer some of your questions:

    If we tell our customer they have to upgrade because we want to use a newer software (VS 2012) and its hard to test for XP and W7 the answer is: 'We don't care' it's your problem and we do not want to upgrade to W7 now' (sad but true, I had this discussion already).

    What would it cost to ship a bug to our customer:
    We once had a smal bug which caused a 1 hour production breakdown. Our customer told us that this was a total loss of about 1 Million Euro.

    And now something productive:
    All we want is, that a .net 4.0 programm behaves the same on our VS 2012 deveopment machines and the Win XP target systems.
    May be I'm wrong, but to ensure this, MS would have to create an update for XP (some 4.1 or 4.5) and test it once.
    Or make 4.5 (or 5.0) not an inplace update. (also a one time job for MS)

    If 4.5 stays an inplace update as it is now, then all SW developers who have to support XP and W7 and want to use VS 2012 needs to test twice for every release.

    Thursday, August 16, 2012 3:27 PM
  • But this intersection, small shops with customers running Windows XP, is very much a minority case.

    Additionally, I think too much is being made of this problem. Let's say you accidently shipped a bug because "it worked on your .NET 4.5 PC" but not on .NET 4.0 on a customer's XP system. Just exactly how big a tragedy is that?

    [.....]   You might also take this opportunity to point this thread out to your XP customers. If they thought it was "OK" to continue running XP, you can show them that Microsoft really isn't going to go out of its way to solve XP-specific problems, so maybe they should plan to upgrade before the end of the decade.

    Can you please provide statistics/data showing that XP is "very much a minority case"?  In my experience, i.e. both in my present full-time job at a fortune 500 company where XP is still the majority OS on our desktop, and as an independent developer selling to home users, that is not the case.  Perhaps you have evidence to the contrary?

    As for the "just exactly how big a tragedy is that" statement, I was wondering whether to address it or considering that perhaps you were being sarcastic?  In the unlikely event that you're serious, I think if a customer of mine found that the software they'd been using since 2006 with no problems on their trusty XP home PC suddenly stopped working and my response was "go buy a new PC", they would be unhappy.  Not just due to my response but because their other software still works.  The net result is a lost sale.

    And if I tried that tack at my day-job, then... well let's just say it wouldn't be my day job for very much longer.  I suspect our organisation will not be using .NET 4.5 for this very reason (which IMO is a massive shame due to the useful advances I was hoping to take advantage of as a programmer).

    I think it's possible your job & development experience may be somewhat lesser compared to others posting here who are "whining", which is perhaps why you don't understand the seriousness of the issue.  I hope my explanation has helped you to understand it a little better.

    Thursday, August 16, 2012 3:43 PM
  • Calmly describe your situation, making it clear how much it would cost you to change your environment to not have these problems.

    Tried that. Microsoft ignored us.

    Complain in Connect, not in the forums.

    Tried that. Microsoft responded with, "Connect is for future versions, not for fixing bugs." On top of that, they recently embarked on a purge of the connect site, deleting a huge number of bug reports which they'd previously ignored.

    Here's something I wish that people like you would get: Telling us we're doing it wrong, or that our customers are living in the dark ages, doesn't help. Telling us to change the way we work, or to force our customers to spend time and money to upgrade their systems, just because Microsoft wants to kill XP, is not an answer.

    • Marked as answer by Vaccanoll Thursday, August 16, 2012 6:40 PM
    Thursday, August 16, 2012 5:20 PM
  • .NET Framework 3.0 was an additive (non-overlapping) feature layer that built on top of 2.0.

    .NET Framework 3.5 was yet another additive (non-overlapping) feature layer on top of both .NET 3.0 and .NET 2.0, but it included newer versions for those lower layers viz. 2.0 SP1 and 3.0 SP1 since it was built on top of those.

    There's a bit of confusion at times because installing .NET 3.5 chain installs the 2.0 SP1 and 3.0 SP1 layers. So effectively from a customer's point of view .NET 3.5 includes .NET 2.0 SP1 and .NET 3.0 SP1.

    .NET Framework 3.5 SP1 was a service pack refresh for all 3 layers, so in addition to the updated 3.5 (SP1) bits it also included 2.0 SP2 and 3.0 SP2. 

    Thanks,

    Jamshed Damkewala [MSFT]

    Friday, August 17, 2012 3:25 AM
  • One Problem i was having is they have discontinue setup project (.vdporj).

    I have a solution of about 50 odd projects including 10 setup projects.

    I have previously upgrade my VS2008 solution into Vs2010 easiliy and after some rleases i have upgraded the framework version as well.

    Now looks like i have to go for some third party tools for setup projects.Reinhard Ostermeier1 It will also human resource :) which is the most difficult thing to convince the management.


    Kamran Shahid Principle Engineer Development (MCP,MCAD,MCSD.NET,MCTS,MCPD.net[web])

    Friday, August 17, 2012 6:33 AM
  • This raises another part of this issue that I think needs to be made explicit. We're not only talking about the fact that your customers use XP. We're talking about the fact that you are in a shop small enough that you feel that having developers test code is a good idea.

    That's absolutely anathema in most places I've worked, even in "broke" government agencies. The idea of developers finding their own bugs is the punchline to a bad joke.

    BTW, I'm not necessarily saying your customers need to upgrade right now. I'm saying that, if a bug costs 1 million Euros, then maybe your customers should be paying you more money for Windows XP support.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, August 17, 2012 8:34 AM
  • I said,

    But this intersection, small shops with customers running Windows XP, is very much a minority case.

    So it's not XP that's the minority case: it's tiny software development shops with customers running XP that is the minority case.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, August 17, 2012 8:35 AM
  • it's tiny software development shops with customers running XP that is the minority case.
    As Quanta said, do you have statistics to prove that, or is it just your gut feeling?
    Friday, August 17, 2012 11:55 AM
  • That's absolutely anathema in most places I've worked, even in "broke" government agencies. The idea of developers finding their own bugs is the punchline to a bad joke.

    So that's another "you're doing it wrong" comment. Forcing people to change the way they work just to suit Microsoft's latest whim is not an acceptable answer.

    Even if you have a full QA department to test your code, isn't it better to catch and fix bugs during development, rather than waiting for someone else to catch it?

    And let's not forget that, unless you have VS Ultimate, you don't get IntelliTrace, so debugging a problem that only happens on someone else's PC is much harder.

    Friday, August 17, 2012 11:59 AM

  • So it's not XP that's the minority case: it's tiny software development shops with customers running XP that is the minority case.



    Once again I feel obligated to ask, do you have some statistics to back this up or are you just guessing?  What is it about a smaller software shop that makes you think they'd be less likely to have customers on XP?

    Given that this question is regarding the framework and not just WPF, I wonder if Windows 2003 Server will suffer from the same lack of .NET 4.5 support.  If so that affects web projects as well and the line becomes even more blurry for obvious reasons.  I think you're making some blanket generalisations here without really understanding the situation.

    Friday, August 17, 2012 12:44 PM
  • it's tiny software development shops with customers running XP that is the minority case.

    As Quanta said, do you have statistics to prove that, or is it just your gut feeling?

    It's experience and common sense.

    In fact, it's not just the intersection of "has Windows XP customers" and "is a tiny shop"; you also have to intersect with "adding a virtual machine running XP to test on is too great a burden" and "releasing bugs to customers is inordinately expensive". Otherwise, it would be acceptable to

    1. test on the single developer machine running .NET 4.5
    2. have the customers find the very small number of bugs caused by code that worked when running .NET 4.5 but which broke on .NET 4.0
    3. fix the bugs promptly and produce a new release
    4. repeat from step 1

    I get that there's a feeling of shock, betrayal, disbelief and abandonment, but I just don't see how this problem will have a serious, widespread, and practial impact.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, August 17, 2012 2:41 PM
  • Yes, Richard, "gravity sucks". If you drop a hammer, make sure you have no body parts under it.

    I'm not the first person in the world to notice that developers tend to miss many of their own bugs. You don't have to work with a "full QA department" to notice this. Just work with one good QA person. They're trained and experienced in finding the bugs your users will otherwise find. It can be truly amazing to see some of the bizarre bugs they'll find.

    Recent case in point: a QA person had the crazy idea to click a column header to sort a grid (that worked), but then to click above the grid and press Enter. For some bizarre reason, this sequence of clicks had moved the focus such that the Enter key was clicking a button placed in the grid header. There was no visual indication that the focus had changed, but the QA person thought to check this anyway.

    So, try working with even a single QA person, who will, obviously be using Windows XP to test with.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, August 17, 2012 2:48 PM
  • John,

    To make sure I understand - why are you limiting this to "small shops"?

    Why should ANY shop have to give more money to Microsoft because Microsoft chose to change the behavior of .NET 4.0 on certain operating systems, but not change it on others?

    Friday, August 17, 2012 2:49 PM
  • As Quanta said, do you have statistics to prove that, or is it just your gut feeling?

    --It's experience and common sense.

    Okay, so we'll go with "gut feel" rather than you having anything to back it up with.  I think that's all we needed to know.

    Hypothetically speaking (and I think at this point purely for amusement purposes and nothing else), what would you do if you'd written something in a specific way (such as pre-loading a large list of images) which appeared to work fine at first, but after a little while some bug reports started coming in from your XP customers and NOT your Win7/8 customers?

    Supposing at that point you discovered a memory leak in the framework was fixed in a core library of .NET 4.0 via the release of .NET 4.5 - a fix which will not be available for XP.  Had you known about this from the start, you would not have written a particular class in a particular way, but it's too late now - you already have.  And it works fine - just not on XP, and it never will.

    Do you set about re-writing the class to come up with a workaround that is completely unnecessary for your 7/8 customers?  Or do you tell your XP customers to get bent?

    I'm trying to give you explanations that you might be capable of understanding, so... do you see how neither of the above is a particularly desirable solution?  Either way you lose money, through lost customers or through lost development time.

    Also, not everyone has the luxury of even "one good QA person".  Some people are one-man-bands, others have a QA person who's responsible for all sorts of other tasks and will NOT catch something like a memory leak that gets worse over time.  Some people have pre-historic managers who hate IT and don't see why more resources should be allocated to testing something that, in their opinion, should already have been thoroughly tested by the person that wrote it.

    When people start telling others to change the way their IT department works all due to a new version of the .NET Framework being released, I think something slightly more serious is wrong.

    Friday, August 17, 2012 3:25 PM
  • Because only a smaller (or "more frugal") shop would have to pay more to spin up another virtual machine running XP, or else wouldn't already have a separate machine for testing.

    And, you do realize the difference between Windows XP and other Microsoft operating systems, don't you? One is over a decade old, and the others are not.

    In fact, it might (or might not) clarify things to perform a simple thought experiment:

    Consider the set of people or companies who want Microsoft to produce a .NET 4.0 SP1 that fixes all the 4.0 bugs addressed by .NET 4.5. Let's take up a collection. Let anyone from that set who wants to contribute to a collection for Microsoft. Let them pay into the collection the amount of money they think it's worth to them to have Microsoft produce and ship that service pack.

    The experiment is: how much money will be in the collection at the end of a month? Three months? A year? When will there be enough money collected to offset Microsoft's expense in producing and releasing that service pack?


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects


    • Edited by John Saunders Friday, August 17, 2012 3:33 PM thought experiment
    Friday, August 17, 2012 3:27 PM
  • what would you do if you'd written something in a specific way (such as pre-loading a large list of images) which appeared to work fine at first, but after a little while some bug reports started coming in from your XP customers and NOT your Win7/8 customers?

     I would fix the bug and ship the fix to my customers. I might swear a little, first.

    Supposing at that point you discovered a memory leak in the framework was fixed in a core library of .NET 4.0 via the release of .NET 4.5 - a fix which will not be available for XP.  Had you known about this from the start, you would not have written a particular class in a particular way, but it's too late now - you already have.  And it works fine - just not on XP, and it never will.

    Do you set about re-writing the class to come up with a workaround that is completely unnecessary for your 7/8 customers?  Or do you tell your XP customers to get bent?

     I would ensure that my customers understand the true cost of not upgrading their XP systems. Part of that cost is the additional cost to me to support them, since Microsoft isn't interested in supporting XP and Vista+ systems equally. I would offer them the opportunity to mitigate the additional time it will take me to support them, by offering them an add-on service contract. Any additional funds from customers purchasing that contract would go towards the additional resources necessary to support XP: that extra machine or an MSDN license, for instance.

    I would also ensure that Microsoft is aware of every single bug of this nature that only affects my XP customers. Perhaps they have underestimated the severity of the problem. Perhaps not, since I'm sure they get support calls from XP customers (so they know how many there are), and because they know which bugs they're not fixing in the service pack they're not shipping for XP.

    And, BTW, don't be getting the wrong idea of what I might or might not be able to understand. I've worked in companies of all sizes, from the "one man band (me)" to startups, to corporations with hundreds of thousands of employees. I know who you are, and I completely understand how you're getting the short end of the stick. Maybe in better economic times Microsoft might spend money for the service pack you'd like. They might do this even though it will "enable" more customers to not upgrade their XP systems.

    But in today's economy, well, not yet, if at all.

    Don't hide this from your customers. Let them see what Microsoft is doing. It might either be another reason for them to upgrade, or another reason for them to yell at Microsoft. Either way, they won't be yelling at you quite so much.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, August 17, 2012 3:46 PM
  • Uhhh... What does NuGet have to do with showing that the versioning system/process is broke?  IMHO, NuGet is one of the best things to hit the Microsoft development environment since Visual Studio 6 came out.

    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, August 17, 2012 3:47 PM
  • And, you do realize the difference between Windows XP and other Microsoft operating systems, don't you? One is over a decade old, and the others are not.


    Well, for now.  In a few months, Server 2k3 will fall under that same flag, and if .NET 4.5 isn't supported on that either, then a whole lot of ASP.NET web applications are going to be affected also.
    Friday, August 17, 2012 3:55 PM
  • Maybe in better economic times Microsoft might spend money for the service pack you'd like. They might do this even though it will "enable" more customers to not upgrade their XP systems.

    What does the economy have to do with releasing 4.5 as a different version rather than an in-place upgrade to 4.0?  Or are you implying this was a cynical move from Microsoft to somehow "break" XP and force users to upgrade, thereby producing more income for them?  If anything I'd think this move would work against them in that regard.  Case in point?  The company I work for is refusing to touch VS2012 or .NET 4.5, and I have to take the same decision for the software I write independently as a sizable percentage of my user base is still on XP.

    Incidentally, let's say you have some home users scattered across the globe - maybe 2-3 thousand.  You don't know exactly what OS each and every one of them is running but some of your anonymous usage stats show a lot of XP users still exist out there.  How exactly are you going to explain to all of them that they need to upgrade?  Are you going to mass email all of them?  Put up notices on your company website stating that XP won't be supported in the next version?  Track down each XP user individually and give them a phone call?

    This is not even about MS releasing a service pack or making 4.5 compatible with XP.  All they needed to do was LEAVE 4.0 ALONE and make v4.5 a separate version that could be targeted independently.  It's the combination of an in-place upgrade plus lack of XP support that causes this problem.

    It seems more like they went out of their way to do this the wrong way.

    Friday, August 17, 2012 4:07 PM
  • John, why do you think this is only a problem for small companies?  Bigger companies have bigger projects, and testing costs scale up geometrically not linearly.  It costs us millions of dollars a year to run all of our validation tests, and a great deal of that is the redundancy of having to test on multiple OSes. 

    Worse, the costs are not just in the running of the tests, but actually fixing the problems.  If a developer inadvertently used a .NET 4.5 bug fix that doesn't work on 4.0/XP, it could be a major effort to fix it--sometimes a completely different design is needed to work around it.  This happens to us frequently with WPF already--device drivers in XP are hideously bad (particularly nVidia Quadra) with WPF, so code that works fine on our developer machines running Win7 can cause BSODs on our customer's XP machines.  Now with .NET 4.5 we're seeing another whole class of bugs that only affect our XP machines.  Dropping XP is not possible for us, so we have to eat even more costs.

    What actually makes me angry here is that the whole issue could have been avoided if .NET 4.5 and 4.0 could be installed side by side.

    Friday, August 17, 2012 4:12 PM
  • I work for one of those "'broke' government agencies" and, as a developer, one of the items on my job description is, "Thoroughly tests all programs to ensure that a minimal number of bugs are released to production."  I've been pretty lucky so far, but one of the only times my boss has ever had negative words for me was when a bug got past me that he thought I should have spotted.

    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, August 17, 2012 4:24 PM
  • John, why do you think this is only a problem for small companies?  Bigger companies have bigger projects, and testing costs scale up geometrically not linearly.  It costs us millions of dollars a year to run all of our validation tests, and a great deal of that is the redundancy of having to test on multiple OSes. 

    Worse, the costs are not just in the running of the tests, but actually fixing the problems.  If a developer inadvertently used a .NET 4.5 bug fix that doesn't work on 4.0/XP, it could be a major effort to fix it--sometimes a completely different design is needed to work around it.  This happens to us frequently with WPF already--device drivers in XP are hideously bad (particularly nVidia Quadra) with WPF, so code that works fine on our developer machines running Win7 can cause BSODs on our customer's XP machines.  Now with .NET 4.5 we're seeing another whole class of bugs that only affect our XP machines.  Dropping XP is not possible for us, so we have to eat even more costs.

    What actually makes me angry here is that the whole issue could have been avoided if .NET 4.5 and 4.0 could be installed side by side.

    I agree that this is not limited to small shops (though I guess it is what you consider "small").  I work in a company of about 2000 employees and we write the software they use.  (About 30ish developers)

    Our company chose to not upgrade to .net 4.5 because of the added testing costs.  We would have to add another layer of .net compatibility testing.

    Plus if your QA does not do "shoot from the hip" testing, then this extra layer becomes even more difficult.

    How can you write test plans/scripts for an un-released list of bugs?  Microsoft will not release the bug fix list for .net 4.5.

    Our QA department is great!  They do some exploratory testing, but they mostly follow industry best practices for QA.  Those best practices are involved (and not really the point of this discussion), but suffice to say that they need to know what has changed between versions.  Changes can be gotten from Requirements/Backlogs and from tools like the MTM "Recommended Tests List".

    But because Microsoft will not say what has changed, the only thing we can do is "shoot from the hip" (or luck/intuition based) testing for .NET compatibility.

    That catches some bugs, but it is not very good for a medium to large shop.  So I would say this applies even more to a larger shop than a smaller shop.


    • Edited by Vaccanoll Friday, August 17, 2012 4:43 PM
    Friday, August 17, 2012 4:34 PM
  • This is not even about MS releasing a service pack or making 4.5 compatible with XP.  All they needed to do was LEAVE 4.0 ALONE and make v4.5 a separate version that could be targeted independently.  It's the combination of an in-place upgrade plus lack of XP support that causes this problem.

    It seems more like they went out of their way to do this the wrong way.


    Exactly!
    Friday, August 17, 2012 4:45 PM
  • Vaccanoll Very truly said about

    "I worry even more that Microsoft will put .NET 4.5 in a Windows 7 Service Pack and force us to upgrade!  That would be a HUGE mess."

     Is there any list of possible bugs we can have if we have windows 7/8 machine with VS2012 running under .net 4.0 and which will going to be break on when it runs on XP machine(i think also on w2k3 server) which only .net 4.0?

    If there is a list we might try to have care about it as there could be no benefit of not installing VS2012 if they are having plan to ship 4.5 under some windows update.


    Kamran Shahid Principle Engineer Development (MCP,MCAD,MCSD.NET,MCTS,MCPD.net[web])

    Friday, August 17, 2012 8:00 PM
  • I gather from reading earlier messages in this thread that MSFT is refusing to provide a list of 4.0 bugs fixed in 4.5.  That makes absolutely no sense.  Providing such a list would go a long way toward allowing devs to avoid running afoul of this issue.

    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, August 17, 2012 8:18 PM
  • I gather from reading earlier messages in this thread that MSFT is refusing to provide a list of 4.0 bugs fixed in 4.5.  That makes absolutely no sense.  Providing such a list would go a long way toward allowing devs to avoid running afoul of this issue.

    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    I can guess at a few reasons why they will not release the bug fix list.  The top one is that if there are fixes that impact security, then they have just made a map for exploiting .NET 4.0.

    Also, most companies don't want to advertise how crappy their code is, so they keep the bug lists internal.

    The fact that we NEED a bug list is a huge "smell" from the real problem:

        An In-Place Upgrade that drops supported Operating Systems.
        (Causing backwards incompatibility.)

    Friday, August 17, 2012 8:28 PM
  • The security thing makes sense, but surely not all of the bugs fixed in 4.5 revolve around security. IMHO there is no justification for not releasing a list of the non-security related issues.

    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, August 17, 2012 8:34 PM
    1. test on the single developer machine running .NET 4.5
    2. have the customers find the very small number of bugs caused by code that worked when running .NET 4.5 but which broke on .NET 4.0
    3. fix the bugs promptly and produce a new release

    our customers would not accept to be our QA staff in the production environment. It might be ok for sime kind of office tool. But if the production software has a minor bug, this usually means big losses.
    And being the reason for bog losses means usually loosing the customer.

    BTW. Using our customer for QA is not wat we want. The Gaming industry is doing it that way. This is one of the reasons why I do buy way less games.


    Saturday, August 18, 2012 9:13 AM
  • BTW, I'm not necessarily saying your customers need to upgrade right now. I'm saying that, if a bug costs 1 million Euros, then maybe your customers should be paying you more money for Windows XP support.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    It would be nice if it would be so easy. Our customers like to say 'we don't care' if we tell them something like this. 1st we loose this customer, the customer gets another supplier for less money, they run in similar trouble because of too low budget. They loose the customer, ...

    All we are ask for is: could MS please supply a bug fix package (of already fixed bugs) for an operating system which is officially supported for the next 2 years (Support for XP SP3 runs out in late 2014 as far as I know) and still used by a large number of customers.

    Saturday, August 18, 2012 9:21 AM
  • It would be nice if it would be so easy. Our customers like to say 'we don't care' if we tell them something like this. 1st we loose this customer, the customer gets another supplier for less money, they run in similar trouble because of too low budget. They loose the customer, ...

    Hmm... that's interesting... I think it could lead to the point where, sooner or later, that customer "forced" to accept the change and upgrade their system, as no one would (be able to) do what they requested anymore...

    Saturday, August 18, 2012 11:15 AM
  • With your kind of concern, you need to carefully see how you design the application, you can target the UI layer project with .NET 4.0,

    You actually don't have to worry about the bug fixes made on .NET 4.5 fixes, for example, there is some functionality not supported in the grid and you have used custom code, it shouldn't be a problem running in .NET 4.5 framework.

    If you build .NET 4.5 application and then target to .NET 4.0, then make sure the new features added like async API's, new properties supported etc...  you will not use, else it will be a problem, everything else supppose to work fine....

    There are not much major changes from 4.5 to 4 hence it should be compatible

    • Proposed as answer by kishhr Saturday, August 18, 2012 2:56 PM
    Saturday, August 18, 2012 2:56 PM
  • With your kind of concern, you need to carefully see how you design the application, you can target the UI layer project with .NET 4.0,

    You actually don't have to worry about the bug fixes made on .NET 4.5 fixes, for example, there is some functionality not supported in the grid and you have used custom code, it shouldn't be a problem running in .NET 4.5 framework.

    If you build .NET 4.5 application and then target to .NET 4.0, then make sure the new features added like async API's, new properties supported etc...  you will not use, else it will be a problem, everything else supppose to work fine....

    There are not much major changes from 4.5 to 4 hence it should be compatible

    Kishr, I think you may have missed the problem here.    We DO have to worry about the bug fixes made on 4.5, because some of those bug fixes are actually against 4.0 functionality.

    You are correct that we are not worried about the new 4.5 functionality - as they will not be used in applications targeting 4.0.

    Unfortunately, due to the 4.5 bug fixes changing some aspects of 4.0 functionality, an application built against 4.0 can behave differently between two machines, one with 4.5 installed and one without.

    This problem is then exacerbated because Microsoft has some platforms which .NET 4.0 supports that .NET 4.5 does not.  Microsoft has now made it impossible to get a consistent .NET 4.0 experience.






    • Edited by Cabadam Saturday, August 18, 2012 3:14 PM
    Saturday, August 18, 2012 3:12 PM
  • You actually don't have to worry about the bug fixes made on .NET 4.5 fixes...

    Really? I don't have to worry about, for example, framework bugs which are fixed in 4.5 but which crash the application in 4.0? That's nice, then. I can just let my customers worry about those instead.

    Monday, August 20, 2012 11:39 AM
  • Not a really big deal for those with MSDN subscriptions.  We should be testing our apps on all expected target OS's anyway, so the only additional cost to test on XP is the time and effort to spin up an XP VM for testing if we don't already have one.  Worst case scenario is that if the app actually crashes on XP, or Vista or 7 without 4.5, and we can't get remote debugging to work, we might have to actually install VS on the VM as well.  Again, only cost is time.  Of course, time is $$$.

    The best thing Microsoft can do is release a fix for 4.0 that applies the appropriate bug fixes.  It's universally stupid to NOT fix bugs on a platform that is still officially supported until late 2014.


    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Monday, August 20, 2012 11:58 AM
  • Not a really big deal for those with MSDN subscriptions.  We should be testing our apps on all expected target OS's anyway, so the only additional cost to test on XP is the time and effort to spin up an XP VM for testing if we don't already have one.  Worst case scenario is that if the app actually crashes on XP, or Vista or 7 without 4.5, and we can't get remote debugging to work, we might have to actually install VS on the VM as well.  Again, only cost is time.  Of course, time is $$$.

    As has been pointed out though, that's not quite the full story for the worst case scenario.  The true WCS is that you trip over one of those XP-only bugs while developing using your shiny new VS2012 installation on Windows 7, and the end result is is that you have to spend time and effort either working around it so that it doesn't crash on XP, or removing the feature.

    And I thought one of the advantages of using an abstraction framework like .NET is that you're not supposed to have to worry what the underlying OS is?


    Hey, let's all go back to this!:

    #IF WINNT THEN
    ...
    #ELSEIF WINXP THEN
    ' don't do that thing that has a memory leak on 4.0
    #ELSEIF WINVISTA THEN
    ' still don't do that thing that has a memory leak on 4.0
    #ELSEIF WIN7 THEN
    ' Wait, was it fixed here or just in Windows 8?
    ' And what's the major version number for Win8 anyway, is it still 6? Seriously?
    #ENDIF

    On second thought, I'll just go with avoiding VS2012/.NET45 and sticking with VS2010.
    • Edited by Quanta Monday, August 20, 2012 12:11 PM
    Monday, August 20, 2012 12:10 PM
  • My WCS where you have to install VS on the non-4.5 VM implies development time, so I think that WCS still applies.  It might be a PITA, but really, if you realistically expect your app to be used on XP, then you should test it on XP, or at least put a "Tested on..." statement in a prominent place in the documentation so that users on other untested OS's are made aware that they may find bugs.

    As I said above, I think it's very stupid for MSFT to introduce this problem to begin with.  Unless they fix it with an appropriate patch for machines that will never get 4.5, it's up to us .net developers to work around it.  When has it been any different?  We've always had to work around framework bugs.  The only way for us to deal with this is if we are aware of a 4.0 bug, and we can realistically expect our apps to run on 4.0 only machines, code defensively around it even on a 4.5 dev machine.


    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Monday, August 20, 2012 1:00 PM
  • As I said above, I think it's very stupid for MSFT to introduce this problem to begin with.  Unless they fix it with an appropriate patch for machines that will never get 4.5, it's up to us .net developers to work around it.  When has it been any different?  We've always had to work around framework bugs.

    It's been different because the key was always consistency.  If a bug existed in 2.0, it generally existed regardless of the OS - this is what the abstraction of the framework provided, be it good or bad.  Essentially the "Operating System" you were programming against was CLRv2.0.

    Of course testing is necessary for all OSes you want to support, but this could and should have been handled so much better with minimal effort from Microsoft.  As it stands it seems that they expended extra effort to produce this worst-case-scenario for all .NET developers.

    Monday, August 20, 2012 1:16 PM
  • Not a really big deal for those with MSDN subscriptions.  We should be testing our apps on all expected target OS's anyway, so the only additional cost to test on XP is the time and effort to spin up an XP VM for testing if we don't already have one.  Worst case scenario is that if the app actually crashes on XP, or Vista or 7 without 4.5, and we can't get remote debugging to work, we might have to actually install VS on the VM as well.  Again, only cost is time.  Of course, time is $$$.

    Unless all of your tests are fully automated, it costs a heck of a lot more than the OS and machine/VM it is running on.  UI testing in particular is very hard to fully automate, and when real-world resources are involved (in our case physical valves/pumps/etc) is completely impossible.  Further, the kind of bugs that the 4.5/4 issue will cause might only be found by exploratory testing, which is expensive enough just on one OS.

    Monday, August 20, 2012 3:59 PM
  • Not a really big deal for those with MSDN subscriptions.  We should be testing our apps on all expected target OS's anyway, so the only additional cost to test on XP is the time and effort to spin up an XP VM for testing if we don't already have one.  Worst case scenario is that if the app actually crashes on XP, or Vista or 7 without 4.5, and we can't get remote debugging to work, we might have to actually install VS on the VM as well.  Again, only cost is time.  Of course, time is $$$.

    Remember, these are all bugs that got by the huge QA System that Microsoft has in place.  Just adding some new VMs for testing is hardly going to be enough.  It will take a lot of manpower to find this stuff.  (Manpower = $$$)

    And just as Microsoft missed them, we will probably miss some of them too.  Especially if your app is complex.  (Bugs = $$$)


    • Edited by Vaccanoll Monday, August 20, 2012 4:14 PM
    Monday, August 20, 2012 4:14 PM
  • Thanks for bringing this up. We were going to install VS2012, but we've now put that on hold until we have a regression test plan in place for our entire app suite (WPF, C#, .Net 4.0). We found other issues with regards to  WPF, and I posted a bug in Connect, but it will probably get deleted since it's "not for reporting bugs" anymore.

    And to think we pay money for this kind of stuff...

    Monday, August 20, 2012 6:18 PM
  • I suspect our shop will silently protest this approach to .net 4/4.5 on XP and not build any Metro applications for the Microsoft Store, while we use those resources to blindly guess at the XP bugs that are not resolved.  Further more I can see this being a bug bear for developers and there opinion of Windows 8.

    My advise to customers will be similar to the $MS approach, telling customers there are issues with an MS Operating System and they will have to upgrade or face rising costs.  I suspect a shoot the messenger will occur after we advised our customers to use .net technology.

    Not publishing a complete list of bugs resolved (or not resolved in XP), kind of undoes all the "open source" efforts Microsoft has done in other area's of .net. One step forward 3 steps back Microsoft.


    Jamie Clayton http://www.jenasysdesign.com.au

    Monday, August 20, 2012 11:35 PM
  • I'm glad I came across this post.  Like many others in this thread, I work for a large enterprise with tight margins. 

    For us, XP is good enough.  Not great but good enough.  We don't want to spend money where we don't need to so we've waited until the end of support.  Until then, I need to support XP.  So, I guess I'll be using VS 2010 for a while longer.

    Is it that MS get most of their money from tech companies who are willing to put up with this crap?  Or do they just not understand their customers?  Have they never had to talk to a finance director about upgrades?

    IT: "We need a squillion to upgrade this."
    FD: "Why?" 
    IT: "Because Microsoft are dropping support." 
    FD: "You mean it works but we're throwing it away, anyway?"
    IT: "Well, er, viruses, malware..."
    FD: "So they sold us a product full of holes and now they refuse to plug them?"
    IT: "Well, er, ..."
    FD: "Why are we still doing business with them?"

    Please don't doubt that this is how conversations go; they really do.  We've lost so much capital (I don't mean money, I mean the leverage kind) that we've missed out on all sorts of new stuff because we've had to waste it justifying upgrades.

    • Proposed as answer by Tha Chad Wednesday, August 29, 2012 4:54 PM
    • Unproposed as answer by Tha Chad Wednesday, August 29, 2012 4:54 PM
    Friday, August 24, 2012 3:39 PM
  • Not mentioned so far: even Windows 7 desktops may not be able to get .NET 4.5.  I work for a large corporation (40,000+) on geocoding tools that are used in our offices worldwide.  The whole corporation is not in lock-step on its updates, which are strictly controlled.  In fact, it was only a few months ago that I was able to get approval to set .NET 4.0 as an acceptable prerequisite for my client tools running on corporate desktops.  It may be a year or more before .NET 4.5 gets that same approval (especially with the XP restriction).  So, for awhile, I'll need to target .NET 4.0 for client tier apps. No big deal... EXCEPT, because of this in-place upgrade issue, I also will not be able to develop the server tier components using .NET 4.5 without messing up my client tier apps.  I'll have to do -everything- for -all tiers- in VS2010 until this issue is addressed.  I could get approval to add .NET 4.5 to my servers immediately since it's not a deployment issue.  Unfortunately, there's no point to that now.

    Large companies are no better off than small ones.  Heck, most large companies are just a bunch of small companies stitched together.

    Wednesday, August 29, 2012 3:32 PM
  • The bottom line of all of this seems to be that .net developers will have to choose to target Windows 8 or XP. There does not seem to be a way to develop for both. Since so many of us 'have to' support customers using XP, Microsoft has shot themeselves in the foot as far as building developer support for their new OS.
    Wednesday, August 29, 2012 4:56 PM
  • For everyone that posted in this thread, please vote for this:

    http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3116039-support-xp-for-4-5-until-the-end-of-xp-support-

    I know they already declined a similar "Suggestion" but maybe it they see us insisting on having this support they might come back on their decision... i still have some hope :)


    • Edited by SlickRickD Wednesday, August 29, 2012 6:07 PM
    Wednesday, August 29, 2012 6:07 PM
  • For everyone that posted in this thread, please vote for this:

    http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3116039-support-xp-for-4-5-until-the-end-of-xp-support-

    I know they already declined a similar "Suggestion" but maybe it they see us insisting on having this support they might come back on their decision... i still have some hope :)


    Unfortunately, I'm not sure that is the "good" answer here.  There may well be features in 4.5 that, due to differences in the OS, cannot be implemented on Windows XP (I don't know what these might be - just theorizing).

    Based on the discussion here, I think the RIGHT answer is to either:

    1) Provide a patch for .NET 4.0 on XP to include the relevant changes to 4.0 functionality made in 4.5

    2) Make .NET 4.5 a side-by-side install instead of "upgrading" .NET 4.0.  I think THIS one is actually the right answer, but it may no longer be possible since .NET 4.5 is released (can they "undo" the upgrade and separate 4.5 into separate libraries?)

    Wednesday, August 29, 2012 6:11 PM
  • 1) Provide a patch for .NET 4.0 on XP to include the relevant changes to 4.0 functionality made in 4.5

    2) Make .NET 4.5 a side-by-side install instead of "upgrading" .NET 4.0.  I think THIS one is actually the right answer, but it may no longer be possible since .NET 4.5 is released (can they "undo" the upgrade and separate 4.5 into separate libraries?)

    2) is not an option because it's already been released.  It would've been the right choice in hindsight but we're well past that point now.  Unfortunately.

    Patching the bugs on 4.0 for XP would be the most sensible solution right now.  Everyone can and should accept a minor loss in functionality when running against an older O/S, and if this means that on XP you're targeting 4.0 but on 7+ you're targeting 4.5, then that's fine.  It's the fact that the framework, or rather one specific version of the framework, is different across different versions of Windows that really causes the problem.  It's no longer a framework, it's an OS dependent runtime add-on.

    And to think, a new release of the framework or (especially) a new version of VS used to have me downloading it from MSDN within minutes of its release.  With 2012, I'm not even bothered enough to check it out.

    Big fail, Microsoft.

    Wednesday, August 29, 2012 6:57 PM
  • Based on the discussion here, I think the RIGHT answer is to either:

    1) Provide a patch for .NET 4.0 on XP to include the relevant changes to 4.0 functionality made in 4.5

    Please vote for this: Support a .NET 4.0 Service Pack on Windows XP Supporting those .NET 4.0 Bugs Fixed in .NET 4.5
    Monday, September 03, 2012 6:18 AM
  • Please vote for this: Support a .NET 4.0 Service Pack on Windows XP Supporting those .NET 4.0 Bugs Fixed in .NET 4.5
    I agree!  Maybe if we get enough votes for this we can get to where we can use Visual Studio 2012.
    • Marked as answer by Vaccanoll Thursday, September 06, 2012 7:40 PM
    Tuesday, September 04, 2012 10:49 PM
  • For everyone that posted in this thread, please vote for this:

    http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3116039-support-xp-for-4-5-until-the-end-of-xp-support-


    +3 as far as I'm concerned.

    Jamie Clayton http://www.jenasysdesign.com.au

    Tuesday, September 04, 2012 11:49 PM
  • Have I accurately represented your interests? My questions and responses in this thread were meant to help me determine the "kernel" of the problem and to help me propose a solution.

    While I'm sure that my proposal doesn't solve all of the problems and pain expressed in this thread, I'm hoping that I've identified an action that Microsoft could actually take, which would minimize the pain and frustration of those involved. If I'm off the mark, then please comment in the uservoice article.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Wednesday, September 05, 2012 1:13 AM
  • Have I accurately represented your interests? My questions and responses in this thread were meant to help me determine the "kernel" of the problem and to help me propose a solution.

    While I'm sure that my proposal doesn't solve all of the problems and pain expressed in this thread, I'm hoping that I've identified an action that Microsoft could actually take, which would minimize the pain and frustration of those involved. If I'm off the mark, then please comment in the uservoice article.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Yes, I think that exactly captures the best option to move forward at this point.  I also agree that the other article (to outright support 4.5 on XP) is probably not a viable option.  We just want a consistent 4.0 experience across the platforms on which 4.0 is supported.
    Wednesday, September 05, 2012 1:16 AM
  • I'm glad I discovered this before our team upgraded, there is absolutely no way we can upgrade now, this should have been a .NET 5.0 release or at least give it a separate version number and allow is to target both.

    Until IT upgrade a number of legacy servers and client machines across the organisation it looks like we will still need to support .NET 4.0 bugs and all, which means no VS2012 for the foreseeable future.

    Seriously what the hell were they thinking, is there a justified developer reason for this or was it just a case of trying to force OS upgrades to make a bit more money...

    With the joke that is Windows 8 ME I'm seriously considering a change of scenery...

    Thursday, September 13, 2012 10:56 AM
  • With some of the impassioned discussion that has occurred in this thread, it's possible that you are overestimating the problem. Can you tell us precisely what problem you would expect to have if you were to upgrade to VS2012? The only problem that I've identified is that if your code had a dependency on a bug in .NET 4.0, you would not see that bug while debugging your application on a machine that had VS2012 installed. You would see that bug on QA machines which never had VS2012 (or .NET 4.5) installed.



    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Thursday, September 13, 2012 2:11 PM
  • I've only worked at one company that had "QA" machines, as you describe.  Startups and consultants would prefer that the framework be reliable in the first place.
    Thursday, September 13, 2012 2:15 PM
  • Are you unable to use virtual machines as QA machines? Do you have an MSDN subscription? The licenses for such machines would be covered under the subscription.

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Thursday, September 13, 2012 2:19 PM
  • Hi John, we will each find the workaround that suits us best.  I make money by writing code, not setting up additional test environments.  I'm disappointed at the senselessness by which VS2012 can give me a black eye.  If the QA you speak of failed at Microsoft (evidenced by their choosing this path), then we're all the more vulnerable, regardless of our own QA efforts.

    Thursday, September 13, 2012 2:42 PM
  • Are you unable to use virtual machines as QA machines? Do you have an MSDN subscription? The licenses for such machines would be covered under the subscription.

    John, you have got to be kidding right? In the businesses that do have QA environments, that's generally at the Server end of the software. QA testing in my corporate experience is done by the end users, sometimes even by Business Analysist, on what ever machine they have (read very minimal control into this statement!).

    In large business environments, the "standard" PC that's issued to you for the standard environment. So a developer may have MSDN, but the time available for a dev to find these bugs is very limited

    The access to MSDN subscriptions for testers is unheard of. It's not unusual to have a business with testing groups sitting internationally, where you have ZERO control of the end users environment. Jump out into the real world of business and you will find a very large difference between Microsoft "marketing" and the actual environments. Business are always in a state of flux IMHO, they don't just spend money because a supplier couldn't be bothered to fix there own mistakes. Why would they spend money because one .net application has known bugs, when the other 30 apps the user is using work just fine on there old XP machine sitting in the middle of a mine site 6 hours from the nearest IT person.

    I've worked with business that buy other business every 3 months and let me tell you they do not go out and give all the staff new PC's with the latest software when that happens! If anything, the money spent buying the business, stops them from upgrading the IT gear.

    It is perfectly acceptable for people to vent there frustration at Microsoft about this, because it makes the developers writting software look bad!


    Jamie Clayton http://www.jenasysdesign.com.au

    Friday, September 14, 2012 12:01 AM
  • But if QA is being done by BAs and end-users, then they're not running VS2012, and don't need to have .NET 4.5 installed. That's an even simpler situation. It's the equivalent of what I meant by talking about "QA": an environment that's still running .NET 4.0.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 1:07 AM
  • But if QA is being done by BAs and end-users, then they're not running VS2012, and don't need to have .NET 4.5 installed. That's an even simpler situation. It's the equivalent of what I meant by talking about "QA": an environment that's still running .NET 4.0.

    John,

    Point well made. If anything, control over service packs is relatively easy to manage with IT departments.

    So your recommending the solution for companies is not to push out 4.5 for Windows XP users only, but pushout 4.5 for Windows 7 users, so they get all the bug fixes, for applications that are .NET 4.0. Then handle the different application behaviours for users via the application reporting processes that are inplace to support the software we build.

    When the XP user run into problems, the developers to load VM's with XP and VS 2010 to debug those environmental issues, if a change is required to the application on that platform do it AND then retest on the Windows7/8 plateform with .net 4.5 installed to make sure it all works again. Sounds painfull enough.

    Great strategy to "encourage" XP migration or "discourage" VS2012/Windows 8 adoption.


    Jamie Clayton http://www.jenasysdesign.com.au

    Friday, September 14, 2012 1:56 AM
  • The people who pop in and keep stating some variation of "QA will catch it" are completely missing the point.  Even in environments with a completely 100% MS TFS compliant QA system with perfect unit tests and so forth, this is still a problem.  Why?  Because the developer will be unable to reproduce the error on her system.  Then the developer needs to go into VM land to reproduce the issue.  The issue will make absolutely no sense at first, seeming to just "not work" on XP for unexplained reasons.  After some time checking code, debugging on the VM, then she will google/bing about the issue.  If she is lucky, she will find this post.  Then she will finally know how to fix it. 

    This is all doable, yes.  BUT IT IS A WASTE OF TIME. Time is money!  Why is that so hard to understand?




    Friday, September 14, 2012 3:06 AM
  • The access to MSDN subscriptions for testers is unheard of. 

    I wouldn't go that far.  It's very heard of.  If an organization has a subscription to an MSDN sku that includes operating systems, anyone in that organization can spin up pretty much any Windows OS they want in a VM for purposes of testing.  I use VMWare Workstation, and I have base VM's of every windows OS my apps can run on.  I've activated and keep updated, 1 of each version of windows starting with XP Pro.  When I start working on a new project, I clone the VM I want to test with, and do all the testing in the clone.  If I do something to break the clone, I re-clone from the original.  It's not hard to do.  If a customer finds a bug, I clone a new one and try to duplicate the issue.  If I can't, I find out what the user has installed other than my software, or what IIS configuration they have that I don't, to try and mimic the conditions that created the bug.  The same workflow can be accomplished for free if you use Virtual PC or Hyper-V for the virtualiztion.

    I guess my point is, having an MSDN subscription means there's only one root reason why even a low-budget, single developer shop can't spin up VMs to do testing.  That root reason is because they don't want to take the time to do it.  Laziness.


    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, September 14, 2012 4:42 AM
  • That root reason is because they don't want to take the time to do it.  Laziness.

    Would that definition of Lazyness also apply to the Microsoft QA .net team?  Microsoft QA know all the issues with XP and don't publish them, or fix the bugs, while the people commenting in this forum are faced with the consequences of that decision.


    Jamie Clayton http://www.jenasysdesign.com.au

    Friday, September 14, 2012 6:33 AM
  • That root reason is because they don't want to take the time to do it.  Laziness.

    Would that definition of Lazyness also apply to the Microsoft QA .net team?  Microsoft QA know all the issues with XP and don't publish them, or fix the bugs, while the people commenting in this forum are faced with the consequences of that decision.


    Jamie Clayton http://www.jenasysdesign.com.au

    +1!

    @John Saunders: What exactly is difficult to understand here ? Microsoft has created a real mess on this subject and instead of them to go and fix it (even now, there are ways for Microsoft to do that) you suggest (as an MVP ) to us to...build VMs and start testing ? Start testing software that has been working for so many years flawessly and was ALREADY tested before shipping and now has to re-tested AGAIN just because a recompile through the new IDE ? Waste, waste , waste of time.....


    • Edited by King Kikapu Friday, September 14, 2012 7:52 AM
    Friday, September 14, 2012 7:51 AM
  • The people who pop in and keep stating some variation of "QA will catch it" are completely missing the point.  Even in environments with a completely 100% MS TFS compliant QA system with perfect unit tests and so forth, this is still a problem.  Why?  Because the developer will be unable to reproduce the error on her system.  Then the developer needs to go into VM land to reproduce the issue.  The issue will make absolutely no sense at first, seeming to just "not work" on XP for unexplained reasons.  After some time checking code, debugging on the VM, then she will google/bing about the issue.  If she is lucky, she will find this post.  Then she will finally know how to fix it. 

    This is all doable, yes.  BUT IT IS A WASTE OF TIME. Time is money!  Why is that so hard to understand?

    It may be slightly worse than that.  From what I understand, remote debugging cannot be performed from VS2012 to an XP machine so the either the dev environment would need to be set up on the XP instance (at which point your testing VM may start to drift away from an accurate representation of a production XP install) or you have to guess what the problem is.

    There's a real comedy of errors here that make it increasingly harder to reliably state that your software is compatible with XP.  Whether this is a cynical marketing move or not is known only to Microsoft, but it's certainly one of the reasons we're holding off on upgrading to VS2012 at my organisation.

    Other than Async there's not really much in the latest release that's making me wish I could use the latest and greatest release.

    Friday, September 14, 2012 12:05 PM
  • Start testing software that has been working for so many years flawessly and was ALREADY tested before shipping and now has to re-tested AGAIN just because a recompile through the new IDE ? Waste, waste , waste of time.....
    In fairness, that isn't really the case here.  We're talking about bugs that always existed in .NET 4.0 that are fixed in the 4.5 release.  Basically if your software fell victim to the 4.0 bug originally, it still will on XP.  The problem is, if you've upgraded to VS2012 and the bug in question was one of those fixed in 4.5, then you won't be able to reproduce the issue.
    Friday, September 14, 2012 12:25 PM
  • Start testing software that has been working for so many years flawessly and was ALREADY tested before shipping and now has to re-tested AGAIN just because a recompile through the new IDE ? Waste, waste , waste of time.....

    In fairness, that isn't really the case here.  We're talking about bugs that always existed in .NET 4.0 that are fixed in the 4.5 release.  Basically if your software fell victim to the 4.0 bug originally, it still will on XP.  The problem is, if you've upgraded to VS2012 and the bug in question was one of those fixed in 4.5, then you won't be able to reproduce the issue.

    Agreed, wrongly formulated (now that i see my post again).

    As like you, i want to upgrade to VS 2012 not because .net 4.5 (i will continue to work with 4.0 as i have a lot of XP machines here) but because of C++ and the enhancements of the new compiler and new Library bring. But it seems that i cannot do this for the time beeing...

    Friday, September 14, 2012 1:03 PM
  • Would that definition of Lazyness also apply to the Microsoft QA .net team?

    Possibly, it depends on whether or not this happened because they failed to test or if it was a deliberate business decision.  If I was a deliberate business decision, then it is not the fault of the QA testers.

    My point is that even with old long running apps, one should do thorough regression testing anytime there is a change.  Laziness, or questionable business decisions on the part of Microsoft doesn't no absolve one of that responsibility.  Having an MSDN subscription (which I have been keeping active back since the Visual Studio 5 days with the old MSDN Universal, and I'm just a single hobbiest developer) makes it easy to test on pretty much any version of Windows imaginable.  The only extra cost is time and effort.  


    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, September 14, 2012 1:08 PM
  • Jamie Clayton http://www.jenasysdesign.com.au

    +1!

    @John Saunders: What exactly is difficult to understand here ? Microsoft has created a real mess on this subject and instead of them to go and fix it (even now, there are ways for Microsoft to do that) you suggest (as an MVP ) to us to...build VMs and start testing ?

    I have no difficulty understanding. It's just that I think it's very unlikely that Microsoft will support .NET 4.5 on Windows XP - ever. The question is what is the impact of that?

    The only impact I see is that there may be some bugs that occur on .NET 4.0 running on Windows XP that will not occur with .NET 4.0 on a developer workstation. To be honest, I don't understand why you wouldn't already be doing your tests on Windows XP, simply because that's what your users are using.

    It seems to me that we're talking about a small number of bugs, and a small inconvenience in terms of reproducing that small number of bugs.

    Further, there's a good lesson here: if you have users who depend on your software running on obsolete operating system versions, then you need to take steps to ensure that you can continue to support those users. You should not expect to get this for free. There's a cost associated with continuing to use decade-old software.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 2:05 PM
  • Are you saying that installation of VS2012 will prevent you from using VS2010 to remote debug on XP?

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 2:06 PM
  • <<That root reason is because they don't want to take the time to do it.  Laziness.>>

    @k4gdw, I should click "Propose as Answer" on your response.  It's not budgets, resources, deadlines, or caring about the quality of your framework that has us all here, its just that we don't work hard enough.  I'm convinced!  </sarcasm>  :-)

    Friday, September 14, 2012 2:07 PM
  • ...

    When the XP user run into problems, the developers to load VM's with XP and VS 2010 to debug those environmental issues, if a change is required to the application on that platform do it AND then retest on the Windows7/8 plateform with .net 4.5 installed to make sure it all works again. Sounds painfull enough.

    ...


    Jamie Clayton http://www.jenasysdesign.com.au


    Actually, I'm saying that when an XP user runs into problems, you should try to use your VS2012 machine to reproduce the problem. Most of the problems with your software will continue to be independant of the operating system. Only when you can't reproduce the problem on a .NET 4.5 system would you need to spin up your XP VM.

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 2:10 PM
  • Further, there's a good lesson here: if you have users who depend on your software running on obsolete operating system versions, then you need to take steps to ensure that you can continue to support those users. You should not expect to get this for free. There's a cost associated with continuing to use decade-old software.

    http://www.microsoft.com/en-us/windows/endofsupport.aspx

    XP is still supported by Microsoft until 2014 - I would not classify that as obsolete.

    Friday, September 14, 2012 2:49 PM
  • Jamie Clayton http://www.jenasysdesign.com.au

    +1!

    @John Saunders: What exactly is difficult to understand here ? Microsoft has created a real mess on this subject and instead of them to go and fix it (even now, there are ways for Microsoft to do that) you suggest (as an MVP ) to us to...build VMs and start testing ?

    I have no difficulty understanding. It's just that I think it's very unlikely that Microsoft will support .NET 4.5 on Windows XP - ever. The question is what is the impact of that?

    The only impact I see is that there may be some bugs that occur on .NET 4.0 running on Windows XP that will not occur with .NET 4.0 on a developer workstation. To be honest, I don't understand why you wouldn't already be doing your tests on Windows XP, simply because that's what your users are using.

    It seems to me that we're talking about a small number of bugs, and a small inconvenience in terms of reproducing that small number of bugs.

    Further, there's a good lesson here: if you have users who depend on your software running on obsolete operating system versions, then you need to take steps to ensure that you can continue to support those users. You should not expect to get this for free. There's a cost associated with continuing to use decade-old software.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Microsoft will not release 4.5 on XP, i agree with that and technically i am sure that there are reasons for this. l really do.

    But i am also sure that there cannot be a set of dlls on dev machine that is different from the one on user machine for the same version of the framework (4.0). This is totally wrong and with the scenario we are discussing here, unfortunately is possible.

    As for the "wouldn't already be doing your tests on Windows XP, simply because that's what your users are using." argument:  .NET is an abstraction and when you programming *against* that abstraction, you shouldn't have to worry about extra testing for different OSes, at least, not so much as we are forced to do in this scenario. 11 years of .NET programming and i didn't need to have to setup a VM to do extra testing, why i have to do it now ??

    Anyway, because there already reported cases where these bugs exist and are causing problems, i think that it would help if Microsoft release a list with the bugs fixed on 4.5 that still exist on 4.0 so we know what are we dealing with.

    Friday, September 14, 2012 2:50 PM
  • Further, there's a good lesson here: if you have users who depend on your software running on obsolete operating system versions, then you need to take steps to ensure that you can continue to support those users. You should not expect to get this for free. There's a cost associated with continuing to use decade-old software.

    http://www.microsoft.com/en-us/windows/endofsupport.aspx

    XP is still supported by Microsoft until 2014 - I would not classify that as obsolete.


    XP is in extended support until 2014. THat's not the same as "support".

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 3:02 PM
  • I agree that there should be a list of bugs. Even with such a list, there may still be bugs you find that are unique to the XP system.

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 3:03 PM
  • Are you saying that installation of VS2012 will prevent you from using VS2010 to remote debug on XP?

    John Saunders

    That is an excellent question.  Has anyone tried this? 

    To rephrase it:

    If you have .NET 4.5 on your dev machine.  And you are remote debugging to a machine that has only .NET 4.0.  What happens when you hit a .NET 4.0 bug? 

    @k4gdw - I would love to try it out, but I am too "Lazy" to setup the VMs to do it.  Or no, wait.  I have a boss, and a Job, and deadlines and don't have the time or hardware to setup a whole farm of VMs to test inconsistencies in the .NET framework.

    Friday, September 14, 2012 3:04 PM
  • Further, there's a good lesson here: if you have users who depend on your software running on obsolete operating system versions, then you need to take steps to ensure that you can continue to support those users. You should not expect to get this for free. There's a cost associated with continuing to use decade-old software.

    http://www.microsoft.com/en-us/windows/endofsupport.aspx

    XP is still supported by Microsoft until 2014 - I would not classify that as obsolete.

    See http://support.microsoft.com/lifecycle/?p1=3223:

    Products Released Lifecycle Start Date Mainstream Support End Date Extended Support End Date Service Pack Support End Date Notes
    Windows XP Professional 12/31/2001 4/14/2009 4/8/2014 8/30/2005 Buy Windows 7 now!

    4/8/2014 is the end of Extended support.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 4:28 PM
  • How long do you think it takes to set up a VM? It's like setting up a normal machine - you do real work while you wait for Windows to install. You again do real work while waiting for Windows Update to finish. It's not a big chore.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 4:31 PM
  • If you have .NET 4.5 on your dev machine.  And you are remote debugging to a machine that has only .NET 4.0.  What happens when you hit a .NET 4.0 bug?

    What do you think what would happen?
    Yes, I become curious about what would actually happen after someone actually has experienced it. Is there any real evidence of failure or is this a hypothetical discussion about "what if" and/or "what would"? Just another FUD.

    Friday, September 14, 2012 4:34 PM
  • @John Saunders -

    I guess it depends on what "Obsolete" means.  Or more importantly, who gets to decide it.

    Mainstream support ended 4/14/2009.  But Dell was still selling brand new laptops with XP loaded on them up until October 22, 2010 (over a year after mainstream support ended).  And they only stopped then because Microsoft MADE them.  So, people were buying NEW computers with XP on them less than 2 years ago. 

    So, if Microsoft decided to declare Windows 8 "Obsolete" tomorrow, and end support for it, does that make it so? 

    Or does it become obsolete when people stop using it?

    Or you could argue that it becomes obsolete then the features it supports are no longer at Market Level.  (Though that is in the eye of the beholder as to what features are important to the "market".)

    I truly don't know.  And frankly don't care.  I don't like XP.  I am not defending it.  I really like Windows 7 and wish I could develop for only it.  But alas, I have no choice.


    • Edited by Vaccanoll Friday, September 14, 2012 4:45 PM
    Friday, September 14, 2012 4:41 PM
  • @John, haven't you heard?  We already understand that it's our fault for being too lazy.  I think the issue is closed.
    Friday, September 14, 2012 4:50 PM
  • I have not called you lazy.

    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 5:01 PM
  • "Obsolete" is certainly a relative term. The meaning depends on the outcome of depending on "obsolete" software.

    If there is no cost at all to using obsolete software, then it just doesn't matter.

    If using obsolete software means that some people die and others go to prison, then it matters a great deal.

    Personally, I typically recommend against using software in production when the vendor is no longer fixing general bugs. That would rule out using XP, as Microsoft are only providing security fixes and paid support.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects


    • Edited by John Saunders Friday, September 14, 2012 7:42 PM Make it clear I'm not inventing standards
    Friday, September 14, 2012 5:05 PM
  • Personally, I would argue against using software in production when the vendor is no longer fixing general bugs. That would rule out using XP, as Microsoft are only providing security fixes and paid support.

    Not to split hairs, but "Support" and "General Support" may be different in your eyes, however that view will not necessarily be shared by customers.  In reality, your view of whether XP is obsolete is totally irrelevant - it's whether or not our users, their IT departments, etc determine it to be obsolete.  For many, knowing that XP has support of *any* kind up until 2014 is reason enough to delay an upgrade, especially when combined with cost.

    If Mainstream support is supposedly a good measure of obsolescence, then according to that support calendar you posted above it shows that XP's mainstream support ended in 2009.  How come VS2010 and .NET 4.0 were still supported on XP in that case?

    Friday, September 14, 2012 5:58 PM
  • Personally, I would argue against using software in production when the vendor is no longer fixing general bugs. That would rule out using XP, as Microsoft are only providing security fixes and paid support.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    You can argue that all you want.  That doesn't change all of our customers' minds or make them go out overnight and replace all of their XP/Server 2003 systems.
    Friday, September 14, 2012 6:01 PM
  • I apologize for not being clear. I have updated my reply to clarify that I am not attempting to invent standards. I meant that I typically recommend against using software in production when it is no longer fully supported by the vendor or developer.

    I did not mean to define how your customers should decide on upgrades.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 7:43 PM
  • @k4gdw, I should click "Propose as Answer" on your response.  It's not budgets, resources, deadlines, or caring about the quality of your framework that has us all here, its just that we don't work hard enough.  I'm convinced!  </sarcasm>  :-)

    In my private time I code for fun.  However, that's also my 9-5, bread and butter job as well.  One of the major line items on my official job description is, "Thoroughly tests all code changes before deploying to production."  That includes changes to our code, as well as OS updates that might affect our code, such as .Net Framework updates and service packs.

    Thorough testing is something that any developer, be they a hobbiest or professional developer that is part of a large development organization who cares about budgets, resources, deadlines, and the quality of their product should do.  The later in the process a bug is found, the more expensive it is to fix.  If I can find a bug before the product ever gets to QA testing, I've just saved my employer $$$.  If it's in my own person project, where I am system architect,developer, QA tester, and end user support, I still start testing on the minimum target OS as soon as the app is complete enough to actually run outside of the VS debugger.

    Some of the folks on this thread seem to be actually offended at the idea that maybe they should test to make sure their code doesn't break when MSFT makes a change to the framework.  Failing to test, will eventually come back to bite you.  When it does, it'll cost even more $$$, time, and effort that simply testing up front would have.


    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, September 14, 2012 9:01 PM
  • Of course developers may test. But we're not professional testers. We're going to miss things. In my experience, many of the bugs reported by users are bugs that would have been caught by professional testers using professional test tools.

    But whoever the tester is, they should test the code in the environment it will be running in. In this case, that means on a machine running XP.

    Clearly, that machine should not have .NET 4.5 installed on it.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 9:22 PM
  • @k4gdw - I would love to try it out, but I am too "Lazy" to setup the VMs to do it.  Or no, wait.  I have a boss, and a Job, and deadlines and don't have the time or hardware to setup a whole farm of VMs to test inconsistencies in the .NET framework.

    I also have a boss and his face turns red and a vein on his left temple throbs if a user of one of the apps I'm responsible for calls the help desk about something that I could have found had I not forgotten to test after a big batch of updates from MSFT or especially a new framework version/service pack hits Windows Update.

    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, September 14, 2012 9:26 PM
  • Hey, if you, as a developer, can do as good a job of regression testing as QA professionals I've worked with, then, congratulations! Most developers are not good testers.

    In fact, I've been in the industry over 35 years and have never met a developer I would trust to completely test an application of any complexity; at least, not if the application is important.


    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects

    Friday, September 14, 2012 9:39 PM
  • I never said I was as good as a trained and experienced QA professional.  I merely contend that it is good practice for a dev to test and try to catch problems before they ever get to QA.  A problem that is caught by the developer will be much cheaper to fix than one caught by QA, which in turn will be cheaper by one caught by the end user.  Also, developer testing isn't nearly the horrible oppressive burden some of the folks on this thread seem to think it is.

    Everywhere I've ever worked the QA folks were very attuned to details.  The dev team has always been responsible for the first line of functional testing and if they did their job correctly, the QA team virtually flies through the functional tests and then dig into the minute details of spit and polish, obsessing about things like misspelled words in dialog title bars, smooth gradients, and whether or not the company logo within some acceptable range of the correct shade of blue.  Likewise, in the maintenance phase, the dev team does functional regression testing first.


    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Friday, September 14, 2012 10:38 PM
  • I think this thread is going down a rat hole.  Testing should not be undervalued, and that will uncover many or most issues depending on the amount of resources you have.  It seldom catches them all.  The original intent of this thread is that there was an egregious error in judgement by Microsoft that can still be corrected or at least mitigated in one or more ways, and we feel Microsoft is obligated do something about it before we commit to adopting VS2012.

    Monday, September 17, 2012 2:31 PM