poco
poco copied to clipboard
Windows Eventviewer not able to find PocoFoundation DLL
I want to log from my Application to the Windows Event Log.
When i run the Application as an Administrator it creates the Registry Keys under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog
Path. Without Admin Rights the key is not created.
I have placed the PocoFoundation64.dll
inside the System32
Folder but in the Eventlog it still gives me the message:
the description for event id from source cannot be found
I'm using Poco in Version 1.10.1
@obiltschnig I further investigate on that problem. If i make a visual studio build directly from the provided Visual Studio Solution file inside the Poco Foundation Folder and use that created lib and dll File it works. But if i made a CMake Build or use the Conan Package Manager there seems to be two Problems:
- CMake/Conan gives me a
PocoFoundationd.dll
instead of thePocoFoundation64d.dll
which was created by the Visual Studio Solution File. - The
setUpRegistry()
Function in theEventlogChannel.cpp
could not find thedll
because of the Naming missmatch. As shown here:
if (disp == REG_CREATED_NEW_KEY)
{
std::wstring path;
#if defined(POCO_DLL)
#if defined(_DEBUG)
#if defined(_WIN64)
path = findLibrary(L"PocoFoundation64d.dll");
#else
path = findLibrary(L"PocoFoundationd.dll");
#endif
#else
#if defined(_WIN64)
path = findLibrary(L"PocoFoundation64.dll");
#else
path = findLibrary(L"PocoFoundation.dll");
#endif
#endif
#endif
Also manually adding the Registry Keys and pointing them to the PocoFoundationd.dll
does not work.
This is also the same for the Release Build.
Thanks for looking into it. The solution is then probably to pass an additional preprocessor macro when building POCO, indicating that CMake is being used, so that the expected DLL name can be set accordingly.
where should it be placed? so maybe i can fix this and send you a merge request to fix this
Probably add a definition like:
target_compile_definitions(Foundation PUBLIC POCO_CMAKE)
to Foundation/CMakeLists.txt
and then change EventlogChannel.cpp
accordingly.
Okay I will make a merge request hopefully until the end of this week 👍
@obiltschnig is there already a branch for the 1.11.1? Or should i take the master or the devel branch as a base?
@KevDi take master as a base and hold on with pull request until we sort the branches out - master
and devel
need to be re-aligned, and there will be contrib
branch (where your pull should go)
unless there are some critical bugs discovered, the next release will be 1.12.0
@KevDi it's been a while, sorry about that; we're getting ready to release 1.12, so you can send it there, or if you're late for release, you can send to 1.12.1
I've tested this on 1.12.2 and I still think for both win32 and x64 that the message definitions are not found when when looking at log points in EventViewer application. I have confirmed by opening the dll in Visual Studio that they are not part of PocoFoundation dll.
In my case I'm building Poco through cmake using generator for Visual Studio 17 2022. In addition to this I can see that cmake does generate the Message00001.bin file as well as the corresponding rc file. (Basically running mc compiler on pocomsg.mc) The output can be found in the CMAKE_CURRENT_BIN_DIR for PocoFoundation. However the rc file for PocoFoundation doesn't include the generated PocoMsg.rc file. Hence the resulting dll doesn't contain the necessary message definitions and therefor it will not work with having PocoFoundation registered in the registry.
I think it would be good if either the PocoFoundation rc files includes PocoMsg.rc for Win32 or x64 windows target, or that there is a cmake build options which besides generating the pocomsg.rc also performs the resource compile and link into PocoMsg.dll. ( ofc these option would only be valid for windows platform).
# Compile rc file to res file
rc pocomsg.rc
# Link into no entry dll
link -dll -noentry -MACHINE:x64 pocomsg.res
If the above is not an option, then maybe at least a note in the build instructions would be nice, in case somebody else stumbles upon same issue.
This issue is stale because it has been open for 365 days with no activity.
I am interested in a fix for this and an example on it's usage please