Categories
Microsoft Windows Installer, Application Compatibility and Deployments

How does the CLR Locates Assemblies in Applications?

To successfully deploy your .NET Framework application, you must understand how the common language runtime locates and binds to the assemblies that make up your application. By default, the runtime attempts to bind with the exact version of an assembly that the application was built with. This default behavior can be overridden by configuration file settings. The common language runtime performs a number of steps when attempting to locate an assembly and resolve an assembly reference. Each step is explained in the following sections. The term probing is often used when describing how the runtime locates assemblies; it refers to the set of heuristics used to locate the assembly based on its name and culture.

Note You can view binding information in the log file using the Assembly Binding Log Viewer (Fuslogvw.exe), which is included in the .NET Framework SDK.

For Further Reading, Please refer – http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx

Categories
How-to

How do I Create Right-Click Context Menu for my Application?

Yesterday at office when we were discussing about the applications support for 64 bit Vista, One of my work-mate, Sreejith mentioned that Symantec Antivirus doesn’t give him a context menu for scanning viruses. Here are few simple steps to create the right click context menu for scanning viruses. I am just sharing the same to everyone for your reference.

Step 1: Create the following registry key in HKEY_CLASSES_ROOT\*\shell\ as shown in the below screen. (For demo purpose – I have added my name)

Creating Context Menu - 1

Step 2: Create the association to the “Application.exe” – You can use the main executable for Symantec Antivirus here. (For demo purpose – I have used notepad.exe)

That’s it. You’re done with creating a right-click context menu…!!

Testing the same…

Categories
Microsoft Windows Installer, Application Compatibility and Deployments

What is the WinSxS folder which is present in C:\Windows?

In the early days Microsoft recommend installing DLLs to c:\windows\system32 if you wanted to share them with other applications. This lead to “DLL Hell” since one applications installer would install one version of a DLL and another installer would install another version overwriting the existing DLL. If the new version of the DLL wasn’t compatible the older application would suddenly break and stop working. With SxS technology, applications can install DLLs to version specific directories tell Windows what version of the DLL should be used when they load a DLL by that name.

You can refer this article to get the basics of Assemblies

Windows OSes which have SxS will look for an application’s manifest information to determine which version to load from SxS. A manifest is a fairly simple XML description of all the SxS DLLs that might be loaded by the application and which version to use. The manifest can either be embedded in the application EXE/DLL file as a resource or stored separately on the filesystem as a .manifest file. In the second case, the manifest file for app.exe would be called app.exe.manifest.

The manifest resolution algorithm is fairly complex and I won’t get into all the details here, but it can include among other things searching based on the user’s locale (i.e. Look for French/German version first). As well, to eliminate security disasters like what happened with gdiplus.dll, SxS DLLs have a “force upgrade” mechanism implemented as separate security policy files (also XML files). This mechanism allows Microsoft to override version number request by applications in the case where some gaping security hole is discovered in a shared library that effects thousands of applications. For example, an application manifest may say “I want version 1.0.0.0 of xyz.dll”, but Microsoft can push a policy file update that says “redirect all request of version 1.0.0.0 to 1.0.0.5”.

Categories
Best Practices How-to Windows Installer, Application Compatibility and Deployments

How good is to use GetVersion function to detect the OS version number?

The internal version number for Windows Vista is 6.0 and Windows 7 is 6.1.  The GetVersion function returns this version number. The problem is, some applications will return a higher version number. 

Symptoms of OS Version 

  1. Applications that check for OS version will get higher version number.
  2. Application installers may prevent themselves from installing the app and apps may prevent themselves from starting.
  3. Applications may warn users and continue to function properly.

Mitigation Techniques for OS Version

  1. For apps and installers that check for OS version, a Compatibility mode is provided in Windows Vista
  2. Users can right right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode from the Compatibility tab. This applies multiple shims including “WinXPSP2VersionLie”
  3. Better: Apply the shim “WinXPSP2VersionLie”
  4. In many cases, applications will work the same way that it did in Windows XP and there is no need for changes to the application

Fixes for OS Version

Applications should not perform version checks for equality (== 5.1)

  1. If you need a specific feature, check whether the feature is available.
  2. If you need Windows XP, check for Windows XP or later (>= 5.1).
  3. Exceptions to this occur when there is a very specific business, or legal need to do a version check, such as regulatory body requires you to certify your application for each operating system and version.
Categories
General Microsoft

Mis-understood Features of Windows Vista

This is a very good article to understand Windows Vista better. There are lot more to talk about. Once you go through that article, I believe your complains would be reduced for sure !!!!

You can obtain the article from here

Categories
How-to Windows Installer, Application Compatibility and Deployments

Basics and Introduction to .NET Framework Assemblies

