I don't think so. That wont resolve the problem where the assembly has
dependencies on other assemblies that reside in directories outside of the
application base directory or one of its subdirectories. Also, they were
describing a means of adding a manifest as a resource to a win32
application, not to a .net application. This definitely does not apply to
anything you can do to your .net component.
"Guido Buecker" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> hi dave,
>
> once more thanks for your help.
>
> while looking for a solution i stubled across the following article in
MSDN
> where they describe how to add a manifest as resource.
>
> "Enabling an Assembly in an Application Hosting a DLL, Extension, or
Control
> Panel"
>
> i was just curious whether that may solve the problem.
>
> bye, guido
>
>
> "Dave" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> > Glad it worked.
> >
> > To uninstall it you use a -= instead of a +=, all the other fields on
the
> > line are the same. For example,
> >
> > AppDomain.CurrentDomain.AssemblyResolve -= new
> > System.ResolveEventHandler(myHandler);
> >
> > I don't believe you need to do this - once your assembly is loaded it
> should
> > stay loaded, so there should not be any problems with Excel making a
call
> to
> > a function that is no longer loaded.
> >
> > I am not sure what you mean by compiling a manifest as a resource but it
> > would not solve your problem. Given the way Excel appears to load your
> > assembly the runtime will never automatically resolve those references.
> >
> >
> > "Guido Buecker" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > ok, many thanks, that worked so far.
> > > but now i have two more questions.
> > >
> > > the first might be of a more general type: do i have to uninstall the
> > > ResolveEventHandler? or more general, do i have to generally uninstall
> > > EventHandler's. i never saw something like "event -=
_MyEventHandler".i
> > > suspect that this is (somehow) automatically done with garbage
> collection.
> > > am i right? but then what about static callbacks?
> > >
> > > i just read about the possibility to compile a manifest as a resource
> into
> > a
> > > dll. would that be an alternative way to solve the problem?
> > >
> > > bye, guido
> > >
> > >
> > > "Dave" <(E-Mail Removed)> wrote in message
> > > news:(E-Mail Removed)...
> > > > You should be able to subscribe to the AssemblyResolve event. In the
> > > handler
> > > > you search the list of assemblies already loaded into the appdomain
> > > looking
> > > > for a match, and if found return it. If it's not already loaded you
> > search
> > > > the directory where the addin is installed for the requested
assembly,
> > and
> > > > when found use LoadFrom to load the assembly into the appdomain.
> > > >
> > > > "Guido Buecker" <(E-Mail Removed)> wrote in message
> > > > news:(E-Mail Removed)...
> > > > > hi there,
> > > > >
> > > > > i have problem with a special "application" scenario. maybe
someone
> > more
> > > > > experienced has an idea.
> > > > >
> > > > > what i have is a main mixed mode managed C++ dll and a bunch of
> > > dependent
> > > > > (C#/.NET) dll's
> > > > > the main dll is loaded as an AddIn into Excel (via Excel97 SDK)
> > > > >
> > > > > now the AddIn won't load because it cannot find it's dependent
> dll's.
> > > This
> > > > > is because the Excel.exe is treated as the application and all
> > (private)
> > > > > assemblies (and .config files) are searched in the application
> > directory
> > > > > (which is the Excel directory and not my "application" dir).
> > > > >
> > > > > the question now is, is there a way to solve this scenario without
> > > > switching
> > > > > to shared assemblies (and installing all the stuff in the GAC)? i
> know
> > > > that
> > > > > it is no big deal to do so (and in fact i've alredy done it) but
i'm
> > > just
> > > > > curious if there is another solution.
> > > > >
> > > > >
> > > > > thanks in advance
> > > > >
> > > > > guido
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|