ClickOnce issue with Corporate IT client - wpf

So I am having some difficulty with our WPF ClickOnce deployment. I knew that we would run into issues when our clients from coporations with complex IT policies started installing. Up to this point, I have not had an issue. The application itself has a prerequisite of .NET 4.5 – which I know requires administrator privileges. Here is the error that the client is sending to me:
“C:\documents and settings\gdevlin\local settings\Temporary Internet Files\content.ie5\9wkrp310\setup[1].exe
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.”
Seems pretty obvious to me. They have of course consulted their IT dept and they confirm that there should be no problems and that they have sufficient permissions. They did note that the setup.exe file is empty – that file should be around 430 kb.

Related

WPF Clickonce update failing - Why is Trust Not Granted?

Trying to get a ClickOnce application to work correctly, but I keep encountering the "Trust Not Granted" exceptions, and I'm not yet seeing why this is happening.
The EXE is signed with a code signing certificate from VeriSign, both by setting the "Sign the ClickOnce manifests" option in the Signing tab, as well as implementing the pre-publish approach metioned here: http://robindotnet.wordpress.com/2013/02/24/windows-8-and-clickonce-the-definitive-answer-2/ . I have verified that the certificate is installed on the client machine correctly. I have verified that my EXE is signed after the build as well.
I have taken the same approach with setting explicit trusts as this StackOverflow answer: https://stackoverflow.com/a/16816341/97879
I am presently deploying to a network share, and that is the expected path for updates until we're prepared to take this application to production.
My application can see that there is an update available, but then fails when trying to update. This happens the same way on both Windows 7 and 8 machines.
What am I missing?

Helicon Ape build 0098: "Access to the path is denied" when enabling licenses

I just upgraded Helicon Ape to the latest build 0098. Then I opened the Helicon Ape Manager, went to "Help" -> "License Manager", selected one of my sites and chose "Enable free license". This message came up: "Access to the path is denied".
I made sure that I had free licenses available before I tried to enable it on that specific site. I also granted rights to "Everyone" in the security-settings of the website folder. It is also possible to explore the website folder in the Helicon Ape Manager.
Is anyone experiencing the same problem or have any idea what this could be?
Did you install Full or Free version?
What is your Windows version?
And why don't we continue looking into the problem on Helicon Tech helpdesk: http://support.helicontech.com/helpdesk/
In my case it just stopped working after a windows update. I upgraded to version 3.1.0.105 and followed the troubleshooting steps. I had to add read & list folder permissions for my IIS_USERS group to the Helicon folder in program files(x86).
This still didn't fix it. So I played with a few settings and at some-point in the process I removed .Net Framework v2.0xxxx from the app pool configuration (set it to No Managed Code.) After trying the debugger and everything else I could think of I decided to start over.
I uninstalled helicon. Reinstalled it from scratch. I re-added the IIS_USERS permissions to the Helicon application folder in Program Files (x86). And it still didn't work. Then I re-routed the application pool through .net and sure enough everything worked... which makes sense since APE is a .net application and uses .net hooks into iis.
Anyway, after doing all of that it is now working for me.

IIS related System.ExecutionEngineException

After too many hours of research I have come up with nothing to solve this problem.
I am running a WPF program in an .xbap page file being hosted on internet explorer. Running the project in Visual Studio 2010 works just fine and generates no errors.
I want to be able to host the webpage on IIS 7.0 and to browse to it with a windows forms application. To test this I created a new website on port 80 in IIS manager. I then published the project to the local website folder and added the autogenerated project certificate file (projectName_TemporaryKey.pfx) to my Trusted Publishers and Trusted Root Certification Authorities.
My problem is this: whenever I try to browse to the file with internet explorer or with my windows forms program, the wpf program stops working. When pulling up the just-in-time debugger, I am informed that there is a System.ExecutionEngineException but am given no source code, no stack trace, and no data outside of an empty Dictionary enumerable. My guess is that this might have something to do with the database call made in the program to another machine, but I can't prove that.
I've tried several things to solve this including repairing my .NET 4.0 framework and altering permissions but nothing seems to be affect the error.
Does anyone know of a way to get more information on this error, or perhaps a step I may have missed when publishing this project?
Thanks very much.
Some things to check:
Windows event log often includes additional exception information (although usually in an awful format)
Output some trace information from your application so you can follow what's happening
Try attaching a debugger to the WPFHost and then stepping through the code