An Assembly is a logical unit of code. Assembly physically exist as DLLs or EXEs. One assembly can contain one or more files. The constituent files can include any file types like image files, text files etc. along with DLLs or EXEs. When you compile your source code by default the exe/dll generated is actually an assembly, Unless your code is bundled as assembly it can not be used in any other application. Every assembly file contains information about itself. This information is called as Assembly Manifest.

What is assembly manifest?

Assembly manifest is a data structure which stores information about an assembly. This information is stored within the assembly file(DLL/EXE) itself. The information includes version information, list of constituent files etc.

What is private and shared assembly?

The assembly which is used only by a single application is called as private assembly. Suppose you created a DLL which encapsulates your business logic. This DLL will be used by your client application only and not by any other application. In order to run the application properly your DLL must reside in the same folder in which the client application is installed. Thus the assembly is private to your application.

Suppose that you are creating a general purpose DLL which provides functionality which will be used by variety of applications. Now, instead of each client application having its own copy of DLL you can place the DLL in ‘global assembly cache’. Such assemblies are called as shared assemblies.

What is Global Assembly Cache?

Global assembly cache is nothing but a special disk folder where all the shared assemblies will be kept. It is located under <drive>:\WinNT\Assembly folder.

How assemblies avoid DLL Hell?

As stated earlier most of the assemblies are private. Hence each client application refers assemblies from its own installation folder. So, even though there are multiple versions of same assembly they will not conflict with each other. Consider following example:

  • You created assembly Assembly1
  • You also created a client application which uses Assembly1 say Client1
  • You installed the client in C:\MyApp1 and also placed Assembly1 in this folder
  • After some days you changed Assembly1
  • You now created another application Client2 which uses this changed Assembly1
  • You installed Client2 in C:\MyApp2 and also placed changed Assembly1 in this folder
  • Since both the clients are referring to their own versions of Assembly1 everything goes on smoothly

Now consider the case when you develop assembly that is shared one. In this case it is important to know how assemblies are versioned. All assemblies has a version number in the form: major.minor.build.revision. If you change the original assembly the changed version will be considered compatible with existing one if the major and minor versions of both the assemblies match. When the client application requests assembly the requested version number is matched against available versions and the version matching major and minor version numbers and having most latest build and revision number are supplied.

Categories
Microsoft Windows Installer, Application Compatibility and Deployments

APPCRASH Messages – Overview and Example Scenarios

Vista and Windows 7 have a variety of fault-protection systems that try to prevent a crashing application from taking down your entire computer. When Windows Vista detects that an application has crashed, it terminates it and generates an Appcrash error report. This report is useful, since it can be sent to Microsoft Team. Most of the applications crashes give an exception code of c0000005.

APPCRASH Scenarios: (in the order of their occurrence Rates)

Scenario 1
Problem Event Name: APPCRASH
Application Name: explorer.exe
Application Version: 6.0.6001.18000
Application Timestamp: 47918e5d
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.6001.18000
Fault Module Timestamp: 4791a727
Exception Code: c0000005
Exception Offset: 00009c00
OS Version: 6.0.6001.2.1.0.768.3
Locale ID: 1041
Additional Information 1: 72b2
Additional Information 2: 693d7799b8b778ed847472df9568cf8f
Additional Information 3: a1b0
Additional Information 4: 0d44ab9553a107ee7d95071a61aa480b

This problem can be solved, if the dll or supported depreciated dll is isolated to the application installation directory. For eg: Renaming cmoctl32.dll file to .old and let it rebuild itself. Like trashing an ini file and letting it rebuild itself.

Scenario 2
When some core application components (VB and VC++ runtime, DHTML controls etc…) are missing the machine/build, we get the APPCRASH message for few of the applications.

Scenario 3
Problem Event Name: APPCRASH
Application Name: PhotoStudio.exe
Application Version: 5.5.0.91
Application Timestamp: 46861e12
Fault Module Name: dtype32.dll
Fault Module Version: 3.9.4.4
Fault Module Timestamp: 3ebed48a
Exception Code: c0000005
Exception Offset: 0000e004
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 2057
Additional Information 1: d6bf
Additional Information 2: 0623d5f43aa286e60fe956167dbc9d6f
Additional Information 3: f083
Additional Information 4: 4aaeb79ec497d908d232129b547584f0

In these scenarios the application is not supported to run in Vista. Here we need the latest version/update to work with Vista. For the entire list of applications which works on Vista, refer to this link.

Applications which work with Vista
https://winqual.microsoft.com/member/softwarelogo/workswithlist.aspx

VISTA Certified applications List
https://winqual.microsoft.com/member/softwarelogo/certifiedlist.aspx

