{"id":2350,"date":"2015-09-17T14:21:54","date_gmt":"2015-09-17T18:21:54","guid":{"rendered":"https:\/\/www.tmurgent.com\/TmBlog\/?p=2350"},"modified":"2015-09-30T15:28:08","modified_gmt":"2015-09-30T19:28:08","slug":"app-v-and-net-native-images-updated","status":"publish","type":"post","link":"https:\/\/www.tmurgent.com\/TmBlog\/?p=2350","title":{"rendered":"App-V and .Net Native Images Updated"},"content":{"rendered":"<p><img decoding=\"async\" src=\"https:\/\/www.tmurgent.com\/TMBlog\/wp-content\/uploads\/2014\/12\/Performance.PNG\" alt=\"\" align=\"left\" \/>Last year I wrote\u00a0<a href=\"https:\/\/www.tmurgent.com\/TmBlog\/?p=2175\" target=\"_blank\">an article<\/a> on App-V and .Net Native Images and how they didn&#8217;t work with App-V.<\/p>\n<p><span style=\"font-size: 16pt; font-weight: bold; color: #900000;\">I was wrong<\/span>, but it wasn&#8217;t my fault. It turns out that the trusted tooling that I used, the <i>Microsoft SysInternals ProcessExplorer<\/i>, was lying to me.<\/p>\n<p>One of the uses of ProcessExplorer is to view the modules (fancy name for dll&#8217;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.<\/p>\n<p>Oops. (But I said assume so you are included).<\/p>\n<p>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&#8217;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???<\/p>\n<p>ProcessExplorer didn&#8217;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.<\/p>\n<p>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 &#8220;real code&#8221; written by the developer of the app is running. After attempting the PVAD fix, which didn&#8217;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\u00a0(for some reason, the vendor&#8217;s installer didn&#8217;t, causing the &#8220;just in time&#8221; compilation to be performed every time it was loaded).<\/p>\n<p>This solved the timing issue and the App now runs my package. [No, I can&#8217;t name the app or vendor at this time].<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Last year I wrote\u00a0an article on App-V and .Net Native Images and how they didn&#8217;t work with App-V. I was wrong, but it wasn&#8217;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&hellip; <a class=\"more-link\" href=\"https:\/\/www.tmurgent.com\/TmBlog\/?p=2350\">Continue reading <span class=\"screen-reader-text\">App-V and .Net Native Images Updated<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[47,48,50,1],"tags":[4,13],"class_list":["post-2350","post","type-post","status-publish","format-standard","hentry","category-appv5","category-sequencing","category-tools","category-uncategorized","tag-app-v","tag-sequencing","entry"],"_links":{"self":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/2350","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2350"}],"version-history":[{"count":4,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/2350\/revisions"}],"predecessor-version":[{"id":2355,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/2350\/revisions\/2355"}],"wp:attachment":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2350"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2350"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2350"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}