Database errors in Quantum Grid demos in Delphi XE Professional

Whenever I open one of the Quantum Grid demos in Delphi XE Pro (on Windows 7 32-bit), the following error is displayed for every table (I think) in the project:
error message http://www.tranglos.com/img/qgerror.png
The message is:
Network initialization failed.
File or directory does not exist.
File: C:\PDOXUSRS.NET
Permission denied.
Directory: C:\.
I understand permission issues writing to c:\, but the result is that while I can build and run the demo projects, no data is displayed, which makes the demos rather useless. And what kind of database writes its configuration to c:\ directory in the 21st century anyway? :) (Yes, I know very little about Paradox databases, but I won't ever be using one either. I just want to learn how to use the grid.)
Using BDE Administrator I've tried changing the Paradox "NET DIR" value to a folder with write permissions on the C drive. Result: now the database tables cannot find their data:
Path not found.
File: C:..\..\Data\GENRES.DB.
...and the unhelpfully truncated path gives no indication where the files are expected to be.
Is there a way to work around the problem so that the demos can load their sample data correctly?
Did you install the BDE correctly? It should use the DBDEMOS files. Do you see such an alias in the BDE administration utility? Can you open that database in one of the Delphi demos?
The BDE is not a XXI century database, it was developed twenty years ago and never upgraded lately. It's an obsolete tecnology, but because it comes still with every release of Delphi with a known database it is still often used in demos because nothing new has to be installed.
Anyway that file is not its configuration file. It's a sharing lock file to allow more than one user to use the database concurrently. Because it is a file based database without a central server, it has to use such kind of shared files. Usually its position is changed to a network share, but it defaults to C:\ for historical reasons.
Anyway it's not only the BDE still attempting to write in the prong directories. I still see a full bunch of applications attempting to write to C:\ (especially logs) or other read-only positions.
Using BDE Admin to change the location for PDOXUSRS.NET helped, but it wasn't sufficient. DevExpress did the right thing in specifying a relative folder for the data location, and the relative folder seems perfectly allright, but for some reason the DB can't find it.
Solution: under the \Demos\ folder find all the *.dfm files that contain the string
..\..\Data
and replace that string with the absolute path to the demos folder. That done, all the demos open correctly.
I know this message from our own applications. It has to do with security measures introduced with Windows Vista. The operating system trying to protect critical files denies access to them. There is a method how to bypass this mechanism without compromising security. Try to run your application in compatibility mode. When application is running in compatibility mode, read / write operations from / to system folders are redirected to "safe" directories located in C:\Users[Current User]\AppData\Local\VirtualStore.
More info on http://www.windowsecurity.com/articles/Protecting-System-Files-UAC-Virtualization-Part1.html.

Guidelines to follow when making your program Active Directory/Terminal Services compatible

Wondering if there's any guidelines that should be followed when writing an application that should work not only on a plain ol' non-networked computer but also on a computer/network that is setup with Active Directory (or some other directory service) and/or Terminal Services? Anything I should look out for, be aware of, etc?
Microsoft has renamed Terminal Services to 'Remote Desktop Services' so searching and looking around MSDN my not be as constructive using the old terminology.
I'd start having a look around Remote Desktop Services Programming Guidelines found here:
http://msdn.microsoft.com/en-us/library/aa383490(VS.85).aspx
On the AD site a starting point would be here:
[http://msdn.microsoft.com/en-us/library/ms682458(VS.85).aspx][2]
The most important things to be aware of:
On a Terminal Server users are not admins, they have no rights to:
Write in Program files folder
Register ActiveX controls
Write into (ini files) in Windows(\System32)
HKLM hive of the registry
Some other points:
- Certain API's like getting the Windows directory will return redirected results (in this case the windows subfolder of the homedrive) UNLESS you mark your executable as Terminal Server aware
- Your application must not rely on settings in HKCU that prevent startup when not present
- Multiple users might use your app concurrently so each user must be able to have their own settings (in HKCU)

Resources