Hi

I'm implementing an simple updater application that updates another
application.
The scenario is as follows:
The main application (MA) checks if there are any updates. If updates
are present, it starts another application: the updater application
(UA).
After that, UA waits for MA to exit. After MA exits, UA reads the
updating package and overwrites all the files.
Unfortunately, some private dll's are still in use, even after MA has
exited (!). It's impossible that those dll's are used by another
process because no running process references my dll.

Is there a way to find out what other process holds and blocks my dll?

Thanks.

nano2k,

Not to try and dissuade you, but considering that there is an
Application Updater Block in the Enterprise Library, and that ClickOnce also
provides very similar functionality, why would you try and rewrite this
functionality yourself?

For more information on ClickOnce:

http://msdn2.microsoft.com/en-us/net.../aa497348.aspx

For more information on the Application Updater Block:

http://msdn2.microsoft.com/en-us/library/ms978574.aspx

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)

"nano2k" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi
>
> I'm implementing an simple updater application that updates another
> application.
> The scenario is as follows:
> The main application (MA) checks if there are any updates. If updates
> are present, it starts another application: the updater application
> (UA).
> After that, UA waits for MA to exit. After MA exits, UA reads the
> updating package and overwrites all the files.
> Unfortunately, some private dll's are still in use, even after MA has
> exited (!). It's impossible that those dll's are used by another
> process because no running process references my dll.
>
> Is there a way to find out what other process holds and blocks my dll?
>
> Thanks.
>

Thanks Nicholas,

Forgot to mention. I'm using VS2003 with .NET 1.1.
Anyway, meantime I found out that VS was blocking my DLLs because I
used them for toolbox.
But still the question remains - is there a way to programatically get
the process/es that loaded a specific DLL?

Thanks.


Nicholas Paldino [.NET/C# MVP] a scris:
> nano2k,
>
> Not to try and dissuade you, but considering that there is an
> Application Updater Block in the Enterprise Library, and that ClickOnce also
> provides very similar functionality, why would you try and rewrite this
> functionality yourself?
>
> For more information on ClickOnce:
>
> http://msdn2.microsoft.com/en-us/net.../aa497348.aspx
>
> For more information on the Application Updater Block:
>
> http://msdn2.microsoft.com/en-us/library/ms978574.aspx
>
> Hope this helps.
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - (E-Mail Removed)
>
> "nano2k" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Hi
> >
> > I'm implementing an simple updater application that updates another
> > application.
> > The scenario is as follows:
> > The main application (MA) checks if there are any updates. If updates
> > are present, it starts another application: the updater application
> > (UA).
> > After that, UA waits for MA to exit. After MA exits, UA reads the
> > updating package and overwrites all the files.
> > Unfortunately, some private dll's are still in use, even after MA has
> > exited (!). It's impossible that those dll's are used by another
> > process because no running process references my dll.
> >
> > Is there a way to find out what other process holds and blocks my dll?
> >
> > Thanks.
> >