Transcript Top Ten AppCompat Tips And Tricks

Tips and Tricks: 10 Things to
Avoid if You Want Apps to Work
on Future CLR Versions
Robert Villahermosa, Robert Kenny
FUNL01
Microsoft Corporation
In English: Top 5 .NET
Framework and Top 5 OS
Compatibility Issues
Robert Villahermosa, Robert Kenny
FUNL01
Microsoft Corporation
2
Overview
Background
Top five .NET Breaking Changes
Top five ways to ensure your application
will be incompatible
Questions
3
Background
What and why?
What is compatibility?
Ability to run applications built on older versions of the platform to
run on the latest version
Ability for older applications to benefit from new capabilities of the
latest platform (ex FUS)
Why is it important?
End-Users: Their applications just work when running them on
their latest machines
Developers: Minimizes the work required to move to newer
versions of the platform
IT Admins: Greater confidence in deploying new versions of the
product and allowing developers to take dependencies on the
newer platform
4
Background
Why would we break you?
All breaking changes evaluated for the trade-off
between preserving compatibility and the value
of the change to customers
Potential Justifications for a breaking change
Security
Determinism
Standards Compliance
New features
Correctness
5
Breaking Change #5
Enterprise Library Application Blocks
The Break
Customers who used the January 2005 release of the Enterprise
Library Application Blocks will run into “Unrecognized Attribute” or
“Unrecognized configuration section” errors if they run their
application against Whidbey
The Blocks are doing a validation of the v1.1 configuration
schema on the new v2.0 configuration file, so fail when they run
into added sections
The Rationale
Most of the apps encountered in the field that used the Enterprise
Library Blocks redistributed the runtime they were built against
The fix required hacking of String.StartsWith() and was stomach
churning to everyone who considered it
6
Breaking Change #5
Enterprise Library Application Blocks
Mitigations
This only impacts applications using the
January Application Block Release
Most apps encountered in the field run in
environments with the v1.1 runtime installed
and can take advantage of Side-By-Side
Workarounds
Upgrade to the June release of the Application
Blocks
7
Breaking Change #4
Dotfuscator obfuscated assemblies
The Break
Applications that use the original Dotfuscator will not
run under partial trust
The impact here is largely with Dotfuscated ASP.NET
third-party controls
The Rationale
The versions of the Dotfuscator the shipped with
Visual Studio 2002 and Visual Studio 2003 emit invalid
metadata that describes value types (such as byte) as
reference types
Allowing this in v2.0 for partially trusted applications
opens up a type hole
8
Breaking Change #4
Dotfuscator obfuscated assemblies
Mitigations
This only impacts applications running in
partial trust
Workarounds
Preemptive (owners of Dotfuscator) have
released a patch that updates an obfuscated
binary with the correct metadata
The assembly can be granted full trust
9
Breaking Change #3
Type checking in User Defined Type
(UDT) Columns
The Break
We now check do a type check for data entered into
UDT Columns
You can no longer assign values to UDT Columns that
are not of the UDT type
The Rationale
Using untyped ‘Object’ storage for UDT’s
compromised type checking
We wanted consistency with UDT support in
SQL Server
10
Type checking in User Defined
Type (UDT) Columns
11
Breaking Change #3
Type checking in User Defined Type
(UDT) Columns
Mitigation
None
Workarounds
Explicitly forego type checking by setting UDT
type to ‘Object’
12
Breaking Change #2
XHTML conformance
The Break
The HTML rendered by ASP.NET apps is slightly
different in v2.0 than in v1.1
Control naming conventions for non id’ed controls and
container controls have changed, client side scripts
using hard coded ids might break
The Rationale
Standards Conformance
XHtml conformant rendering was one of the top
requests from customers for the v2.0 release
13
Breaking Change #2
XHTML conformance
Mitigations
Only affects apps that had dependency on
specific rendering generated in v1.1
Default rendering in v2.0 is XHtml 1.0
Transitional conformant
Workarounds
Add the configuration switch to the web.config
file of each ASP.NET application affected:
<system.web>
<xhtmlConformance mode=“Legacy"/>
<system.Web>
14
Breaking Change #1
Assembly Textual Identity Parsing
The Break
Assembly textual identity parsing is now
stricter and can fail in several situations where
it previously passed
APIs that generate or use assembly textual
identities (e.g. assembly resolve hook) may
now get strings that have special characters
escaped
The Rationale
We wanted to notify users of errors, instead of
silently ignoring them
15
Breaking Change #1
Fusion Textual Identity Parsing
Examples of breaking identities
//Example 1: Bad attribute values e.g. 5 part version number
Assembly.Load("myAssembly, version=1.0.0.0.0“);
//Example 2: Blank Attributes
Assembly.Load(“myAssembly, Version=2.0.0.0,Culture=Neutral, ,”)
//Example 3: Assembly names with characters that need to be
escaped such as ‘’’
Assembly.Load(“Rob’sAssembly”);
16
Assembly Textual
Identity Parsing
17
Breaking Change #1
Fusion Textual Identity Parsing
Mitigations
Unknown attributes allowed
Assembly.Load(“myAssembly, version=1.0.0.0, foo=bar”);
Customer Workaround
Modify the applications .exe.config file
with the following switch
<configuration>
<runtime>
<useLegacyIdentityFormat enabled="1" />
</runtime>
</configuration>
18
Top Five Ways To Ensure…
…your application will be incompatible
All the way from the home office in
Redmond, WA
The five best ways to ensure your
application doesn’t work on the next
OS release
19
Number Five
Ignore Window sessions
Sessions separate multiple logons
Terminal Server
Fast User Switching
Windows Vista:
Services run in session 0
First user will log into session 1!
Session 0 is not an interactive session – No UI
When using named objects
ALWAYS specify Global\ or Local\ namespace
FindWindow/SendMessage doesn’t work across
sessions
20
Number Four
Ignore newer hardware
16 bit components not supported on
64 bit OS
Many older installers use 16 bit setup.exe
32 bit drivers not supported on 64 bit OS
WIN64 architecture does support x86
code
GetNativeSystemInfo returns true system
info
GetSystemInfo returns info relative to WOW
emulated environment
21
Number Three
Hardcode your file and directory locations
ALWAYS use SHGetFolderPath
Environment.GetFolderPath for managed
code
Store application data in CSIDL_APPDATA
Do not store user files and settings in the
exe directory
Documents and Settings is being renamed
Will be called “Users” in Windows Vista
Directory layout being flattened
22
Number Two
Pretend the registry is your
private playground
DO NOT read undocumented registry
values
Current REG_SZ types may be converted
to REG_EXPAND_SZ
New routines for reading registry
Both expand REG_EXPAND_SZ if desired
SHRegGetValue >= XP SP2
RegGetValue
>= Srv03 SP1
23
Number One
Choose not to run on the OS
Most common “incompatibility” problem
Application almost always works
Poor customer experience
Check against minimally supported OS
If (osVersion >= 6) printf(“Windows Vista and newer”);
Better yet determine if your required feature exists:
OpenService(hScm,“CiSvc”,GENERIC_READ);
GetProcAddress(hShell32, “SHRegGetValue”);
24
OS Version Check
Using VerifyVersionInfo
BOOL IsVistaOrNewer() {
ULONGLONG osVersionCondition;
OSVERSIONINFOEX osVersion;
// Note using the VER_GREATER_EQUAL comparison
osVersion.dwOSVersionInfoSize = sizeof(osVersion);
osVersion.dwMajorVersion = 6;
osVersionCondition = VerSetConditionMask(0, VER_MAJORVERSION,
VER_GREATER_EQUAL);
if (VerifyVersionInfo(&osVersion, VER_MAJORVERSION,
osVersionCondition)) {
return TRUE; // Vista
} else if (GetLastError() != ERROR_OLD_WIN_VERSION) {
// Handle API error
}
return FALSE;
}
25
OS Version Check
Using GetVersionEx
BOOL IsVistaOrNewer()
{
OSVERSIONINFOEX osVersion;
osVersion.dwOSVersionInfoSize = sizeof(osVersion);
if (GetVersionEx((LPOSVERSIONINFO)&osVersion)) {
// Determine if this is Windows Vista or newer
// Note the >= check
if (osVersion.dwMajorVersion >= 6) {
// Vista
return TRUE;
}
} else {
// Handle API error
}
return FALSE;
}
26
OS Version Check
Using InstallShield script
Dlg_SdWelcome:
szTitle = "Welcome";
// Avoid using SYSINFO.WINNT.bWinXP
// Note usage of >= comparison
if (SYSINFO.nOSMajor >= 6) then
szMsg = "Windows Vista or newer";
else
szMsg = "Older than Vista";
endif;
//{{IS_SCRIPT_TAG(Dlg_SdWelcome)
nResult = SdWelcome( szTitle, szMsg );
//}}IS_SCRIPT_TAG(Dlg_SdWelcome)
if (nResult = BACK) goto Dlg_Start;
27
Summary
Check OS version numbers with care
Treat the registry with respect
Use SHGetFolderPath
Pay attention to newer hardware
Pay attention to windows sessions
28
Most Applications Just Work!
Our in-house .NET Framework
compatibility suites have pass rates of
over 90%
Windows compatibility rates have
historically been in the same range,
and we do not expect any changes for
Windows Vista
We are providing you with this information
now to drive that number even higher in
the next release
29
Most Apps Just Work!
Quake II.NET: A Managed C++ app built
on v1.0 of the .NET FX
30
2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.