We Keep Coding

Registration-free COM and DLL location

My C++ app was required to communicate with a web application. Since writing in C++ was hard I wrote the web application client in C# (DLL), COM enabled it, and called it from C++ app and it worked.
But the C++ app can be installed on a server PC, its folder shared over a network, mapped to a drive on a client PC, and run from there. When I tried running so, it doesn't run because it is expecting the C# DLL to be registered on the client PC. I would like to avoid it. I would like to keep them both on the server. Is it possible to do it using registration-free COM? If yes, can the C# DLL (and its dependent DLLs) be placed in a folder different to the C++ EXE folder?

I see this is an outdated post. Hope you had found out a solution or a workaround. Anyhow, I shall answer as it may help someone with the same problem.
Is it possible to do it using registration-free COM?
Yes, it is. Follow this MSDN article. You will have to create a manifest for the c# com dll and embed the manifest into it. Which would be with the help of a RT_MANIFEST resource. That article is a little outdated, so you may face problem with .net framework version. If you did, you will need to specify the .net framework version in your machine. You can simply replace the clrclass line with this :
<clrClass
clsid="{16AD5303-E154-44B4-A72B-C129859714AD}"
progid="SideBySide.SideBySide"
threadingModel="Both"
name="SideBySide.SideBySideClass"
runtimeVersion="v4.0.30319" >
can the C# DLL (and its dependent DLLs) be placed in a folder
different to the C++ EXE folder?
Yes, it can be. But I wouldn't recommend it. According to this resource, the assembly loader searches for assembly manifests in the following order :
Side-by-side searches the WinSxS folder.
\\<appdir>\<assemblyname>.DLL
\\<appdir>\<assemblyname>.manifest
\\<appdir>\<assemblyname>\<assemblyname>.DLL
\\<appdir>\<assemblyname>\<assemblyname>.manifest
The above locations are respective to the application (appdir). If you want your dll to be elsewhere, then you can use the file element of the assembly manifest (the name attribute can include a path), see here for more details and other elements.
Hope this helps someone.

How to bundle a required DLL with a solution in Visual C# (Express, 2010)

I have an application written in C# which interfaces with some custom hardware using a vendor supplied .Net assembly. The .Net assembly in turn loads another DLL at run time. I can add the vendor supplied assembly to my project but when I run it, the vendor assembly complains that it can't load the required DLL. I can work around this for the moment by copying the DLL to the bin\Debug and bin\Release folder.
The problem is that I will need to distribute this application to clients at some point and they will not have this DLL in place. I can't see how I can make the solution require it; I can't add it as a reference since I get the error "A reference to foo.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."
I can't convert the DLL to a .Net assembly using TlbExp, it gives an error "The module was expected to contain an assembly manifest."
I thought if I published the application via "click once" that I could declare the dependency there but I don't see any way for this either. I also tried adding it as a file resource but this didn't seem to help.
I can see other questions on SO relating to how to invoke functionality in an external DLL but in this case, I just need a way to bundle the DLL with the project.
Thanks.

Indicates that the attributed method is exposed by an unmanaged dynamic-link library (DLL)
The DllImportAttribute attribute provides the information needed to call a function exported from an unmanaged DLL. As a minimum requirement, you must supply the name of the DLL containing the entry point.
For further reference go here
Link to Review

You could add the dll as a resource, write it out as a byte[] to a file on loading, and do an Assembly.Load() at runtime for deployment.
You might have to use an AppDomain.AssemblyResolve Event to make sure the assembly resolves in case of multiple versions.

you could add both (all) of the dlls in your project as references and mark them as "copy local". That should do it unless the first DLL expects the second DLL in a specific place.

Converting from framework 3.5 to 4 app.config location

I had a project whose framework is 3.5 and i converted it to 4 and when i faced a problem of mixed mode. i changed the useLegacyV2RuntimeActivationPolicy from this answer
Now when i install my application to program files and try to run it, it crashes but when i place the config file beside my exe it runs.
Can anyone tell my the reason of that crash?

but when it was 3.5 i didn't need to place the app.config file beside the exe
That was required in 3.5 as well. It is the only way that the CLR can find the .config file. I'd have to guess that you somehow got away with it before and it just didn't matter. But now it is critical to let the CLR find the .config file since you really need that attribute to allow the mixed-mode assembly to load.
An obvious way ahead is to rebuild the C++/CLI assembly and have it target v4 as well. So you won't need the .config file anymore. If it is not yours then ask the vendor or author of the assembly for an update.

DllNotFoundException for .dll which is in current folder

I'm getting a System.DllNotFoundException for a .dll which is in the same folder as the executable whenever my application attempts to use a function which exists in the DLL. The weird thing is that it is only occurring on one user's PC; it works fine on my dev PC and it works fine on one non-dev PC that I tried it on. Also, there are other DLLs in the folder which are being found and used correctly. The DLL in question is a native library which is referenced by my application via another DLL which is a c# wrapper for the native library.
My initial instinct is that there must be some other library being referenced by this DLL which doesn't exist on the problematic PC, but I cannot imagine what library this PC could be missing that the other non-dev PC has.
So my questions are this: is there a way to determine the dependencies of a given DLL file? Keep in mind that the DLL in question is a native library (i.e. not managed code), and I do not have access to it's source code. And if it turns out no dependency is missing, what else might cause such an issue?

For unmanaged dlls you can use Dependency Walker to find dependencies.

I would suggest using ILSpy to open the dll and view its dependencies first.

c# dll not found

I am writing a small AOL IM application in C#. I have all the dlls that I need and I have been able to compile and run my app. However, when it runs I get an error that says
"Unable to load DLL 'acccore.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"
I understand that this means the acccore.dll file couldn't be found but I don't know why. I tried putting it in C:\Windows\System32 and it is also in the debug directory that is created when the project is build in Visual Studio. Can anyone tell me how to make my application know where this dll is located?
Thanks!

I did some research and it looks like acccore.dll is a COM DLL file. That means you need to run:
regsvr32.exe C:\Windows\System32\acccore.dll
This will register the COM DLL into the registry, you can then use that DLL in your .NET code. Check out the link:
http://64.12.130.129/forum?c=showthread&ThreadID=1173
So you will need to use P/Invoke to use the DLL (I guess the AOL SDK has some example code you can use).

is this dll an assembly?
If so then fuslogvw will show you where the CLR is looking for assemblies. Put it where .net is looking

.NET assemblies need to be in the directory of the application (or one of its subdirectories, especially if they represent a localized version of a different assembly), or in the GAC (global assembly cache.) If the DLL isn't in the same directory as the .EXE, then that's your problem. If it is and it still doesn't work, it means that the assembly doesn't match for some reason.

I used dependancywalker to find the dll I was missing that caused it to error. This was suggested by Taylor Leese in a comment.