I recently cleaned up my Windows 7 64-bit PC, and after it ABCpdf8 started giving me an error, when I try to export HTML to PDF.
The error is "Failed to initiate IE compatibility mode: Failed to load all required assemblies."
at WebSupergoo.ABCpdf8.Internal.IECompatibility.Activate()
at line
theID = theDoc.AddImageUrl(input.Text);
of the test application, and I have no idea why, because I did not remove any assemblies from my machine.
If I run the compiled application on another workstation with the same config (Windows 7 64-bit), it works fine. Dependency Walker images showed no difference in DLLs sets from my machine and from another.
How else can I identify the source of the problem?
It is definitely neither a missing DLL, nor the user access to the system folders, because, I checked user rights as well, they're identical on both machines.
I assume that it might be a corrupted registry entry. Is there any way to quickly check the assumption?
It has to be said that, ABCpdf comes as third-party tool within another software, so I cannot contact support directly, but through the main vendor.
I had a similar problem with different behavior on w7 and ws2008, which was solved by using the Gecko engine
doc.HtmlOptions.Engine = EngineType.Gecko;
Note that websupergoo recommends using Gecko rather than IE9 as parts of the IE API it uses have been deprecated. (item 6.29)
When you 'cleaned' your system you may have erased the license key from the registry. Try re-installing your 'other software'.
Related
I'm working on a MacOS application built in Unity3D. I'm using a native file browser plugin to open native MacOS file dialogs for selecting files.
In order to generate PDFs, my app relies on using Chromium's Headless/command line functionality.
On Windows, I can easily get the path to the included Microsoft Edge as that's standard, but on Mac, unless I guess and check (which I already do), there isn't a way to guarantee a Mac user has a Chromium-based browser installed.
So I intend on allowing the user to set the path manually by selecting the .app file with a file dialog. But even when I specify .app to be a valid extension, they still don't appear selectable.
I assume this is some sort of MacOS-specific limitation or default permissions, though I can't find much info on this online.
Using C#/DotNet s there any way of allowing this behavior as needed?
For some more info: I'm just running the application using System.Diagnostics.Process.Start() with command line arguments.
Based on my experiments searching for Google Chrome (though Edge or Opera are just as usable), the path I'm looking for is:
/Applications/ {{APP NAME}}.app/Contents/MacOS/{{APP NAME}}
Because Contents isn't accessible by most users, I figured I would just automatically go in and grab the binary with the correct name.
I know I could include some lightweight version of ChromeDriver with my app, but I'd rather keep everything as self-contained as possible, especially as so many people already have Chrome (or Opera, Edge, etc) installed. The challenge is that not everyone has it installed in the same place, hence my need to make it customizable.
Any ideas or help would be appreciated!
Thanks!
After doing some testing: It seems that this limitation is only when running inside the Unity Editor. Once the app is built into a standalone Mac application, the file dialog does allow the selection of .app files and it works as expected.
Not a 100% solution to this problem, but definitely clears up some concerns.
I was hoping for maybe some suggestions on how to get selenium working in following case. I am trying to implement smooth update of chromedriver with limited permissions on environment.
The problem occurs when Google Chrome is upgraded by third party to a newer version and the chromedriver stays the old version. The real problem is because the new version of application requires a new build, new documentation ... etc.
During development I run VS as admin, so no problem when downloading chromedriver.exe. Also normal user can execute it since it is already downloaded.
I tried different ways:
Embed driver into dll, extract it when needed, delete it when not needed any more. The problem is I don't have sufficient permissions to extract or create. I need admin privileges but I don't have it.
Load driver from local/remote location. Here is the problem that the program (chromedriver.exe) is blocked by a group policy.
Loading driver using DriverManager. Since VS is run as Admin, chrome driver detects version and download it beside application. It stop working when applicaiton is not runned as Admin. I tried to download it into users Downloads folder but it is blocked by a group policy.
There is another idea which I am not sure if it is possible. Emmbed chromedriver.exe as Resource in dll and call it. Here is the problem that I need a path for Constructor (ChromeDriver), but I don't have it since it is packed in dll. The idea is when browser is upgraded, new dll is built with new chrome driver and added as dll beside "first" application.
The question is: is it possible to implement the 4th idea or do you maybe have another idea/example?
I've got an application written with C# which is installed via InnoSetup.
With enabled Controlled Folder Access of Windows 10's Defender, the setup fails to create a desktop icon (showing the message PersistFile::Save failed, code 0x80070002) -- despite running with administrative privileges.
Furthermore the installed application (which is NOT run with administrative privileges) fails to write to folders of the user, e.g. Documents.
This happens even for new files or folders, which do not overwrite anything existing. For ransomware protection I'd expect that only modifying existing files is considered dangerous.
The first question that comes to my mind is: Why is my application considered to be harmful and is thus being blocked?
I've done extensive research to get an answer, but could not find anything that helps:
Web resources from Mircosoft describing which applications are considered harmful and why cannot be found -- only guesswork there.
Signing my application with an Extended Validation Certificate (which helps suppressing SmartScreen warnings) does not change Windows Defender's behavior.
I let the Windows App Certification Kit analyze the installer -- which reported several warnings and one critical error. I fixed all issues the Kit complained about (except the warning regarding /SAFESEH which is not possible with InnoSetup), but this did not change Windows Defender's behavior regarding access blocking.
So, my refined question is: How can I bypass the access blocking of Windows Defender for my setup and my application in a valid way?
To give insights to the problem and to provide a basis for experiments I've set up a small sample application in C# which
creates new (and afterwards removes) directories in the public desktop path, user's desktop path, pulic documents path and user's documents path
is bundled by an InnoSetup script to a signed installer
Using Visual Studio to build the solution and InnoSetup to package the build, it should be easy to reproduce the behavior with enabled Controlled Folder Access. (Make sure to have a look at README.md for a description of the build steps!)
Please check out the sample project.
I selected the BarTender from Com tab on preferences screen and add BarTender into my project.
when I execute the project with Ctrl+F5 on my local computer I can print the barcode smoothly.
But when I publish my project under wwwroot I get an error as follows,
Also I set the project platform “ x86 – x64 Any Cpu” but nothing was changed.
PS: I am giving the screenshots as links because of I have not enough points. Sorry for this
It's an EXE server, so it looks like you need to give Local Launch and Local Activation permissions to the COM Class for the identity that your web site is running under. You can do this with DCOMCnfg.exe. Have a look at the Application Pool identity and make sure it has the appropriate rights. A good way to test the problem is to set it to "EVERYONE". If that works then it's definately your problem, but DO NOT leave it set to "EVERYONE". Once you've proven this is the issue, you'll need to set the activation, launch and probably access permissions correctly.
This is due to the security settings on the library itself. I had the same issues with Excel & Illustrator COM's.
Even though this is Excel, this site will guide you through setting the security and permissions.
UPDATE:
If you can't find the library then it may be a 32 bit one; these don't always show up in 64 bit console (assuming you're running 64 bit..) - if so, you need to launch the 32 bit DCOMCONFIG. See bottom of the page here on how to launch 32 bit version.
I have installed on a 32bit server a IBM Rational ClearQuest and made a process which uses the api that they provide.
And there works perfectly.
When I migrate this to another server (64bit) it throws
Retrieving the COM class factory for component
with CLSID {94773112-72E8-11D0-A42E-00A024DED613}
failed due to the following error: 80040154.
I went to the registry to see what was there, (in both servers) and in the first one, there were some keys regarding where this API dll is placed that in the 64bit server weren't. (Also there were a key about the framework)
I did a research on the web to see this.
My options then (at least the only ones I could think of) where:
Uninstall CQ and Reinstall it (Which I did and after some installation and uninstallation crashes of the product It was back up without any changes to my actual problem)
Register the dlls I needed with regsrv32 (didn't work)
Add the keys myself (also didn't work)
I've seen today this cscript, here using Windows Script Host but it does not work with c#.
Supposely c# .Net2008 when the compiler says "Any" machine it clearly means both... but just in case I've changed it to 64bit exclusively...
And guess what... yes you are right... that didn't work also.
I hope you can help me.
Thanks in advance.-
Edit:
InstallUtil on C:\Windows\Microsoft.Net\v2.050727\ on the base dll didn't work
asp_regiis (Which I've tried just in case) didn't work
The fact that you couldn't find the registry key is of course the source of the problem. You are likely to find it back in HKLM\Software\Wow6432Node\Classes\CLSID, the home for 32-bit COM servers. Assuming they are properly installed.
Which means that you cannot allow the jitter to generate 64-bit code. A 64-bit process cannot execute any 32-bit code. Project + Properties, Build tab, Platform target = x86 is the simple fix.
The problem was Windows Server 2008 UAT Protection
Searching on the web I've found that when I've tried to do a registration it was throwing error 5 Access Denied
This is the solution
Go to Control Panel --> User Accounts --> "Tune User Account Control on or off". Turn off "Use User Account Control (UAC) to help protect your computer", and restart the computer. Run "the process with the API" again and it worked.