Running an XLL outside Excel? - c#

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.

Related

Sending control keys with DDeltaSolution UIDeskAutomationSpy

I have been using DDeltaSolution's UIDeskAutomationSpy to enhance some of my Coded UI testing, initially based on the MS Code UI test (cuit) framework.
However there is very limited documentation and even after using dotNetPeek to inspect the internals of the UIDeskAutomationSpy exe and associated dll, I can't see how to send control keys (Shift/Control/Alt) to a component.
There are two relevant methods
SendKeys()
SimulateSendKeys()
but both just take a string as input.
I've even got as far as thinking about trying to use Cecil to try and modify the binaries (is this possible?), but this is a desperate measure. Does anyone know any better, or know of any better documentation?
This is a surprisingly powerful tool, but no-one seems to have heard about it.
I'm not positive, but if I were you I'd try using the list of control key strings found HERE since automation spy is based on .NET. Let me know if it works!

Calling Excel C API from VSTO add-in

From within an Excel VSTO (.NET) add-in, I need to call Excel C API functions (e.g. Excel12), in order to avoid conversion between Excel's data types (xloper12) and managed data.
I know how I could get access to functions defined within an XLL; so in principle, I could write an XLL more or less "forwarding" the functionality which I need. Yet I would like to avoid a "dummy" XLL.
The accepted answer to this
Calling Excel/DLL/XLL functions from C#
question suggests that I find the functionality I need in xlcall32.dll. I'm not sure this assumption is correct.
Yet how do I put that all together? Does my VSTO addin have to load xlcall32.dll?

Is there a way to fake registry entry in C#?

I am trying to execute an .exe file from my C# code. The .exe file requires some key to exist in the registry. Now I have two options:
1. Either I can add the key, execute the file, and then delete what I added from registry.
2. OR If possible, I can fake the key in registry so that .exe can execute and I don't have to modify the registry.
Can someone please tell me if #2 is possible? If not then is there any other better way to deal with this situation (perhapds undo changes I made from registry)? or do I have to stick with #1?
Please guide me on this.
Thanks
Intercepting registry reads is not for the faint of heart and will almost certainly require several orders of magnitude more work than option 1.
There is a function for that, but it only affects the process which calls it. So you would have to use DLL injection. C# (or any type of managed code) would not be my choice for accomplishing this.
If you must intercept the read, then start developing a driver in C/C++ that calls CmRegisterCallback to hook system-wide calls and filter out the ones you need. But I think you'll seriously regret even starting the project... just go with option 1 instead.
It's technically possible to intercept calls to the registry using something like Detours. However, the intercept code cannot be written in C# and must be in C++ (or C, I suppose). Not to mention, doing this in a robust manner is going to be a lot of work.

Make an executable at runtime

