Windows 7 Compatiblity
-
Recently, I've been running the Application Remediation and Compatibility team for our Windows 7 Migration. Most of our machines are moving from Windows XP 32 Bit, to Windows 7 64 Bit.
In English, we're a small team of folks who help get applications running on Windows 7. Some are as simple as downloading new versions of COTS apps, or adjusting a few ini files or registry values. Sometimes it may involve application compatibility shims. Some involve rewrites, either done by my team or my team advising other internal programming teams.A large part is working with internally developed applications. We're a large company, and each line of business has development teams of various quality. As an example, the QA Testing Team found an application failing with the error, "Unable to Open C:\Program Files\NameOfProgram\Config.xml"
A common enough issue in a 32 to 64 bit migration- A 32 bit app will get installed to C:\Program Files (x86) on a 64 bit OS, but the original team had the path to their config file hard coded. We met with them, explained how to do relative paths, and we're done.
Or so we thought- Next week the testing team came back, saying that now on 32 Bit OS's, it was failing with the error "Unable to Open C:\Program Files (x86)\NameOfProgram\Config.xml".
You can lead a horse to water, but you can't make him think.
Anyway, I told you that story so I can tell you this story - And hopefully, to give you a quick to determine if this is something you want to bother reading the rest of this.
We have another application where the app itself works fine- But it's being deployed by pointing users to a URL and having them download and install it off a web site. It's an internal web site, and has a define Development - Test - Production workflow, so I'm not incredible worried about that. But the setup is downloading to a location that standard users will not have access to. Worse, because of how the setup is named, it won't trigger a UAC Prompt- So it will fail even for Administrators, unless they use "Run as Admin" on IE to open the shortcut.
Not a difficult fix- We grab the files that were being downloaded, wrap them into a MSI, and deploy it via SCCM to the test machines. It works for our testers, it works for their testers, and we're done.Or so we thought. The team who wrote it is insisting on troubleshooting the deployment problem. Worse, they have completely ignored the 2 problems we've brought up to them, and instead want to focus on .NET Framework 2.0 as a dependency.
Now, .NET Framework 2.0 is included in .NET Framework 3.0, which is in turn included in .NET Framework 3.5. They use the same Runtime, just add new managed libraries. Those of you with a somewhat deeper understanding of the .NET Framework can pick all sorts of nits with that, but those with a really solid understanding realize that what I'm saying - A well written application using .Net Framework 2.0 will run just fine using 3.5- is true.
As 3.5 is included in Windows 7, we're fine. We explain this, similar to the above paragraph.
The team wants to argue- No, it's failing because .NET Framework 2.0 isn't installed.
Keep in mind we've already shown them their applications runs- It just doesn't install. We show the .Net Framework design documents show this. We show several TechNet documents stating this. We show the MSDN Article on .Net Framework Backwards compatibility. We show several Microsoft Employee blogs about this. We call our TAM, have a Microsoft Rep join the call, and explain it. I even showed them the Wikipedia page about .Net Framework.
After each of these items, they insisted they needed to see .Net Framework 2.0 listed in Programs and Features, and that would fix the problem.
So we switched tact. We tried to install .NET Framework 2.0 and showed them the error message. x86 and x64 versions. After removing .NET Framework 3.5 support in the OS. After a clean install of Windows 7. In fact, here's a brand new vanilla installed Windows 7, not even joined to the Domain, you can have it- Let me know when you get .NET Framework Installed.
I haven't heard back from that team yet.
-
@cdosrun said:
Now, .NET Framework 2.0 is included in .NET Framework 3.0, which is in turn included in .NET Framework 3.5. They use the same Runtime, just add new managed libraries. Those of you with a somewhat deeper understanding of the .NET Framework can pick all sorts of nits with that, but those with a really solid understanding realize that what I'm saying - <font color="#FF0000">A well written application</font> using .Net Framework 2.0 will run just fine using 3.5- is true.
Well, there's your problem.@cdosrun said:The team wants to argue- No, it's failing because .NET Framework 2.0 isn't installed.
Huh? What? How do you run a program without installing it first?@cdosrun said:
Keep in mind we've already shown them their applications runs- It just doesn't install.
We tried to install .NET Framework 2.0 and showed them the error message. x86 and x64 versions. .
Maybe something was changed in Windows 7, because that was not the case with Vista.A few years ago, when I switched from Windows XP to Vista x64, I did a clean install of Vista and then began installing all of my various applications. Everything went perfectly except for one (very important) application. Despite the fact that Vista included .Net 3.0, this program would not install, giving me an error message saying that .Net 2.0 was required. WTF? Did they hardcode the requirement for .Net 2.0 into the installer? That's the only thing I can think of. Once I downloaded and installed .Net 2.0 then the program installed just fine. They have since fixed this problem in newer versions of their installer, but I think it illustrates that the alleged backwards compatibility of .Net is not as fool proof as some would claim.
-
@El_Heffe said:
Huh? What? How do you run a program without installing it first?
We rewrote the installer they were using as a MSI that put the same files and shortcuts on their machines. We deployed it via SCCM to their QA Teams machines, who tested it and found it functional.
@El_Heffe said:
Everything went perfectly except for one (very important) application. Despite the fact that Vista included .Net 3.0, this program would not install, giving me an error message saying that .Net 2.0 was required. WTF? Did they hardcode the requirement for .Net 2.0 into the installer?
From what I've seen, yes, it's quite likely they hard coded a Launch Condition into the MSI (...Or other installer) that checked for it.
The default check included with InstallShield uses a registry value (Again, from memory) that also exists on Windows 7 with 3.5 SP1 included, so that launch condition should pass. However, if they rolled their own, it quite possibly did not. Also, I'm less familiar with Vista than I am with 7.
On 7, .Net 2.0 Framework will fail to install, saying (From memory) You must use "Turn windows features on or off" in the control panel to install or configure .Net Framework support".
-
@cdosrun said:
On 7, .Net 2.0 Framework will fail to install, saying (From memory) You must use "Turn windows features on or off" in the control panel to install or configure .Net Framework support".
That would be because .NET 2.0 is now an actual OS component and 'installing' it means opening it up for other programs to use. Therefore none of the redistributable installers for .NET 2.x will actually allow an install to take place; that might break the OS. My guess is that the redistributable installers for .NET 2.x have been retro-fit some time shortly before the Windows 7 release to show a message specifically to users of Windows 7 and up that they can toggle .NET framework support through the Windows Features.
@cdosrun said:
The default check included with InstallShield uses a registry value (Again, from memory) that also exists on Windows 7 with 3.5 SP1 included, so that launch condition should pass.
This is the recommended best practice, infact. The registry keys you can (and sometimes should) check for are quite exhaustive.
It's really nothing special that you'd get a small-time software firm pushing out a hacked together installer, because the boss is breathing down the neck of the one semi-competent developer the company has. It's the same thing with hard-coded user paths, temporary directories, etc. Rather than taking the time to figure that stuff out, you're stuck in an eternal hell of catching up to the deadline of last week's project.
-
@El_Heffe said:
the alleged backwards compatibility of .Net is not as fool proof as some would claim
Fool-proofing is hard. You keep coming across bigger fools. Better to focus on making error logs actually contain useful info so that when things go wrong, you can at least figure out what actually failed. Since you can't make everyone happy, at least try to make things not always awful for yourself.
-
@Ragnax said:
That would be because .NET 2.0 is now an actual OS component and 'installing' it means opening it up for other programs to use. Therefore none of the redistributable installers for .NET 2.x will actually allow an install to take place; that might break the OS. My guess is that the redistributable installers for .NET 2.x have been retro-fit some time shortly before the Windows 7 release to show a message specifically to users of Windows 7 and up that they can toggle .NET framework support through the Windows Features.
I wonder what they do for something like Steam then, where it doesn't even check if it's installed already, just runs the redistributable until it exits 0.
-
@El_Heffe said:
A few years ago, when I switched from Windows XP to Vista x64, I did a clean install of Vista and then began installing all of my various applications. Everything went perfectly except for one (very important) application. Despite the fact that Vista included .Net 3.0, this program would not install, giving me an error message saying that .Net 2.0 was required. WTF? Did they hardcode the requirement for .Net 2.0 into the installer? That's the only thing I can think of. Once I downloaded and installed .Net 2.0 then the program installed just fine. They have since fixed this problem in newer versions of their installer, but I think it illustrates that the alleged backwards compatibility of .Net is not as fool proof as some would claim.
Except that the application having a hardcoded requirement for .Net 2 is hardly the fault of the .Net system. You yourself said the only explanation you could think of was that the installer was looking for evidence of 2 being installed, NOT that a version of .Net greater than or equal to 2 was installed. Microsoft's developers can't possibly plan for that.
