Coffeehouse Thread

18 posts

.NET 4.5 clarification

Back to Forum: Coffeehouse
  • User profile image
    vesuvius

    .NET 4.5 is an in place upgrade of .NET 4.0 (Visual Studio 2010). This means that when you install it, it removes .NET 4.0 replacing it with .NET 4.5. This is a departure from previous versions where .NET has been incremental.

    I am finding people getting themselves into all sorts of trouble, including running Visual Studio 2012 and Visual Studio 2010 on the same box, or installing exchange 2010 on a server with .NET 4.5 and applications stop working. I don't think a lot of people are aware about this yet, are you?

    I know that MSDN says this is supported, if so, how does this work where you have a version that removes the previous version and expect the previous software to work (i.e. .NET 4 WPF applications for example)?

    For now, I do not recommend Dev 10 and Dev 11 on the same box, and running .NET 4 applications on a server with .NET 4.5 is asking for problems.

    Can sombody shed some light on this, and can you start sending out correct information, as I think a lot of people are finding the upgrade process confusing or destabilising, where clarification on how to approach upgrades and what can or can't be done would negate this issue?

  • User profile image
    figuerres

    this does not sound good.....

  • User profile image
    AndyC

    @figuerres: It's no different to the situation when .NET 3.0 came out.

  • User profile image
    vesuvius

    , AndyC wrote

    @figuerres: It's no different to the situation when .NET 3.0 came out.

    No different in the confusion? I think there is a subtle nuance that you have missed. When .NET 3.0 came out you could run side by side installations (I have Visual Studio 2005, 2008 and 2010 on the same box). In my add remove programs I have .NET 2.0, 3.0, 3.5 and .NET 4.0. There is no confusion.

    I am not looking for a flame-war or anything, just clarification so 9ers and I can start to tell our sys admins and other developers what they need to do. I have .NET 4 applications that went berserk when I installed Dev 11 on a machine with Dev 10

     

  • User profile image
    AndyC

    @vesuvius: Installing .NET 3.0 "fixed" certain bugs in .NET 2.0. It might have looked like they were both installed and entirely isolated, but that was never the case. If your app was dependent on one of those bugs/behaviours then you'd have seen the same problem you do now (though possibly it'd be harder to diagnose because they looked unrelated).

  • User profile image
    vesuvius

    , AndyC wrote

    @vesuvius: Installing .NET 3.0 "fixed" certain bugs in .NET 2.0. It might have looked like they were both installed and entirely isolated, but that was never the case. If your app was dependent on one of those bugs/behaviours then you'd have seen the same problem you do now (though possibly it'd be harder to diagnose because they looked unrelated).

    .NET 4.0 is a standalone version, requiring no prior .NET versions (they have release service packs for .NET)


    If I install .NET 4.5 on a machine with .NET 4.0 (A WPF app for example), will this work? I am also looking to install Exchange 2010 on Windows Server 2012 and it plain does not work. This is not just about bug fixes, the problem is far bigger than your care or want to admit, and your usual ploy of discrediting something you disagree with - reminds me of a certain "Humphrey Appleby" , I can read through it like a warm knife through butter. - not only is it tiresome, it is predictable. It's a recurrent theme in how you deal with disagreement.

     

  • User profile image
    DeathBy​VisualStudio

    , vesuvius wrote

    *snip*

    This is not just about bug fixes, the problem is far bigger than your care or want to admit, and your usual ploy of discrediting something you disagree with - reminds me of a certain "Humphrey Appleby" , I can read through it like a warm knife through butter. - not only is it tiresome, it is predictable. It's a recurrent theme in how you deal with disagreement.

     

    +1000

  • User profile image
    blowdart

    , vesuvius wrote

    I am also looking to install Exchange 2010 on Windows Server 2012 and it plain does not work.

    That however is not, AFAIK a .NET issue, and adding it to back up your argument is disingenuous. Exchange checks the OS version and won't install on Win8 or 2012 because of that.

    Anyway Exchange 2010 uses .NET 3.5 and you can quite happily install that on 2012 via the usual Add Roles and Features route.

     

  • User profile image
    AndyC

    @vesuvius: The relationship between .NET 4.5 and .NET 4.0 is the same as that between .NET 3.0 and .NET 2.0. In both cases installing the "newer" version can break applications which have dependencies on behaviours (bugs/features take your pick of name) which change between the two.

    If Exchange 2010 breaks solely due to .NET4.5 (and not due to one of the myriad of other changes on Server 2012), then it clearly has a dependence somewhere on something that changed between the two. That doesn't necessarily equate to the fact that every .NET4.0 app will break similarly any more than if Exchange did work with 4.5 it would guarantee everything else would too.

    Any time you apply any kind of update to a system, no matter how minor it seems, there is a potential for things to break. This is why sysadmins spend their life saying "no, we can't just apply that hotfix to every box" to developers, because they're only too aware of how often "unrelated" changes break stuff.

    I'm not sure where you get the idea I'm attempting to discredit the idea it breaks, if anything it's exactly the opposite. Every change is a potential breakage. And it doesn't matter what that change is. Different OS? New patch installed? Changed some "totally harmless" registry entry? All represent a potential for breakages. It amazes me how many developers still think that because they compiled against .NET X.x, they can avoid testing on every version of Windows they support running on, with every viable combination of patching (within a reasonable degree, i.e. every OS SP and every runtime SP + whatever amount to "up to date" at the time of testing)

  • User profile image
    vesuvius

    , blowdart wrote

    *snip*

    That however is not, AFAIK a .NET issue, and adding it to back up your argument is disingenuous. Exchange checks the OS version and won't install on Win8 or 2012 because of that.

    Anyway Exchange 2010 uses .NET 3.5 and you can quite happily install that on 2012 via the usual Add Roles and Features route.

     

    I did genuinely post a link above with the words sys admins and target this specific post;

    Hi,

    Digging up it only for information. I had a similar problem but found a solution.
    The problem is that the WS12 in default use .NET 4.5 and Exchange 2010 need .NET 3.5. Second problem is that you cant install .NET 3.5 on .NET 4.5.

    Short scheme what you need to do to fix this:
    - Remove .NET 4.5 (it remove GUI and PS3)
    - Via dism install .NET 3
    - Install .NET 4 and GUI

    And next when you see you have both .NET 3.5 and 4.5, you can normally install exchange 2010.

     

  • User profile image
    blowdart

    , vesuvius wrote

    *snip*

    I did genuinely post a link above with the words sys admins and target this specific post;

    Hi,

    Digging up it only for information. I had a similar problem but found a solution.
    The problem is that the WS12 in default use .NET 4.5 and Exchange 2010 need .NET 3.5. Second problem is that you cant install .NET 3.5 on .NET 4.5.

    Short scheme what you need to do to fix this:
    - Remove .NET 4.5 (it remove GUI and PS3)
    - Via dism install .NET 3
    - Install .NET 4 and GUI

    And next when you see you have both .NET 3.5 and 4.5, you can normally install exchange 2010.

     

    That (community) answer makes no sense to be honest.

    Second problem is that you cant install .NET 3.5 on .NET 4.5.

    is untrue. You most certainly can. Mind you it takes an entire whitepaper to list the options, but DSIM is the ugliest option.

    1. In Server Manager, click Manage, then select Add Roles and Features to launch the Add Roles and Features Wizard.
    2. Click Next at the Before you begin screen.
    3. At the Select installation type screen, select Role-based or feature-based installation and click Next.
    4. On the Select destination server screen, select the target server and click Next.
    5. On the Select server roles screen, click Next.
    6. On the Select features screen, check the box next to .Net Framework 3.5 Features and click Next.
    7. On the Confirm installation selections screen, a warning will be displayed asking "Do you need to specify an alternate source path?...". If the target machine does not have access to Windows Update, click the Specify an alternate source path link to specify the path to the \sources\sxs folder on the installation media and click OK. After you have specified the alternate source, or if the target machine has access to Windows Update, click the X next to the warning, and then click Install.

    Or, if you don't like a GUI there's always powershell; Install-WindowsFeature NET-Framework-Core -Source D:\sources\sxs

    Of course then you have to remove the OS check from the Exchange installer ...

  • User profile image
    bondsbw

    Obfuscated code working under .NET 4.0 may break when .NET 4.5 is installed.

    In my particular case, I built a DLL under .NET 4.0 and obfuscated it with .NET Reactor.  The DLL failed on any machine where .NET 4.5 was installed, Windows XP or 7 or 8, even though the entry assembly that loads it targets .NET 4.0.  The MDA error was "PInvokeStackImbalance was detected".

    The fix was to run .NET Reactor on the unobfuscated assembly and change obfuscation settings until it worked.

    (This may not be very related to your issue, but perhaps it will help someone who reads through this post looking for answers.)

  • User profile image
    felix9

    that TechNet forum post has nothing about .NET 4.5 compatiblity issues in it, and contains misleading information in its own.

    There is basically 2 problems for Exchange 2010 on Server 2012 in that post.

    1, it depends on .NET 3.5
    Then someone posted a misleading instruction of installing .NET 3.5.
    you can just install it without touchingt .NET 4.5 at all. Another reply confirmed this later.
    So the only place .NET 4.5 mentioned in this post is wrong information.

    2, it requires some roles/features to be installed, this has nothing to do with .NET 4.5 either.

  • User profile image
    felix9

    , bondsbw wrote

    The DLL failed on any machine where .NET 4.5 was installed, Windows XP or 7 or 8

    .NET 4.5 on XP ???

     

  • User profile image
    vesuvius

    @blowdart: Have emailed thread to Admin.

     

    Ta.

     

  • User profile image
    blowdart

    , vesuvius wrote

    @blowdart: Have emailed thread to Admin.

     

    Ta.

     

    You'd be better off waiting for the next exchange sp though for official support. What I listed is a fudge Smiley

     

  • User profile image
    varungupta

    @vesuvius: We test tons of .NET apps in house to validate compatibility of .NET4.0 apps on .NET4.5 (among other ways to validate compatibility). We would like to take a look at failures that you are seeing. Could you contact us at netfx45compat at Microsoft dot com with specific issue report (s)? Thanks, Varun Gupta (.NET Compatibility Program Manager)

     

  • User profile image
    varungupta

    @bondsbw: We test tons of .NET apps in house to validate compatibility of .NET4.0 apps on .NET4.5 (among other ways to validate compatibility). We would like to take a look at failures that you are seeing. Could you contact us at netfx45compat at Microsoft dot com with specific issue report (s)? Thanks, Varun Gupta (.NET Compatibility Program Manager)

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.