How can I consume a registration free COM object without copying the dll to the same directory as the executable? Is this possible?
I would like a complete working sample or a detailed step-by-step guide for my exact scenario.
For example, I have the following components:
CppTestRunner.exe - vc++ console application
CppTests.dll - vc++ mfc dll
CsCOMServer.dll - c# COM visible dll
I do not want to modify the exe or its directory, like adding an external manifest.
CppTests.dll is in a different directory than the exe.
It is okay if CsCOMServer.dll is in the same directory as CppTests.dll.
CppTestRunner.exe calls LoadLibrary on CppTests.dll which works fine.
After embedding manifests and using the windows activation context apis, I was able to copy CsCOMServer.dll to the exe directory to verify that CppTests.dll can create an instance of CsCOMServer.dll without issues, but again, I am trying to avoid this step.
Currently, with CsCOMServer.dll in the same directory as CppTests.dll, and without CsCOMServer.dll in the exe directory, I am getting the following error when I call CoCreateInstance:
Error = 0x80070002 The system cannot find the file specified.
I have used sysinternals process monitor to track down the paths CppTestRunner.exe looks in, etc.
I notice that depending on the things I try to do, sometimes CppTestRunner.exe tries to read CsCOMServer.dll.config in the same directory as CppTests.dll, but no matter what I try to put in there, I was not able to get past the error.
Also depending on other things I try to do, CppTestRunner.exe tries to read CsCOMServer.dll in the same directory as CppTests.dll but for some reason, I still get the same error.
Anyone know of working code with this exact scenario?
As you can probably tell, this is part of some unit\integration tests.
As a simple workaround, I am currently copying CppTestRunner.exe to the same directory as CppTests.dll and running it from there, but would like to avoid this step.
Thank you.
.NET looks for managed registration-free COM first in the GAC, then in the executable's folder. It uses the activation context to read activation metadata, but not to determine the location of the files themselves.
You can save the DLL in a sub Folder, let say DLLFolder\YourDll.dll, and in the manifest file of yourDll, write the filename like
<file name = "DLLFolder\YourDll.dll">
But you need to keep the manifest file (of the DLL) in the location where the EXE is saved.
Related
We want to hot reload a DLL. The first idea was to overwrite the .dll file then reload it from the application. However the file is write protected.
Is there a (documented) counter-argument to not remove this file protection and overwrite the file?
If no such counter-argument exist how do we bypass this protection?
EDIT: References found on internet point out mmap and the fact that the DLL may not have been loaded. In my case, the (only exported) method has been called so I can reasonably think that the DLL has been fully loaded.
In our situation we have a program that loaded and use a DLL.
An edit in the source code of this DLL is made, we need to recompile it and have it hot-reloaded by the program. The problem is the DLL is locked against write.
We have another program that watch for any modification on the source file (this is actually a custom script Compiler) and need to compile a DLL (by translating the source script into c++ code and invoking clang).
The solution we have for some month now (and is working pretty well), is to have our Script Compiler to check if the file is protected against write, if so it rename this dll with a temporary name and finally compile.
The Main program catch the change on this dll and is able to reload it.
Extra step At the startup of the compiler, we check if there is any temp dll and try to removed them. If the deletion fails it's probably because the DLL is in use, we ignore it.
Note: We need to move the .dll and .pdb to a temporary file. We delete the .exp, .ilk, and .lib just in case of.
I am trying to use dll files from OpenCV. To locate the dll files, instead of copying the dll file in a post-build event, a guy on YouTube did the same thing by going to System-> System Variables -> Edit Path -> Add YourLocationToDLLFile.
My code runs fine by editing my Path variable. I do not understand how editing the Path variable gives me the same result as copying the dll file in a post-build event.
I presume, since OpenCV is C++, your application is also unmanaged. In this case you should consult this article.
PATH directories are used as the last resort for DLL searcher to try locating the requested DLL. That's why it works for you.
Mind you, this is, obviously, good only for your local development, when you deploy your application, make sure it is properly packed with all the necessary dependencies, including OpenCV.
This may sound like I'm just looking for a .exe file, but I'm not all that familiar with windows. I have been using pyinstaller to turn my apps into binaries. My app relies on a lot data directories and third party binaries that I package within the same directory as the executable binary. For Mac, this makes things easy because the user only has to click on MyApp.app inside the applications directory which is like a link to MyApp.app/Contents/MacOs/MyApp. This way MyApp never has to be touched and is all bundled together with the data directories (also loaded inside of MyApp.app/Contents/MacOs/).
However, I can't really find a windows equivalent. While Pyinstaller can create a directory with my data directories and executable inside of it, if the user ever moves the .exe file inside the directory, the app will never work (because it loses its relative location to the data directories). Is there such a thing that can package this directory like on MacOS so the user just has to click on a single .exe file that links to the .exe inside the directory packaged within it? That way we can just pass around one directory. Like a Mac.app?
Win32 apps store data within the executable file as resources, which allows the single file solution, but they can't be accessed using normal file APIs, there are a separate set of functions for resource handling. (This implies that resources aren't so useful for things that absolutely have to be files, like images of helper executables.)
Win32 also has alternate data streams, which are more similar to what you're used to with .app packages, separating a local identifier from the actual filename by $DATA:. But those only work on NTFS, get lost by many file management applications, never have been very popular, and are now effectively deprecated by Microsoft (by preventing access from Windows Store apps).
I am creating a WIX installer project. During one managed customized action, I need to create a file (other than the deployed files specified in the components of WIX) in the installation folder, which by default is the Program Files folder. I am experiencing the "Access denied" problem in Windows 7. After some searching, I found out that people say it is not advisable to create files into Program Files folder. Instead, try to create files into for example AppData folder. For example, see this link:
C# Access denied to path in a Windows Application
But my question is, the generated file is crucial to our SW, so it must reside in the installation folder. Isn't it the target of SW installation, I mean, to create file in most of the cases Program Files folder? Does it mean the only files should be added into installation folder, during the installation, are the deployed files (basically the targets of XCopy)?
My file can't be made deploy-able in the WIX, i.e, it can't be made ready before the installation. So what's the proper way or best practice to handle such situation: a file must be generated during the installation, into the installation folder. It is not some log file that I can put somewhere else. I tried to create a Permission element in WIX for the INSTALLADIR, although it seems to be against the rule mentioned in the link, but it still failed. Thanks!
UPDATE:
Based one MichaelUrman's commen, some more information. The generated file is needed after the SW is installed and necessary during normal launch of the SW. And I think it needs to be modified during normal use after the installation. And as I mentioned my a comment to #caveman_dick answer, my CA is actually in commit phase, I don't know whether there is any difference between it and normal deferred CA
Set the custom action to Execute="deferred", that will run the command elevated and should give it the required permissions to create the file.
Since you need to update that file from the main application, and I'm assuming your application does not require elevated privileges, you have three options.
The first is the worst: without a manifest, your executable's attempts to write to the Program Files folder will typically result in it being redirected to the Virtual Store (see File Virtualization). It sounds like this isn't happening in your case, so you can't use it.
The second option is to modify the application to store this in an appropriate location such as the ProgramData folder, or Common Documents, or (if appropriate) a per-user location under LocalAppData. This is typically the best approach, but has the highest development costs.
Finally the third option is to create the file and change its permissions (or in some cases to change the permissions on the folder containing the file), allowing limited users to modify this file. See LockPermissions or MsiLockPermissionsEx for the Windows Installer way to approach this. Change the permissions on as few files or folders, as restricted as possible, to keep the system as safe as possible if you go with this option.
I want to put my dependent files in the app directory.
I seem to remember that you can force VB6 to use the files in the local directory only.
Any hints?
You may also want to try setting up Reg-Free COM for your project. There's a freeware called Unattended Make My Manifest that will do most of the work for you.
Placing component libraries in the EXE folder (with or without .local files) can be deleterious to the hygiene of target machines too.
VB6 programs will register the components here via the self-reg entrypoint behind your back if they are not previously registered. Then if the application is moved or removed you leave the user with a broken reigistration - possibly fatal to subsequently installed applications using some of the same components. This is probably fine though for application specific components, i.e. your own DLL or OCX that will never be needed by another application.
The .local trick was really not meant for use with VB6 programs and if it is used your installer needs to be aware and properly install and register the components if they are not already on the machine. It was meant as a manual hack to get around DLL version compatibility problems on individual machines, not a deployment strategy.
Move up to SxS application and assembly manifests (Reg-Free COM and more) for a better solution. DLL/COM Redirection (.local) was a good try but it has many warts.
Clay Nichol's answer about the search order is not quite correct. That search order only applies to non-COM components. I.e. only some DLLs, and not OCXs. If you register your COM objects, they will be used from the directory where they are registered regardless of what's in the local directory, unless you use reg-free COM or a .local file.
EDIT:
MakeMyManifest is well spoken of as an automatic tool for creating manifests for VB6 projects, haven't tried it myself.
DirectCOM also has fans, again I haven't tried it.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
There is a semi-automatic technique to generate reg-free COM manifests. You can create the manifests with Visual Studio 2008 (you can use a free version like Visual Basic Express Edition). Then make a couple of edits by hand to make the manifests suitable for use from VB6. See this section of this MSDN article for step-by-step instructions - ignore the rest of the article which is about ClickOnce.
It can be sort of confusing because every version of windows, the rules change. Older versions of Windows search the path before the current directory.
A simple solution without manifests:
If your executable file is A.EXE, add a (0-byte, empty) file in the same directory named A.EXE.local -- for older versions of Windows this puts the app directory ahead of the path in the search order.
Found it myself:
Windows does look in the App Directory first:
If SafeDllSearchMode is enabled, the search order is as follows:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
If SafeDllSearchMode is disabled, the search order is as follows:
1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
according to : http://msdn.microsoft.com/en-us/library/ms682586.aspx
But you can redirect where it looks for .dll's using a Manifest:
http://msdn.microsoft.com/en-us/library/aa375365(VS.85).aspx