- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Microsoft .NET Framework "Access is Denied"
I am having trouble getting a component of a ThinApp application working. A bit of background information:
The virtual desktop does not include a native browser.
This is a custom application that basically uses presents two IE Frames within the application.
The application is packaged and linked to IE9 and .NET Framework 3.5.1 packages (Via AppLink)
The application contains a button that opens an external application (ThinApp and Linked via AppLink)
When I click on the button that opens the application, I am getting an "Access is Denied" message from Microsoft .NET Framework.
"Unhandled exception has occurred in a component in your application" Some further error message below.
See the end of this message for details on invoking
I am a bit stuck on a workaround for this. I guess if I cannot get the packages to work nicely together, I might just have to install .NET Framework in the gold image? I am assuming that there are some conflicts between the .NET on the virtual bubble vs. the virtual desktop? Anyone have any ideas?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is your deployment OS? XP or Win 7?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The deployment OS is Windows 7 Enterprise (64bit).
I've attempted staging the application and .NET in XP, Windows 7 32bit and Windows 7 64bit.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you try enabling the below parameters in the package.ini by removing the semicolon (;) at the beginning. Rebuild by executing the build.bat file.
LoadDotNetFromSystem=Win7
wow64=0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi There,
I have tried the suggested settings and got the attached error message.
I've also tested the following scenarios:
Just WoW64 - same .net access denied message
Just LoadDotNet - attached error
WoW64 & LoadDotNet - attached error
I have included the .net framework in a new test package also to see if that makes a difference, and it does not seem to help. (vs. AppLink in orginal package)
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you removed NET package from Applink before trying those?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did leave out the .NET AppLink and still getting the same access is denied message.
This application requires some caspol settings to allow the button on the webpage to open a "linked" application. Without the caspol settings, I am getting the attached error message.
See the end of this message for details on invoking
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you tried capturing everything into one single package, your app and the external app? Does it run?
Can you try after that to execute this virtual package on a machine with a native IE9 and .NET Framework 3.5.1 installed?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've captured the applicaiton in a single package and I am still getting the same error message. I am currently testing this on a machine with .NET 3.5.1 installed but that doesn't seem to make a difference. When packaging it into a single application, I did lauch the application and ensured that it was working prior to postscan. But just doesn't seem to want to work once it is packaged.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As Windows 7 has .NET 3.5 preinstalled, can you try removing the .NET Applink, enable the two package.ini parameters and check?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
During my testing, I did remove the .NET applink to test the parameters. The staging workstation has .NET 3.5 installed while the base image for the linked clones do not. I have confirmed that package is using either the AppLinked .NET or the one with the desktop outside of the virtual bubble. Both does not seem to work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As your deployment OS is Win7 64, can you try packaging the application on Win7 64 without bundling .NET and enabling the two package.ini parameters discussed above?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've engaged VMware support and have an open ticket now on this issue. We were able to determine the issue to be cause be an applicaiton rather than the .NET Framework. In short, an AppLink applicaiton is running in the x86 program files folder, but by the nature of ThinApp, it is putting a link to the program files folder as well. When the executable is ran from the program files folder (64bit), it is giving an access denied. When the applicaiton is ran from the x86 program files folder, it launches. Due to the nature of our custom application, we are looking at options to ensure that we run the x86 command instead.