In the Windows Event Log, there are "Event Message Files" that contain templates for the logged messages.
The paths of the templates are stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog and documented on this page: https://learn.microsoft.com/en-us/windows/desktop/EventLog/message-files.
According to the docs and most of the registry keys, the message files should be DLLs. However, some of them seem to be EXEs. e.g. ...\EventLog\Application\Wininit lists an EXE for its EventMessageFile. A few others do the same thing.
Can I use an EXE (e.g. the one that writes to the log) as a MessageFile as well? Do I need to take any extra steps to make it usable?
Related
Here is what I am dealing with. I have a WIX project, that outputs a MSI file. This works like a charm.
I got a new requirement, that I need to analyse in order to figure out how to approach it. As the new requirement is, I need to get as output, a ZIP file, that contains the files and folders as described in the WIX project...
I searched for the "ZIP" keyword on the official documentation, but did not have any luck in finding something helpful...Maybe some of you guys have an idea?
Obviously, I could use other tools to perform this, like maven and the maven assembly plugin, but that would cause maintenance issues, as there would be 2 different projects, 2 different technologies, and since the files and directories structure is quite big, this could cause issues like one developer modifying a project, and forgetting about the other..
So yeah...difficult question...any input would be welcomed :)
Thx
Administrative Installation: Windows Installer / MSI features a built-in capability to extract all files and make a "network installation point" (a network location where installation can be kicked off from to install on all workstations on the network - ensures all source files are available for repair operations and patching). This is called an administrative installation - in plain terms a glorified file extraction mechanism.
Given the availability of the administrative installation, is a ZIP file really necessary? I suppose you could zip up the extracted admin image? Note that any files that need to go to system, shared or userprofile folders may cause issues and prevent successful launching of your application from the extraction folder (obvious, just mentioning).
Command Line: Try it, from a cmd.exe command prompt (see above link for more details):
msiexec.exe /a MySetup.msi
You could set the Compressed="no" attribute of the Package element to create an uncompressed layout. The result could be easily zipped (excluding the *.msi file) by running any of the freely available command-line zippers (e. g. 7za.exe of 7-zip).
Note:
File elements can override the Compressed attribute of the package.
I am working on a application built in VB.Net that allows a document to be uploaded and saved into a database. I did not build this application, but I do maintain it, put enhancements in it here and there. The target framework is .Net4
One of the functionalities within this process when uploading and saving the document it uses the method File.Open() to access the file and run other methods to compress it. The method that uses File.Open takes in a parameter that passes just the filename, not the entire path of where it came from.
When this application is running on an x64 machine I receive an error (System.IO.FileNotFoundException) when the code hits the File.Open method, complaining that it cannot find the file to open. It is expecting the file to be in the programs executing directory, which does make sense because it is only given the filename to go off, not the entire directory that it came from.
What's getting to me, is that this exact same application (exact same built assemblies) will run fine when run on an x86 system. It does not fail on File.Open() It still passes just the filename, but somehow, it will know the directory information.
How is this possible?
It's worth noting, that the method that contains the File.Open() method is in a different project in the same solution. It's a referenced DLL. e.g. MyApp.exe (Windows Form Application) references MyUtil.dll (Class Library). I have built against x86, x64 and AnyCPU configurations.
I understand that the fix to this would be to just pass the entire directory to the method, but what I need to know is how this is even possible? I want to better understand why this would happen, and hopefully this would help someone else better understand how assemblies may differ between different system environments.
EDIT: Using an absolute path did fix the underlying issue. See the comments below for some good information on this scenario
Windows has special handling for certain folder names on 64bit systems depending on whether you have a 32bit or 64bit process. Notably, the Program Files folder and the System32 folders map differently depending on what kind of process you have.
Note that this is a difference in Windows itself. It's not a behavior that is unique to .Net or Visual Basic. Any program platform that uses Windows native file handling will give you these results.
This is why you should use appropriate relative paths or the SpecialFolders enumeration, rather than hard-coding full path names, and be careful about where you put things you expect to reference later; you might find they end up in a different location than you expected. Often, the AppData or ProgramData folders are the more correct location, instead of the Windows or Program Files folders.
My .exe contain a lot dlls added through reference or as .CreateObject .
I wonder is there any way when i open some dll to find in processes or somewhere else which .dll is currently in use
Just use Process Explorer from sysinternals by truning on View->Lower Pane View->DLLs (Ctrl+D) and then clicking on your application process in processes list.
With Find->Find Handle or DLL (Ctrl+F) you can search for DLLs and other files being open by any system process, e.g. when you need to delete a data files but the OS refuses for file being in use reason and not telling you which one the culprit is.
I would like to run a custom action on a dll during my installation process.
There is no clean description that I found. So how would you implement this command:
regsvr32.exe /c /n /i:"[PathToIncFolder]" "[BIN]MyFile.dll"
in Wix during the Installation or maybe degister during uninstall?
Preferrably not. The recommended way to install COM components nowadays is to manually add the registry entries.
You definitely should be performing manual registration of the keys and values needed to install the COM component. The reason self-registration is frowned upon is because of problems concerning rollback and uninstall.
The OLE/COM specification should give you information on what keys need to be registered but at a minimum you will need to add a set of entries to a new subkey at HKCR\CLSID\.
Inside this subkey you will need at a minimum, the path to the component and the threading model.
Depending on what your COM component does you may also need to register a PROGID, file-extension maps and APPID.
If the COM object is a managed assembly then your task is slightly different as you need to refer to the .NET bootstrap assembly instead of your own.
If your COM object is written in ATL then your project probably contains a .rgs file which contains all the registry information you'll need.
For further information on COM registry entries check the MSDN here.
While creating the setup for VB.net application I am getting the following warning:
"Warning 1 'msado15.dll' should be excluded because its source file 'C:\Program Files\Common Files\System\ado\msado15.dll" is under Windows System File Protection.
Please suggest me how to over come this type of issue.
Thanks,
This is a classic case of IDE components not talking to each other.
One component says "you reference msado15.dll in your code, therefore I should include it in the project".
An unrelated component says "msado15.dll is on my list of protected DLLs, therefore I should warn you not to include it".
However, no component thinks like a human and says "hang on, this DLL is part of the framework, therefore I should silently remove it from the installer".
It's up to you to do the last part yourself.
That means that file is normally already on the operating system, so it should not be necessary to install it. If you remove the user's original protected file in your app uninstall, it can cause problems on the user machine.