Should we put apphack in .Net 2.0?


AppHack is a terminology used in AppCompat. Basically AppCompat detects a specific application, and applies an AppHack if necessary.

One typical AppHack is to lie about the OS version number, due to applications use the wrong logic to check the minimum OS requirement.

I only have Whidbey Beta 1 in my home machine. I need it to write samples for my blog. I don’t need .Net 1.1 to run .Net 1.1 applications, because if mscoree.dll can’t find .Net 1.1 on my machine, it will automatically use Whidbey. (So which CLR will my app use? )

Well, only if I can install the application.

RssBandit is a popular RSS reader written by Dare Obasanjo & Co. And that is what I am using for reading blogs.

Dare is nice enough to provide a MSI package for RssBandit.

The problem is, the RssBandit MSI package checks for .Net 1.1, and refuses to install when it does not find .Net 1.1, even though I have Whidbey beta 1 installed and RssBandit should run happily under Whidbey Beta 1.

Do we need a version AppHack for RssBandit?

Comments (21)

  1. "even though I have Whidbey beta 1 installed and RssBandit should run happily under Whidbey Beta 1."

    Should does not mean will. Whidbey Beta 1 wreaks havok on XHEO licensing and the Office style toolbar control that I use.

    Since .NET was designed for side by side, I think the solution is to have all existing versions of the FX installed with Windows.

    It’s not like hard disk space is an issue these days.

  2. John says:

    I’m not sure appHack in .Net would really help out here; isn’t this due to an Windows Installer check for either a registry key or file version? It seems that to get around windows installer issues, if 2.0 is the only version of the framework on the machine, you’re going to have to lie about the presence of older versions. But that seems to be an issue for Installer, not Whidbey.

  3. Josh,

    Did you report the break in product feedback (http://lab.msdn.microsoft.com/productfeedback/default.aspx)? We are supposed to have very good compatibility in Whidbey. Any app compat issue should be looked at.

    Not that I don’t want to install .Net 1.1. I want to test the compatility of Whidbey on 1.1 applications.

    John,

    The application should say a minimum version, instead of the specific version. Say if the app says requiring 1.1+, and installer finds 2.0, then it will install.

    I do agree with you that AppHack won’t work for installer. But I am using this concept as a general comment.

  4. Considering that RSS Bandit just uses the installer project feature that comes with Visual Studio.NET I’d say that’s where the problem lies not with RSS Bandit specifically.

  5. Raymond Chen says:

    AppHacks completely miss the point of the CLR running side-by-side. If an app wants .Net 1.1 then go install .Net 1.1. (Actually the app should have included a copy of 1.1 on its CD to cover for this eventuality.)

    The app was never tested with 2.0. Who knows what breaking change will cause the app to fail unexpectedly.

  6. Jeffrey van Gogh says:

    As Dare says, the problem probably occurs because of the VS installer framework launch condition. I’d use the WiX decompiler + compiler to open the .msi and rip the installer’s framework check…

  7. Imagine an application refuses to install on longhorn because it requires .Net 1.1, and there is only .Net 2.0 on the box.

    I know it is not RssBandit’s fault. But something has to be done here. You really should check for minimum CLR version, not the exact CLR version.

  8. Why not just open the MSI in Orca (part of the .NET Framework SDK) and change the LaunchCondition? As someone else mentioned, though, you should report it so that RssBandit can fix the problem.

    If you don’t want to change the actual MSI, you could create a transform and run msiexec.exe to apply the transform while installing the MSI.

  9. Heath,

    What problem am I supposed to fix exactly? That RSS Bandit doesn’t support some internal build of a yet to be released version of the .NET Framework?

    That doesn’t sound like MY problem to me. Once Whidbey is an official release then maybe it’ll be a problem if RSS Bandit doesn’t install on it but even then I’d suspect the problem would still be in the installer project feature of Visual Studio.NET 2003.

  10. This is not RssBandit’s problem. It is a problem in the VS setup project system. You cannot say a minimum CLR version in the setup project.

  11. The side effect of this is, maybe in longhorn, we do need an AppHack for MSI packages requiring .Net 1.0/1.1.

  12. Eric Newton says:

    NEVER NEVER NEVER do AppHacks with .NET! Man, why am I one of the few people who are saying SIDE-BY-SIDE is version specific FOR A REASON.

    I’m in contention with one of the guys updating the AsymmetricAlgorithm asking if he should break compatibility to make it RIGHT. Long story short, he doesnt want to BREAK COMPATIBILITY for the new version, because older apps will break…! OMG, this is THE WHOLE REASON for SIDE-BY-SIDE.

    PLEASE NEVER make any APPHACKS for .NET APPLICATIONS. NEVER NEVER NEVER

  13. Ovidiu says:

    No, no, no, no, no. And, in case you didn’t get it: NO! You have one great chance of leaving behind all dirty hacks from previous versions of Windows. Introducing these "tweaks" again would ruin the whole thing. There are better ways to handle this (in this particular case fixing the MSI generated by Visual Studio).

    Off-topic, it seems ironic to me that even considering the great improvements the CLR and .NET Framework have brought, people still write code as they did on their good ol’ VB/VC++. Education is the key, and maybe it’s also the right time for Microsoft to force developers into writing better code. If people don’t start writing better code, Microsoft will be sentenced to fixing broken apps with AppHacks in the OS forever…

  14. Ovidiu says:

    And btw, does anyone remind one tiny design guideline that says that lower-level software layers should be unaware and ignorant above the high-level packages that call into them? This is an obvious violation of that principle, and one that has been employed at Microsoft for years. Please drop it.

  15. I did not say what the potential fix is. The problem is the MSI package says it depends on .Net 1.1, and don’t want other CLR version. On a machine with only CLR 2.0 (say longhorn), this application will fail to install. If MSI has a logic to satisfy CLR 1.1 with CLR 2.0, then the application will install. The potential fix is in MSI.

    Fixing the MSI may be an acceptable workaround for you and me, but it is definitely not an acceptable workaround for the general computer users.

    Of course, I did not say we will introduce this AppHack in MSI. I am not the person to make this decision. But like I pointed out, this is a problem. Whether you want to solve it or not, how you solve it, is up to the right people.

  16. Ovidiu says:

    I’m not sure if you know about the NULL pointer issue on Unix. I learned about it from books, as I’m not that old a professional 🙂

    The point was that NULL has always been #defined as (void *)0, but in the old days reading or writing from address 0 wasn’t punished by the system with an access violation. Subsequently, misbehaving apps using uninitialized pointers would be able to read/write from that location; reading from location 0 would happily bring in whatever someone else had written previously. At some point, someone bit the bullet and marked that page as inaccessible (no read, no write, no execute). Many (buggy) apps crashed, developers balked, but eventually people accepted this as a feature and as a normal behaviour.

    The story is not directly related to the issue being discussed here, but the point is that Microsoft has one great chance of getting rid of legacy stuff and of bad practices. Introducing AppHacks or any other such "feature" that contradicts with the most basic software design principles would be a great loss for an excellent development platform like .NET.

    Just bite the bullet and don’t do such things.

  17. I don’t think I need to emphysize the importance of AppCompat. If you would like, you can read Raymond’s blog.

    This is the cost of doing business.

  18. Kevin Dente says:

    Ironic that Raymond appears to be arguing against AppHacks, isn’t it? 🙂

    I agree that they may be a necessary evil, due to the shortsighted decisions some people make (which apparently the VS.NET installer team is not immune to).

    Of course, you could also avoid the problem by installing the 1.1 framework with Longhorn. 😉 Oh wait – is that even possible? Or does framework SxS go bye-bye when it’s built into the OS?

  19. Kevin,

    I can’t disclose any longhorn information. But you can use your logic to think what could happen.

  20. Eric Newton says:

    Kevin, this is the most obvious answer to the MSI problem… have the correct framework installed for the app, if thats what it is KNOWN to be good on. So thats a good suggestion.

    I would assume that Longhorn does the SxS just fine, if it doesn’t than its STILL BROKE.

    Sorry, I’m being very blunt here, Microsoft should STOP PERSISTING BAD HABITS. They continue in the name of "BUSINESS". An argument was brought up that AppHacks enable Lotus 1-2-3 to continue to run on Longhorn. GREAT! Who the HELL is using Lotus 1-2-3 anymore? Think about it.

    The person who wouldnt buy Windows XP because Lotus 1-2-3 doesnt run properly on it, WOULDN’T BUY WINDOWSXP anyways. THATS TRUE BUSINESS: BUSINESS with INTELLIGENCE.

  21. Eric,

    Personally, I totally agree with you.

    And this is why you and I are not the one making business decision.

Skip to main content