We Keep Coding

Using external DLL's in C# COM-DLL project for MS-Access usage

The user's main application is ms-access (with ms-sql server). Ton of code in vba.
One of the main features i have to manifest is controlling my client's voip telephony. My plan is to make a COM DLL that the ms-access can use.
As of now, i've managed to write a C# project (vs2019 .net framework) that handles the voip pbx well, using json, and do all missions necessary, such as invoking calls, sending sms, get calls list, recodings list, get recordings wav files and convert them to mp3. I use Newtopsoft.Json and NAudio.Lame.
BUT it only works as a standalone .net project or exe.
As a COM DLL (class library) - ms-access can handle and use it UNTIL it gets to the part where the code uses ANY external dll's functionality - and it crashes (with newtonsoft) or just not working (with naudio), although the dll's are in the working folder.
I know i have to found a way to make these external dll's to work under the office (32bit) enviroment.
I was trying and guessing many code samples for a couple of days. I tried to follow the Assembly.Load/From/File examples to dynamically load and include the dll's, but i failed to assimilate it in my code or even to understand it enough.
I hope i'll get a solution here.
Thanks :)

Hum, I am able to create a COM object for use with Access. External library code (in my case Newton soft) for serializing data works just fine when that class code is used as a COM object from Access.
You don't mention if the other libraries are managed code, or external win32 .dll? I have however used un-managed .dll’s with a .net COM object, and then have consumed that from MS-access.
The only issue would be in project explorer is to ensure that you have a copy local setting = true for the external referenced .net .dll libraries. (And that is the default, so I am sure you do.
The next issue of course is of course is there any use of configuration files? (app.config) etc.? The reason for this of course that since your application is being launched with msaccess.exe, then the config and settings will be assumed to be in the office install folder, and not the local application. As a result, it not all so practical to move/copy those app.config files to the office folder where msaccess.exe resides. And the config file name will not only have to be in the same folder, but also named.
Msaccess.exe.config.
In place of
YourDotNet.exe.config
Now of course, if you build your project as a .net exec? Well then of course any config settings (application ones, not user) will be placed in this config file, and of course that file will have to be placed in the same folder as the .exe file.
So, one might add a “test” function (any function is a method of that class) to the class that you test/call from VBA to ensure that such settings are being seen and read (if you are using any settings).
Eg:
System.Reflection.Assembly.GetExecutingAssembly().Location + ".config"
So, return that to access and display this result.
The other issue is of course to FORCE your project to x86. I would not use “any” CPU. While this “may” work, since you are using access x32, then I would force compile your .net class to x86 as opposed to “any” CPU. This would also spit out some errors in case some of the external assemble(ies) are compared to a particular bit size and thus x86 settings will result in your class not consuming some of the external .net .dll’s.
Now you “note” that your project works as an .exe, and then “sort of” works as a class and “.dll” registered as a COM.
However, you don’t mention how you are “flipping” this from an .exe to a class, or do you simply have a .net “test” project that you run as an .exe, and it of course has a reference to that class .dll. And you NOT using “COM” for this testing.
If your test.exe program can use that external assembly?
Then I would create a test2 project, but this time around do NOT reference the assembly (as .net), but try using .net CreateObject(). (I think c# has this choice – vb.net certainly does).
So you could try + use a CreateObject() in this .net test sample, and thus test from .net as COM.
So this test .net program (one that has NOT referenced the assembly) would a intermediate test before you jump all the way into ms-access + VBA test code.
However, I would first test/check if an app.config file is being used here, since as noted when you flip to a COM object, and then create a instance of that object in Access/VBA?
Then the config file will NOT be used. You can in .net code force/change the app.config file in that running assembly, and I can’t seem to find my code example that does this. But I am not going to dig too hard until such time we confirm that you are using app.exe.config file here.
Edit
Out of cuirous, I googled naudio. It is managed code. So, that library should work just fine. If that project is compiled as "ANY CPU", you COULD try re-compile as x86, and also re-compile your test program as x86. Then when you create a COM object, then again compile that as x86.
As noted, I do quite a bit of COM stuff for ms-access, and I have without issue used Newtonsoft (for jason serializing/de-serializing) as a COM object that is consumed by ms-access.
And given that naudio is managed code then I don't see why it would be an issue. Any other 3rd party .dll's you using here? As a quick test, I would set all projects to x86. You seem to "mention" that "some" of the COM object works, but just not all.

Could not load an assembly despite it being referenced

I'm looking at incorporating the new Google Apps Script Execution API into an existing C# plugin i have already working. I am following the .NET quickstart guide provided as a console application (which i have gotten working without problem).
When porting the code from that into my plugin it will also fail at runtime at the first instance of:
UserCredential credential;
which I slimmed down the code so far to just that line which fails giving:
"Could not load file or assembly 'Google.Apis.Auth, Version=1.9.2.27817, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab' or one of its dependencies. The system cannot find the file specified."
The file is properly referenced (having installed via nuget).
C# is not my normal field and perhaps i'm missing something in the subtlety of it working in a Console App.
What gives?

There was a time when console apps defaulted to using the client profile rather than the full .Net framework. Check the properties of the project on the Application tab and make sure the target framework doesn't end with Client profile. If that doesn't work try using the fusion log viewer, which you'll find conviently located at C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin, or any number of other places. Run it as an admin and it'll tell you what it can't load (which may or may not be Google.Apis.Auth) and where it looked for the file at.

This has been a little bit of a red herring. Not very well documented is the fact for the app i am building against, Autodesk Navisworks,
plugin dependency libraries have to be duplicated in a separate directory altogether from the plugins directory.
Easily fixed for the build environment, but will need a little more thought for when creating a distributable.

Dynamically un referenc a dll in c# winforms

I have a winform c# app.
I can use a [web method] to check for a version of a DLL that my client winform should use. I can also download it. But, if I copy over the old DLL I will get an error stating that the file is in use. I had expected this.
Is there a way to unload this DLL from my running winform app, copy over the DLL and reload it?
I do not want to use a boot-strapper for my updater and it may come to having to stop and restart my application.
All this will be obsolete if I can just unload my DLL.
I have looked for a long time and cannot find anything. Before I retire on this I thought I would post the question here.
Thanks
PS
I could post the code that shows how to load an DLL in code and the error generated from it but it is open knowledge and does not add to this question.

Is there a way to unload this DLL from my running winform app, copy over the DLL and reload it?
Not in most cases. The only way to unload a DLL in a managed application is to unload the entire AppDomain. This typically means you need to be very careful about how you use the assembly (you can't just directly reference and use it as normal).
I do not want to use a boot-strapper for my updater and it may come to having to stop and restart my application.
This is the most common approach. Making this work inside the application is essentially building the bootstrapper into the application itself (in its own AppDomain), and unloading/restarting the AppDomain using the assembly. This is typically more work and just as disrupting as a separate bootstrapper application.

you are probably looking for something like MEF?
http://mef.codeplex.com/
http://msdn.microsoft.com/en-us/library/dd460648(v=vs.110).aspx

workaround needed: notify a user that exe is missing dependencies from within the application?

I wrote a quick console application that uses SharePoint dll files. If I attempt to run it on a machine that doesn't have said dll files, the application immediately crashes upon opening.
I'm definitely a newbie, but I would prefer if there was a way the application could tell the user they are using it on a wrong machine, before it hard crashed. Is there a way of doing this other than writing a second application to scan for dependencies, to be run prior to the application in question? If I put the code that needs dependencies in a separate class, that isn't instantiated until the application has checked it is on the correct computer, will the application still fail immediately on opening? Surely someone has figured out a workaround for this sort of situation.

Unfortunately you will have to write a launcher application - if you think about it, the required DLLs need to be there for the main application to even start. If you embed the scan in your main application, it will not start due to the missing DLLs.
You may be able to use a plugin architecture that scans for required DLLs and loads them dynamically (MEF comes to mind).

How about wrapping the load of that dll into:
try {
Assembly.Load(..);
}
catch(TypeLoadException ex) {
//Let the user know which type from what dll was not loaded.
}
You will have to load that dll at runtime to actually do that though.

It might be possible to copy the assemblies to the output directory for sharepoint. So references are made locally.

if your application references directly the SharePoint dlls or assemblies there is no way to notify the user because the .NET CLR will not execute your code if any of the statically linked needed assemblies is not available.
you can either use some kind of dynamic loading of the SharePoint assembly and types so at the startup time the application does not need that assembly to execute, or you create a launcher for your application which does the check and if all is ok starts your application otherwise notifies the user.

Embed EXE and required DLL in .NET application and execute at runtime

I have an existing EXE and DLL file (both unmanaged) that I'd ideally like to embed in my C# app and execute at runtime of the C# app. The EXE, when executed normally via command-line or Explorer, requires the DLL to be in the same directory as the EXE. How would I be able to:
1) Embed the EXE and DLL in my app and execute them via C# code?
2) Make sure that the EXE will be able to access its dependent DLL file?
Thanks!

Put them in Project embedded Resources.
When your program runs extract them from Resources, copy into known location and execute via Process.Start

Add the files as embedded resources. You can then export them to wherever you like in your code. Use the System.Diagnostics.Process class to run it.
Edit:
You may also want to cache the location name so that you can delete the files when your C# application exits (if you want to be nice and cleanup after yourself that is)

There is .NETZ which I have used once successfully. It seems that the tool also supports native unmanaged DLLs to some degree.
Maybe it helps as a pointer to give you some ideas for your actual desired solution.