I have to write an IE11 addon and I found some good sources for start but I always got stuck in the compatibile issue. Turning off of EPM is not allowed and we tried to enabled our prototype addon in GP (Using the CLSID and Administrative Templates to manage group policy objects) but the situation is the same.
I would like to know how I can write a compatible addon because I found nothing about it. What makes an addon compatible?
Which version is your addon is? 32-bit or 64-bit? EPM only allows 64-bit addons to run, so you need to generate a 64-bit version of addon if you want to use it in EPM. For more information, you can refer to this thread.
Besides, Enhanced Protected Mode isolates untrusted web content in a restricted environment that's known as an AppContainer. This process limits how much access malware, spyware, or other potentially harmful code has to your system. So you need to place your addon's DLL with an AppContainer-readable folder (e.g. a subfolder of the \Program Files\ folder). For more information, you can refer to this thread and this doc.
Related
We use Redemption Version 5.21 initializing with RedemptionLoader and 32Bit Outlook.
This works perfect on most systems.
Problems occur on Systems, where a third Software is installed, which is using a customized Redemption.dll together with some Registry-Entries by the setup.
[HKEY_CLASSES_ROOT\TypeLib\{2D5E2D34-BED5-4B9F-9793-A31E26E6806E}]
[HKEY_CLASSES_ROOT\TypeLib\{2D5E2D34-BED5-4B9F-9793-A31E26E6806E}\4.5]
#="Redemption Outlook Library. Version 4.5"
[HKEY_CLASSES_ROOT\TypeLib\{2D5E2D34-BED5-4B9F-9793-A31E26E6806E}\4.5\0]
[HKEY_CLASSES_ROOT\TypeLib\{2D5E2D34-BED5-4B9F-9793-A31E26E6806E}\4.5\0\win32]
#="C:\\Program Files (x86)\\...FullFilePathToCustom_dll
[HKEY_CLASSES_ROOT\TypeLib\{2D5E2D34-BED5-4B9F-9793-A31E26E6806E}\4.5\FLAGS]
#="0"
[HKEY_CLASSES_ROOT\TypeLib\{2D5E2D34-BED5-4B9F-9793-A31E26E6806E}\4.5\HELPDIR]
#="C:\\Program Files (x86)\\...DirectoryPath"
When deleting the identified Registry-Keys everything works fine.
With this third-Party software installed there are Problems accessing
attachment.ContentID from singed E-Mails
and also with
decryptedmail = ((IRDOEncryptedMessage)mail).GetDecryptedMessage();
Conclusion:
Third party-Software adds something to registry, that disturbs the RedemptionLoader Initialisation Process. RedemptionLoader Initialisation is not so isolated from System as expected. Running our software independent from third-Party-Installation is a requirement.
Questions:
How get rid of the fact, that third party Installations of redemption influence stability?
Is this possible with the RedemptionLoader-Approach?
Can loading side by side be a solution?
I have a question about the rules organizing resources into components.
What I want to do is the following; There are two files (both 64bit) with the same filename but in different source locations and with different component GUID's;
C:\data\win7\driver.sys
C:\data\win10\driver.sys
I want both included in the installer and when the installer runs decide depending on the OS which of these two files will be installed in the same location:
C:\Program Files\MyProgram\driver.sys
Is this a violation of the rules regarding the components? (the main one applying would be the first one I would say:)
"Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies."
https://learn.microsoft.com/en-us/windows/desktop/Msi/organizing-applications-into-components
Actual Answer: Yes, installing different files to the same absolute path is indeed a violation of the MSI component rules - in
theory. As you have discovered reading the documentation. However,
seeing as only one file will make it onto the box, it is all semantics
really, there will never be two files installed. Still, the MSI will
probably not validate - you will see validation errors.
I am not sure of the technical implications, but could you make the
file name different based on OS? Then you simply put the files in
separate components and use different component GUIDs and condition
the component for installation or not. Full compliance instantly.
With all that said, it seems driver files are to be installed using
INF-files in standalone packages in the future. Please read below.
Component Rules, Pragmatically: This is a well-known problem indeed. I have this old answer that might be helpful: Change my component GUID in wix? It describes how the component rules work in practice, and how the idea is that you reference count an absolute path, and not a file per-se. Please read it to make it clearer. More links in this answer.
Driver Installation: We are supposed to know how to do this, but the rules keep changing (and another answer). Essentially drivers are to be distributed via Windows Update, or at least via a standalone package without the need for an installer in the future (until Microsoft change their mind again?). Windows Hardware Dev Center dashboard. As far as I understand the installation is INF-based (as before).
Question: Are you sure about that installation location? What does the documentation say? I thought sys files should go primarily to the Windows folder? Or the WinSxS folders (side-by-side win32 assemblies). As you understand driver installations confuse us all.
Windows 10 Detection: It appears to be a challenge to detect Windows 10 due to the new "evergreen versionlessness" of Microsoft. I have this old answer written up to summarize my current understanding of it: Windows 10 not detecting on installshield. Deployment tools such as Advanced Installer does the job for you and detects Windows 10 with simple measures. Not sure what Installshield does. The linked answer lists a few approaches to detect the version yourself - not sure which is the saner approach. Please read (and also please report any interesting findings when you have a successful package).
We have developed a project with Yii framework on local windows server. It is working with no problem on a local windows server.But when we uploaded the project to a linux hosting it started giving us problems. Not getting where is an issue?
Linux accesses files (and therefore all classes it autoloads) case-sensitively. You may run into problems when your models are called something like Contractperiod and accessing them like ContractPeriod. Rename their files to use the same name as their classes (.php) and any code using those classes to use the right names to fix this kind of issue.
Then there's the permissions; your runtime and assets folders need write access under Linux. Windows needs this as well but usually gets it automatically by being ran under an administrator account (unless you've properly configured your Windows web server). See chmod.
You may experience issues due to different PHP versions as some Linux distributions such as Debian don't have updated PHP versions in their default packages. Another possibility is that your PHP is configured differently on your Linux server; showing errors that are hidden on Windows. Generally these should be solved by repairing the code.
To get a more specific answer (or guess) for your instance you're going to have to provide us with more information, such as a copy of some of the errors.
I read a tutorial on how to do that in LINUX, but it looks like this cant be ported to windows so easily. SALOME gives us a development environment for windows and claims its crossplattform:
http://www.salome-platform.org/downloads/current-version
But the documentation does not specify the module creation process in windows (the documentation is only downloadable so i cant link it). To follow the LINUX tutorial, one has to find and edit several files that are missing in the windows distribution. Mainly these are files that are used in the make process of the linux salome module creation.
I hope anyone has some experience in this field.
SALOME doesn't support Windows currently, as the 3rd parties dependencies.
http://www.salome-platform.org/forum/forum_9/975821878
I have a Windows CE device that we are deploying, but we have complete control of the software installed on it.
This is not a typical Windows Mobile device, this is a headless device that the user will not interact with. I know that on PDA-style WinCE devices, the .cab file is the preferred application distribution method.
However, on a headless device, we will be writing some type of upgrade/patch server that will ping a server for updates, download them, and auto-install when they are available.
Do I still want a .cab file, or is a .zip (or even something else) better?
What are the requirements for a .cab file - what kind of restrictions / requirements might get in the way and be an annoyance? What are the benefits?
I'd stick with CAB as a package since even headless devices can use the CAB extraction tool. If you ZIP it, then you have to add a ZIP support library and app. CAB also has the ability to add registry entries and define far more disparate target locations than a zip (I want x.dll in \Windows but prog.exe in my program folder - try that with a ZIP).
One thing to keep in mind is that wceload (the CAB extractor) uses a UI by default, so you're going to want to use things like the /noui switch for it.
If you're true headless this may not be an issue (not done that in a long while) but a fairly common "headless" configuration has display support and either the display simply isn't hooked up or is something like a NOP VGAFLAT driver. This allows you to run a shell and have access to all the nice shell APIs, but adds to the challenge that GWES will render dialogs onto the non-existent display.
OpenNETCF also has a CAB Installer SDK that you can use to completely remove any UI with by creating your own installer app. This may or may not be useful depending on the how and when the install happens (through HKLM\Init or otehr for example).