G
Gary McGill
I have a managed COM add-in for Word/Excel/PowerPoint to which I've recently
added a shim with the help of this NG (thanks Mike).
I can deploy this to a target machine and everything works fine. However,
I'm still having real problems getting it to work on my development machine.
As I mentioned in another post, my managed DLL tries to load configuration
settings from a config file located alongside the DLL. I get the location of
the DLL itself using GetExecutingAssembly().Location.
Having deployed my add-in on another machine, this maps on to
ProgramFiles/MyCompany/MyApp/MyDll.dll as I'd expect.
However, on my development machine, it maps onto somewhere bizarre in the
LocalSettings folder:
C:\DocumentsAndSettings\MyLogin\LocalSettings\ApplicationData\Assembly\dl2\
(some random letters)\MyDll.dll
At first I thought that this was simply a problem with what the CodeBase
property is returning, but I've since discovered that there is actually a
copy of my managed DLL at that location! When I did a File Find for
MyDll.dll I found dozens of them, all somewhere in the dl2 directory but
with a different set of random letters. I'm guessing that a new one gets
created every time I build (or run?) the DLL.
What's even worse is that I've now discovered that if I make a chance to the
source for my DLL and then build & run it by starting Word, the version of
the DLL that actually gets executed is not the one that I just built! (I
figured this out after I put in some extra tracing code that didn't get
executed - took me a long while to understand that this is what the problem
was).
Can anyone help me here? I've seen some chatter on the web about the
LocalSettings directory being used for DLLs that are downloaded, but that
doesn't seem to apply in this case. What's going on?
Thanks in advance,
Gary
added a shim with the help of this NG (thanks Mike).
I can deploy this to a target machine and everything works fine. However,
I'm still having real problems getting it to work on my development machine.
As I mentioned in another post, my managed DLL tries to load configuration
settings from a config file located alongside the DLL. I get the location of
the DLL itself using GetExecutingAssembly().Location.
Having deployed my add-in on another machine, this maps on to
ProgramFiles/MyCompany/MyApp/MyDll.dll as I'd expect.
However, on my development machine, it maps onto somewhere bizarre in the
LocalSettings folder:
C:\DocumentsAndSettings\MyLogin\LocalSettings\ApplicationData\Assembly\dl2\
(some random letters)\MyDll.dll
At first I thought that this was simply a problem with what the CodeBase
property is returning, but I've since discovered that there is actually a
copy of my managed DLL at that location! When I did a File Find for
MyDll.dll I found dozens of them, all somewhere in the dl2 directory but
with a different set of random letters. I'm guessing that a new one gets
created every time I build (or run?) the DLL.
What's even worse is that I've now discovered that if I make a chance to the
source for my DLL and then build & run it by starting Word, the version of
the DLL that actually gets executed is not the one that I just built! (I
figured this out after I put in some extra tracing code that didn't get
executed - took me a long while to understand that this is what the problem
was).
Can anyone help me here? I've seen some chatter on the web about the
LocalSettings directory being used for DLLs that are downloaded, but that
doesn't seem to apply in this case. What's going on?
Thanks in advance,
Gary