Musings of an Application Packager

If you have a package which contains multiple shortcuts to the same executable (but different arguments), then you'll most likely find that most of the shortcuts (except one) will be hidden from the Windows 8 Start Screen, and won't even appear under "All Apps".  This package is authored correctly and fully ICE validated.  This package creates 10 shortcuts, yet only one of the shortcuts which has a target of "Loader32.exe" is showing.  Take a look at the screenshot of the relevant program group as showin in the Windows 8 Start Screen Below. All the rest of the shortcuts that have the same target of "Loader32.exe" are hidden.  This is evident, if I right click any of the three shortcuts above and click on "Open File Location" to reveal the path of where the shortcut physically exists.  See the Windows Explorer (aka File Explorer as it's now called in Windows 8)  screenshot below: The issue is to do with needin

When you apply a compatibility mode manually (either by doing it through the Program Compatbility Assistant or through File Properties, the result is that the settings get saved in the registry located at HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. To apply the fix for all users, click on "Change settings for all users", and it will relaunch the same properties screen, and the compatibility setting will then be saved to: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers You can also apply compatibility modes this via a shim, but if you were to author your package and include this key in your package, this would bypass would the need for a shim (if it were the only compatibility fix that needs to be applied). It's worth noting that this compatibility mode is essentially the same as what a the WinXPSP3VersionLie shim would do.

Basically, as an alternative to install a device driver using the DifxApp merge module (with Windows Installer), you can stage the device driver into the driver store in Windows 7 & 8 using a native utility called " pnputil .exe".  This is IDEAL for situations where you're using non MSI packaging methods and application virtualisation technologies. i.e. Apps that require a device driver, which should make virtualisation possible if you script the pre-launch logic to install the device driver physically .  Even though the files contained within the virtualised package are virtual, once they are staged into the virtual store, the drivers become physically part of it. For instance, in App-V 5, you could use a StartVirtualEnvironment event action.  For Symantec SWV packages, this would be achieved via the OnPostActivate action. What is the Driver Store ? http://technet.microsoft.com/ en-us/library/cc731478.aspx The driver store is exactly what the name sugges

I first encountered this issue today, where the client had packaged two versions of the SQL Server Reporting Services Client Printing ActiveX.  There are separate version for SQL Server 2005 and 2008 Reporting Services.  However, both of these ActiveX controls have identical filenames (rsclientprint.dll). This was a manually created package, and the following guide suggests if you don't allow standard users to install via ActiveX controls via GPO, then to package the ActiveX using the following method. So how do we know if these ActiveX controls are meant to run side-by-side or not? ( The following excerpt is from : http://www.kodyaz.com/articles/client-side-printing-silent-deployment-of-rsclientPrint.aspx ) Reporting Services Client-Side Printing and Silent Deployment of RSClientPrint.cab ActiveX file. RSClientPrint.cab is a Microsoft ActiveX control that provides client side printing for Microsoft SQL Server Reporting Services reports. The ActiveX control display