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
- Anonymous
October 09, 2004
"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. - Anonymous
October 09, 2004
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. - Anonymous
October 09, 2004
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. - Anonymous
October 09, 2004
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. - Anonymous
October 10, 2004
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. - Anonymous
October 10, 2004
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... - Anonymous
October 10, 2004
The comment has been removed - Anonymous
October 10, 2004
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. - Anonymous
October 10, 2004
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. - Anonymous
October 10, 2004
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. - Anonymous
October 10, 2004
The side effect of this is, maybe in longhorn, we do need an AppHack for MSI packages requiring .Net 1.0/1.1. - Anonymous
October 10, 2004
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 - Anonymous
October 10, 2004
The comment has been removed - Anonymous
October 10, 2004
The comment has been removed - Anonymous
October 10, 2004
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. - Anonymous
October 10, 2004
The comment has been removed - Anonymous
October 11, 2004
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. - Anonymous
October 11, 2004
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? - Anonymous
October 11, 2004
Kevin,
I can't disclose any longhorn information. But you can use your logic to think what could happen. - Anonymous
October 11, 2004
The comment has been removed - Anonymous
October 11, 2004
Eric,
Personally, I totally agree with you.
And this is why you and I are not the one making business decision.