Ok, so I was wondering how one would go about creating a program, that creates a second program(Like how most compression programs can create self extracting self excutables, but that's not what I need).
Say I have 2 programs. Each one containing a class. The one program I would use to modify and fill the class with data. The second file would be a program that also had the class, but empty, and it's only purpose is to access this data in a specific way. I don't know, I'm thinking if the specific class were serialized and then "injected" into the second file. But how would one be able to do that? I've found modifying files that were already compiled fascinating, though I've never been able to make changes that didn't cause errors.
That's just a thought. I don't know what the solution would be, that's just something that crossed my mind.
I'd prefer some information in say c or c++ that's cross-platform. The only other language I'd accept is c#.
also
I'm not looking for 3-rd party library's, or things such as Boost. If anything a shove in the right direction could be all I need.
++also
I don't want to be using a compiler.
Jalf actually read what I wrote
That's exactly what I would like to know how to do. I think that's fairly obvious by what I asked above. I said nothing about compiling the files, or scripting.
QUOTE "I've found modifying files that were already compiled fascinating"
Please read and understand the question first before posting.
thanks.
Building an executable from scratch is hard. First, you'd need to generate machine code for what the program would do, and then you need to encapsulate such code in an executable file. That's overkill unless you want to write a compiler for a language.
These utilities that generate a self-extracting executable don't really make the executable from scratch. They have the executable pre-generated, and the data file is just appended to the end of it. Since the Windows executable format allows you to put data at the end of the file, caring only for the "real executable" part (the exe header tells how big it is - the rest is ignored).
For instance, try to generate two self-extracting zip, and do a binary diff on them. You'll see their first X KBytes are exactly the same, what changes is the rest, which is not an executable at all, it's just data. When the file is executed, it looks what is found at the end of the file (the data) and unzips it.
Take a look at the wikipedia entry, go to the external links section to dig deeper:
http://en.wikipedia.org/wiki/Portable_Executable
I only mentioned Windows here but the same principles apply to Linux. But don't expect to have cross-platform results, you'll have to re-implement it to each platform. I couldn't imagine something that's more platform-dependent than the executable file. Even if you use C# you'll have to generate the native stub, which is different if you're running on Windows (under .net) or Linux (under Mono).
Invoke a compiler with data generated by your program (write temp files to disk if necessary) and or stored on disk?
Or is the question about the details of writing the local executable format?
Unfortunately with compiled languages such as C, C++, Java, or C#, you won't be able to just ``run'' new code at runtime, like you can do in interpreted languages like PHP, Perl, and ECMAscript. The code has to be compiled first, and for that you will need a compiler. There's no getting around this.
If you need to duplicate the save/restore functionality between two separate EXEs, then your best bet is to create a static library shared between the two programs, or a DLL shared between the two programs. That way, you write that code once and it's able to be used by as many programs as you want.
On the other hand, if you're really running into a scenario like this, my main question is, What are you trying to accomplish with this? Even in languages that support things like eval(), self modifying code is usually some of the nastiest and bug-riddled stuff you're going to find. It's worse even than a program written completely with GOTOs. There are uses for self modifying code like this, but 99% of the time it's the wrong approach to take.
Hope that helps :)
I had the same problem and I think that this solves all problems.
You can put there whatever code and if correct it will produce at runtime second executable.
--ADD--
So in short you have some code which you can hard-code and store in the code of your 1st exe file or let outside it. Then you run it and you compile the aforementioned code. If eveything is ok you will get a second executable runtime- compiled. All this without any external lib!!
Ok, so I was wondering how one would
go about creating a program, that
creates a second program
You can look at CodeDom. Here is a tutorial
Have you considered embedding a scripting language such as Lua or Python into your app? This will give you the ability to dynamically generate and execute code at runtime.
From wikipedia:
Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them.
Depending on what you call a program, Self-modifying code may do the trick.
Basically, you write code somewhere in memory as if it were plain data, and you call it.
Usually it's a bad idea, but it's quite fun.

NOVAS for .NET

Any astronomers out there? I'm wondering if anyone has produced or stumbled upon a .NET (preferably C#) implementation of the US Naval Observatoru Vector Astrometry Subroutines (NOVAS).
I know nothing (of consequence) about astronomy, and absolutely nothing about NOVAS, so please take this with a grain of salt.
But, I did look at the website, and it looks like they have a C implementation. You could always take the C implementation, access it via pinvoke, and write a C# wrapper around it.
Are you only interested in a port of that library or anything usable from C# for astronomy?
I don't have anything for the first part, but for the second I would take a look at AGI's Components. Their libraries provide ways to compute all kind of astronomical data. The Dynamic Geometry Library lets you model everything including planets and such rather easily.
This download contains a very useful astronomical library in C#.
Sorry that I don't remember where I got it but perhaps it is documented in there somewhere.
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=8399&lngWId=10
Sidenote: The NOVAS library is not very complete. You would be better off to pursue the SOFA lib from the International Astronomy Union. Here's the link:
http://www.iausofa.org/
Urania is an astronomy library in C#:
http://www.smokycogs.com/blog/tutorials/astronomical-calculations-in-c-sharp/
The download is the non-obvious "here" link on the page that combines all of the sample code into a single app called Urania.
Once downloaded, you will also need to modify the Urania.sln file to fix the paths of the different libraries that he uses (MathLib, UraniaLib, etc.) and then it will compile correctly. (Open Urania.sld in notepad and delete: "..\Libs\" out of the 3 project paths)

Categories