ikvm in a vsto add in

[mikeplacko]

VSTO add-ins copy dlls to temporary locations on windows when they execute. Unfortunately, for each word document open, a copy of your dll and all its related dlls get copied to individual temporary folders. This really screws up ikvm compiled JAR files, as it doesn't have a way to find the associated runtime from the original installation directory.
I've read a few other threads here on the topic of shadow copies, but I'm afraid I don't understand possible work arounds. Does anyone know of a way to either stop a VSTO add-in from doing this copy or a way to tell ikvm to look back into the original install directory for its stuff? I know the ikvm.properties file exists, but I can't seem to set it to anything that works, possibly because that file does not get copied to any of the temp directories.

[wasabii]

I don't know the answer to this, since I don't know how VSTO works. But, approaching the issue, I'd first figure out how VSTO works. Is it using the built in Shadow Copy? Are there existing techniques for copying resource files along with the assemblies that are used by other plugins? There has to be right?

[mikeplacko]

It's not using the built in shadowcopy, as in, you can't just disable shadowcopy by setting the config value. VSTO does some weird stuff, because you can have dozens of instances of your add-in running at once. Other threads on similar issues, have people trying to determine the path in code and pass it around to their faulting module paths (not ikvm related). In that case, if I could determine the actual path to the real copy of ikvm at runtime, how would I go about setting it in code?

[wasabii]

You can't set it in code, since IKVM initializes almost everything at assembly load. There is a way to set it in app.config though. But, no idea if you have that. And environmental variables.

You probably also need to consider that IKVM does not support AppDomains. So if VSTO hosts your extension within an AppDomain, you would likely not be able to just do that.

[wasabii]

Reading about VSTO now. Yeah. You'll almost certainly need to separate the IKVM related portions of code into a separate process.

[mikeplacko]

You have an app.config but it suffers from similar problems, which app.config is actually loading? The one in the install directory or a copy of it in temp? Often (but not always because Microsoft) it's the one in temp, so it's useless after the first run. Environment variables might be a more reliable solution, I could set those at install time, and it wouldn't change. What would they be?

[wasabii]

app.config is loaded by the Framework when it spawns an AppDomain, by configuring AppDomainSetup.ConfigurationFile. But since AppDomains aren't supported is isn't useful.

What would they be?

They are only applicable for IKVM as an entry point: that is, executing a main entry point. And they are IKVM_HOME_ROOT and IKVM_HOME. So, if you're writing as external program, those would work. For instance, they could be used to pass path information to an IKVM executable.

But if you're in control of the entry point yourself (which you'll have to be because no-AppDomains), these are not relevant, since the default location would work fine in that case.

[mikeplacko]

I attempted to set those, albeit to my best guess as to what they should be and no improvement.
IKVM_HOME_ROOT = C:\Program Files (x86)\MyApp\ikvm
IKVM_HOME = C:\Program Files (x86)\MyApp\

I should probably be more specific about my error, incase I'm not explaining it well enough: The type initializer for '' threw an exception.

Trace through the code at runtime and it appears to load the IKVM.Runtime.dll but I don't think it can find anything else including my jar/dll even though it's sitting there at the path specified.

And I'll just add that this same code base, referenced by something other than a VSTO project works great, so the JAR/dll itself and normal running ikvm does work. It also worked as a VSTO project in the very old version of ikvm but we needed to upgrade for many obvious reasons.

[wasabii]

Could just be the appdomains, as I've mentioned previously.