Last year I wrote an article on App-V and .Net Native Images and how they didn’t work with App-V.
I was wrong, but it wasn’t my fault. It turns out that the trusted tooling that I used, the Microsoft SysInternals ProcessExplorer, was lying to me.
One of the uses of ProcessExplorer is to view the modules (fancy name for dll’s) that are loaded by a process. Normally, if a dll is built using managed code (developer speak for .Net), it contains MSIL code. If natively compiled, foo.dll will also have a compiled copy in the assembly cache named foo.ni.dll. Normally, ProcessExplorer will show both foo.dll and foo.ni.dll as loaded modules. But for App-V applications ProcessExplorer did not show any NI files, so I assumed they were not loaded for some obscure reason that I could not explain.
Oops. (But I said assume so you are included).
This summer I released a new version of AppV_Manage that includes a run-time analyzer. One of the things it happens to do is also display loaded modules of the virtualized processes. I didn’t put that in to detect NI files, but to help you verify if dlls that are in your package are being used or if system ones are. But then I noticed an NI file in the list one day. WTF???
ProcessExplorer didn’t show it. My list is built by listening to debug windows events (ETW) in real-time, whereas ProcessExplorer probably uses a kernel32.dll API for a static check. So I can now confirm that yes, you can include these NI files inside your App-V packages and they will be used.
This became important to me this week, as I was working on an App-V package that kept crashing on launch. But the crash was in PresentationManager (part of the .NET Framework responsible for XAML display), which is probably during GUI initialization and before any “real code” written by the developer of the app is running. After attempting the PVAD fix, which didn’t help, and a dozen other things, I was desperate. Eventually I suspected I was experiencing a timing issue, and remembering that App-V will use NI files if present, I tried compiling all of their .NET code to see if it would help (for some reason, the vendor’s installer didn’t, causing the “just in time” compilation to be performed every time it was loaded).
This solved the timing issue and the App now runs my package. [No, I can’t name the app or vendor at this time].
