Tips and Tricks: 10 Things to Avoid if You Want Apps to Work on Future CLR Versions

1. Tips and Tricks: 10 Things to Avoid if You Want Apps to Work on Future CLR Versions Robert Villahermosa, Robert Kenny FUNL01 Microsoft Corporation

2. In English: Top 5 .NET Framework and Top 5 OS Compatibility Issues Robert Villahermosa, Robert Kenny FUNL01 Microsoft Corporation

3. Overview • Background • Top five .NET Breaking Changes • Top five ways to ensure your application will be incompatible • Questions

4. BackgroundWhat 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

5. BackgroundWhy 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

6. Breaking Change #5Enterprise 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

7. Breaking Change #5Enterprise 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

8. Breaking Change #4Dotfuscator 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

9. Breaking Change #4Dotfuscator 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

10. Breaking Change #3Type 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

11. Type checking in User Defined Type (UDT) Columns

12. Breaking Change #3 Type checking in User Defined Type (UDT) Columns • Mitigation • None • Workarounds • Explicitly forego type checking by setting UDT type to ‘Object’

13. Breaking Change #2XHTML 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

14. Breaking Change #2XHTML 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>

15. 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

16. Breaking Change #1Fusion 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”);

17. Assembly Textual Identity Parsing

18. Breaking Change #1Fusion 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>

19. 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

20. Number FiveIgnore 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

21. Number FourIgnore 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

22. Number ThreeHardcode 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

23. Number TwoPretend 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

24. Number OneChoose 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”);

25. OS Version CheckUsing 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; }

26. OS Version CheckUsing 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; }

27. OS Version CheckUsing 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;

28. Summary • Check OS version numbers with care • Treat the registry with respect • Use SHGetFolderPath • Pay attention to newer hardware • Pay attention to windows sessions

29. 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

30. Most Apps Just Work! Quake II.NET: A Managed C++ app built on v1.0 of the .NET FX

31. 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.