We Keep Coding

I have the start address of a loaded DLL, how can I discover and call its exports?

I'm writing an add-in that runs in-process. I'm reliably able to discover the memory address of a DLL that is already loaded in that process. The memory at the offset clearly shows an "MZ" DOS header and a "PE" header. Later, there appears to be the names of exported functions etc. This walks and talks like a loaded DLL.
So, now, I'd like to discover more about what the DLL is, and more interestingly, what I might be able to do with it.
I've used PE utilities in the past, but they've always worked with file-based DLLs. How can I list the exported functions of an in-memory DLL, other than by inspecting the process in a hex editor? Is there any way to discover the file-based DLL that is currently loaded? (I'm not overly familiar with the linking that I think takes place when the dll is loaded.)
If I have the names of the exported functions, is it just a matter of trying to call those functions, and guessing their arguments and return values? Or is there some more robust reverse engineering that could be performed?
Given the starting address of the DLL, and a function name, how would I go about making a call in C#?

There are actually many questions here (and some are pretty vast). I'll try providing answers to some.
To get the handle of a module (.dll) loaded in the current process use
[MSDN]: GetModuleHandleEx function, whether its name or address is known (GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS flag)
To get the file name containing the code of a loaded .dll use [MSDN]: GetModuleFileName function. At this point you'll be able to use PE utilities that you mentioned (Dependency Walker or [MSDN]: Sysinternals Suite can be very useful)
Apparently, getting the functions signatures from a .dll is not a trivial task (sometimes it's quite impossible). Here are 3 URLs, but Google would yield tons of results on this topic:
[MSDN]: how can I get metadata (signature with parameters and return type) of C++ dll
[SO]: Is there any native DLL export functions viewer?
[SO]: Get signatures of exported functions in a DLL
But a .dll comes with one or more header file(s) that contain(s) (among other things) the functions/classes declarations. Lacking the header(s) would mean that either:
The .dll symbols are for internal purposes only (and not to be called "manually")
They are private (e.g. protected by a license), and in that case reverse engineering them wouldn't be very ethical
Anyway, considering that one way or another you get the functions names and signatures, you can load the functions via [MSDN]: GetProcAddress function, and then call them.
Doing everything from .NET (C#) (again, function names and signatures are required), only adds an extra level of complexity because C# code runs in managed environment, while C/C++ runs in native environment, and when data is exchanged between the 2 environments it needs to be marshalled/unmarshalled ([MSDN]: Overview of Marshaling in C++).
Below are 3 URLs, but again, Internet is full of information:
[MSDN]: Calling Native Functions from Managed Code
[SO]: Is it possible to call a C function from C#.Net
[SO]: Calling C DLL from C#

C# create excel sheet late bound

Using winforms, C# FW4.5 to open an excel sheet with late bound, like this:
objExcel = CreateObject("Excel.Application")
Now I want to use the InvokeMember method, but I don't know all the members of excel I can invoke.
For example, I know I can call it like this: InvokeMember("Close",... in order to close excel, but where can I find list of all the members I can invoke and what each one of them does?

Late-bound
Using winforms, C# FW4.5 to open an excel sheet with late bound, like this:
If you must use late-binding, using c# 4.0's dynamic keyword is a whole lot easier than InvokeMember, though it won't show you what methods you can invoke ahead of time.
Check out the following code that uses late-binding via the dynamic keyword. Notice how Visual Studio allows me to type in any old thing. Though auto-complete for the final members aren't available, it does show members for items I've used already. I won't know until runtime whether I got it right (such is the limitation of late-binding this way).
C# now supports dynamic late-binding. The language has always been strongly typed, and it continues to be so in version 4.0. Microsoft believes this makes C# easy to use, fast and suitable for all the work .NET programmers are putting it to. But there are times when you need to communicate with systems not based on .NET....The dynamic keyword in C# is a response to dealing with the hassles of these other approaches Tell me more
...and more specifically:
The COM interop scenario that the C# team specifically targeted in the C# 4 release was programming against Microsoft Office applications, such as Word and Excel. The intent was to make this task as easy and natural in C# as it always was in Visual Basic. Tell me more...
Early-bound
OP:
Now I want to use the InvokeMember method, but I don't know all the members of excel I can invoke
Though late binding is fine, even with dynamic, I like early binding. To get a list of methods, it's much easier and type-safe to use early binding via adding Microsoft.Office.Interop.Excel to your project.
Early binding:
var application = new Microsoft.Office.Interop.Excel.Application();
application.Visible = true;
application.ShowWindowsInTaskbar = true;
Here it is in VS:
C# 4 Goodness
c# 4 brings with it some stuff you'll only see when dealing with COM, like indexed properties - something not possible in c# types.
You can’t define types in C# that have indexed properties, but you can use them provided you’re doing so on a COM type more
Some smaller language features in C# 4.0 are supported only when writing code against a COM interop API
e.g.
ws.Range["A1", "B3"].Value = 123;
...is a whole lot easier than pre-c# 4:
ws.get_Range("A1", "B3").Value2 = 123;
C# 4.0 supports indexed properties on COM interop types. You can’t define types in C# that have indexed properties, but you can use them provided you’re doing so on a COM type more...
Tell me more
C# 4.0 - New C# Features in the .NET Framework 4, MSDN Mag July 2010
Dynamic .NET - Understanding the Dynamic Keyword in C# 4, MSDN Mag Feb 2011

How can I inform my managed DLL about my managed application types

I have a situation where I have a C# Managed DLL that is handling incoming real time data. The DLL filters and saves up to 200 of the most recent data points in a FIFO. I also have a C# application that on occasion needs to get some of the data from the DLL. I can easily setup methods in the DLL to return single values of the built in data types.
What I need is a way to pass a reference to my user defined type (EX: List ) to the DLL and have it fill it in. I cannot seem to find any way to tell the DLL about my types and the compiler complains that I do not know what I am doing. This is true. I have tried everything I can find on the internet.
Further my application already has a reference to the DLL so that it can start it up and respond to events, therefor I cannot add a reference to my application within the DLL without creating a circular reference.
So how can I inform my managed DLL about my managed application types? The end goal is to be able to pass an ObservableCollection and have the DLL fill in MyObject with data from its local cache of data points.
When searching the internet it seems that the managed to unmanaged scenario outweighs the managed to managed scenario by 98 plus percent.
Any ideas would be greatly appreciated.

To compile my comment as an answer:
You should have (naming is just ilustrative):
DataContract.dll with the definition of your types.
BusinessLogic.dll with the logic.
And Application.exe with your presentation logic.
DataContract.dll can then be referenced by both - BusinessLogic.dll and Application.exe.

Is it possible to call c# scripts from MATLAB?

I have a script in MATLAB that writes a CSV, the CSV is read by a c# script which writes a few more CSVs that I go back and read in MATLAB.
Is there any way to automate this so I don't have to call the c# code by hand each time?

It's very easy to call into .net from Matlab. The official documentation is at http://www.mathworks.co.uk/help/matlab/matlab_external/load-a-global-net-assembly.html You should be aware that Matlab is case-sensitive (even when it comes to specifying the assembly path) and that it is also limited in the kinds of objects it can pass back and forth across the boundary.
If you pass an array into your C# dll from Matlab, it will appear to be an array of bare objects rather than an array of numbers. In Matlab, you may need to use the char and cell methods to convert strings and arrays back into the form you are expecting.

To answer the title question, e.g. "Is it possible to call C# functions from MATLAB": yes, it is. Mathworks provides decent documentation on calling .NET assemblies from MATLAB on their website. Of course, there are limitations and some awkward quirks to take into account but basically you can create instances of .NET classes and interact with .NET applications from MATLAB.
To advise on automating this process, you could perhaps dive into the MATLAB COM Automation Service?
In the extension of this: it's also possible to call MATLAB functions in a .NET application. The other way around, sort of speak. This will be no problem with basic data types, but when it gets a bit more advances it can put you through some gnarly COM challenges, though.

Running an XLL outside Excel?

I know this question has been posted before... but I haven't found any answer yet (besides from the generic answers about how XLL are actually DLL, etc).
Has anybody out there been successful calling a XLL from say C# (using DllImport) without having to load Excel with the XLL loaded as an addin?
Basically, you would have to create a special XLCALL32.DLL that simulates the Excel host. It sounds like a lot of work... has anybody done this? Or seen a product to do it?
Thanks

You're on the right track with needing to create your own XLCall32.dll and simulate Excel. That's non-trivial given what you can do via the interface that XLLs use to talk to Excel. It becomes easier the less of Excel that you need to use from within your XLL, so I guess if you have a known selection of XLLs that you need to use and you know what bits of Excel they access via the XLL interface then you can just replace the bits you need...
Why do you want to do this?

Evaluating this XLL+ library (which is not free, running on trial atm) which hels to "mock"/"simulate" XLCALC32.dll calls (as it only needs 2 methods from it as far as i understand). Will let you know if I get somewhere.