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.
Related
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 have created a custom control for my development team to utilize the CefSharp Chromium Web Browser. I have everything setup and working well. The only problem is having it run for projects that do not directly reference the chrome project in their solution.
I would like to find a way for when a developer drag and drops my custom control into their application, it will automatically copy ALL of the required files from the compiled control to their bin folder.
Currently, it only pulls the handle full directly referenced by the tool, but some are utilized at run time due to limitation of the utility for being able to compile for Any CPU efficiently.
Image of Files
I would like to have all of the files on the left hand side be copied automatically upon using the control from the tool box to the appropriate folder, or at the very least at run time.
Any information or ideas on where to look are greatly appreciated.
I managed to solve the problem, though this feels like back practice.
My issue what using CefSharp and getting all of the x64 and x84 files downloaded where ever require. I ended up adding a zip file of each content and then extracting them at run time as needed.
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'.
I'm going to make a desktop application that will run in the background, meaning no visible window, and I'd like an option called: "Upload Text" to appear when a user right clicks a file.
Can someone point me in the right direction? I also have to make sure that if someone wants to uninstall the program at any point, that the shell modification is also cleanly eliminated.
The app will run Windows XP, Windows Vista and Windows 7. How different are these OS's in handling my shell dilemma?
This is a shell extension. You've tagged this question with the C# tag; you should know that writing shell extensions in a managed language is strongly discouraged:
Unfortunately unmanaged C++ is really
the only way to go here.
Writing in-process shell extensions
in managed code is actually a very
dangerous thing to do because it has
the effect of injecting your managed
code (and the .NET Framework) into
every application on the machine that
has a file open dialog.
The problems occur because only one
version of the .NET Framework can be
loaded in a process at any given time
(other shared components such as java
and msxml have the same property and
thus the same restriction).
If you write your shell extension
using the 2.0 .NET Framework and an
application built with the 1.1 .NET
Framework uses a file open dialog,
your shell extension will fail because
it can not run on an earlier version.
Things can get even worse if your
shell-extension manages to get loaded
in a process before another
applications managed code does: your
extension may force an existing
application onto a different runtime
version than the one it was expecting
and cause it to fail.
Because of these problems we strongly
recomend against using any
single-instance-per-process runtime or
library (such as the .NET Framework,
java, or msxml) in an in-process shell
extension.
That said, people have done it.
Here's a guide to creating shell extensions, using C++.
You could add your app to the SendTo folder.
What about a stand-alone program using SendTo?
Install the exe to "Program Files\mycompany\myprogram" and a shortcut to the exe into the SendTo folder. Then when a user right clicks on a file, selects SendTo, and then selects your program, your exe will be executed by Windows and the full path to the filename will be passed in via argv[1]. If they select n files they will be in argv[1]..argv[n].
If you want your program to be invisible then do not make the default form visible. You could optionally place an icon in the tray so the user could double click on it to see the upload progress. When the upload of argv[1] is complete, process argv[2]...argv[n] if they exists and exit. To cleanly uninstall, remove your program and the shortcut from the SendTo folder.
For my work I need to create a Autorun application for a CD for our client. The problem is all I'm a C# programmer by trade and .NET does not make for the best autoruns since not all computers will have .NET installed on them.
What is a good solution that will work on Win98-Vista computers?
The answer to this question is really one of preference. Technically, anything can be instructed to open as an autorun. The autorun.inf file is simply an instruction file that Windows knows how to read in order to determine what it should do when a CD is inserted. That could be an application (written in any language you choose), a powerpoint presentation, opening a link to a website, etc. As long as you follow the rules of the autorun.inf file:
http://autorun.moonvalley.com/autoruninf.htm
There are many small autorun-utils (some free) that are configurable. I would go for one of those.
http://www.ezau.com/latest/articles/083.shtml
You need two things:
Follow this steps (http://support.microsoft.com/kb/324733 OR http://support.microsoft.com/kb/888469)
When your application is ready (with bootstrapper), you'll have to create a autorun.inf file on CD root path. Search 'autorun.inf create' on your favorite Search Engine.
It is possible using Mono's bundling feature:
"The resulting executable is self contained and does not need the Mono runtime installed to run."
Mono is an Open Source .Net clone and should be able to run most .Net applications. See "Bundles" section here: http://www.mono-project.com/Guide:Running_Mono_Applications
You could use .hta file on CD to launch as splash page, and from there detect if .NET is installed (using COM from HTA file) and then run your custom executable.
.hta files are what Microsoft SQL Server (and most of their others) installation cd uses from memory, easy to make them look very professional (its just html in the background basically)
You can include the runtime with the CD, but you'll have to install it before running your app. You might look into just popping open an html file from the CD.
Otherwise, you can look at writing a small native program that can prompt to install the runtime if it's not there, or run your .NET app if it is.
Try Delphi; it's by far the best way to create native win32 application nowadays.
It creates slick stand-alone .exe files with rich GUI's that don't need any runtime libraries or other annoying dependencies. Works on any windows machine.
There was a program from Macrovision called "Demoshield" that worked well back in the day. I'm not sure if its available anymore, but it was an alright program for creating the auto-run programs.