Scenario 4
Sometimes, on invoking the application shortcuts, we get the appcrash message with CLR20r3 error. This error occurs when there is a un-compatible .NET framework installed. It’s an exception in Winforms that Under References, System, System.Data, System.Drawing, System.Windows.Forms, and System.XML might have been developed references to .NET framework 1.1.

In few scenarios, the application doesn’t work if a higher version of framework is installed. In this case, we may need to create a manifest where we inform the application to check only for the framework 2 or 1.1 components.

Scenario 5
Some Application services which is not compatible to start with Vista, throws the APPCRASH message.
An exception here is that, services which are running in session 0 will show a Session 0 Isolated OTS window.

Scenario 6
When you have a third party control panel applet (older version of application), we have an appcrash pointing to explorer.exe.
In this case, we will need to update the application with the newer version.

Scenario 7
Seemingly random crashes are often caused by RAM errors. This can happen in Vista and not XP because of the way Vista loads. Vista uses something called Address Space Load Randomization (ASLR) to load the system into slightly different areas of RAM every time it loads as a security feature. XP doesn’t do this. This means if you have bad RAM (or bad hardware causing the symptom of bad RAM) XP may not notice it because the bad RAM isn’t in a system area. Vista because it loads the system into varying areas of RAM may crash with many different errors.

One Solution for this is to run SFC (System File Checker http://support.microsoft.com/kb/929833).

If you find/or have encountered few other scenarios, please add your comments to this page.

Categories
How-to Microsoft

How to register a File Extension in Windows?

If your application uses special file extensions, you might want to register them so that the application gets started when the icon associated with the file gets double-clicked.

There are special tables for this in the MSI structure (Extension and ProgId). The contents of these tables are used for advertising. You can also make your own registry entries to create application-to-file-extension relations. This example shows how to register the .dvi extensions to be opened with the yap.exe program.

Link the extension .dvi to the DVI.Document class:

Key: HKLM\SOFTWARE\Classes\.dvi
Value: <default> = “DVI.Document”

Describe the DVI.Document class:

Key: HKLM\SOFTWARE\Classes\DVI.Document
Value: <default> = “DVI Document”

Select Icon #0 from yap.exe which is in the MSI:

Key: HKLM\SOFTWARE\Classes\DVI.Document\DefaultIcon
Value: <default> = “[!yap.exe],0”

How to open the .dvi file if it is double clicked in the Explorer:

Key: HKLM\SOFTWARE\Classes\DVI.Document\shell\open\command
Value: <default> = “[!yap.exe]” “%1”

Categories
Best Practices Microsoft Windows Installer, Application Compatibility and Deployments

Microsoft Best Practices & Standards: Application Packaging

Here are a few tips I picked up from Microsoft about how to “color inside the lines” when using any tool (including Wise Package Studio) to create an MSI.

  1. Match components in previous versions of the MSI:
    Key path resource matches a resource in previous .MSI list
    Match component layout of previous .MSI
    Set component key to match previous version.
  2. Add all executable files to their own components
  3. Create new component for the resource
  4. Add all .TLB files to their own components
  5. Group matching .HLP and .CNT files together
  6. Group matching .CHM and .CHI files together
  7. Put registry keys associated with files or components in matching components.
  8. Put current user registry keys in their own component
  9. Put non-current user registry keys in their own component.
  10. Group all non-executable files to their own component
  11. Name new non-advertised shortcuts by destination directory.
  12. Group non-key path resources by resource type
  13. Create new components for resources not matching other criteria.
  14. Set component key to table name of key path or the first resource.

Hope these little guidelines helps!

Categories
Microsoft Windows Installer, Application Compatibility and Deployments

How to check an Executable for Manifests and Digital Signing?

To avoid UAC prompts for applications on launch, there exists a manifest file which contains key information on the privileges. Many times, these manifest files are present along with the executable in the same directory. For example: Altair.exe will have a manifest file called Altair.exe.manifest in the same directory. There can also be cases where the manifest is embedded in the exe itself. In this case, identifying the launch condition for this exe involves a lot of research.

Here is a simple executable which will help research those launch conditions.

Sigcheck.exe is an executable from the Sysinternals team that enables you to check whether a file has been digitally signed. The -m switch allows you to view any manifest within the file. All we need to do is run this sigcheck.exe with -m switch along with the executable, the full manifest will be displayed on the command prompt window.

If the XML manifest is going to prompt an elevation then there will be a tag “requiredExecutionLevel” set to “requireAdministrator”.

You can then re-create a manifest on these 3 categories:

  • Runasinvoker
  • Runasadmin
  • Runwithleastprivilages

Its advised to use Run as Invoker for manifests (Launch condition).

Signcheck.exe can be downloaded here.