Jason
Fri May 04 10:02:44 CDT 2007
Hi Michael,
Thanks for the response! As far as inconsistent dll versions, the problem is
this:
We run into a problem somewhat frequently where the application, when run
locally, appears to be using an older, cached version of one of the project
dlls from the solution. This obviously causes problems because debugging
won't work properly when attaching to the application process, and things
just don't seem to "work right" for the developer. I'm trying to write
something that will detect this problem (among others), red flag it to the
developer, and if possible, fix it (clear the inet temp folder).
I hope that clarifies my problem; I was talking to someone yesterday that
suggested using reflection against the temp dlls and the compiled dlls from
the projects to compare versions would be the way to go, I'm just curious if
that's the best approach, or if there is a better way.
Thanks,
Jason
"Michael Nemtsev" <nemtsev@msn.com> wrote in message
news:a279a63a3eff6e8c95c6831669436@msnews.microsoft.com...
> Hello Jason,
>
> JR> I am currently working on a diagnostic utility for developers, and
> JR> some of the things I want to check are whether a dll in a project
> JR> output folder is locked and cannot be over-written, or if an
> JR> incorret version of a dll has been cached in the temporary internet
> JR> files folder.
> JR> JR> A friend said that I could possibly open a file stream on a dll,
> and
> JR> attempt to lock it, and if it failed, it would give info on which
> JR> process currently had it locked, which might solve the first
> JR> requirement - does anyone else have any ideas or suggestions on
> JR> this?
>
> It's common and easy way to check this. Nothing wrong with it
>
> JR> As for checking for cached dlls, I was thinking that I could maybe
> JR> use reflection on the dlls in the temp inet folder to check for
> JR> inconsistent dll versions, but I'm not sure if this is the best
> JR> approach, or would even work - suggestions?
>
> What does "inconsistent dll versions" mean?
> Do you want to check dlls which is used by your app or 3rd party?
> Take into account that Dll can be used from the different folder - for
> example Win2k3 use ShadowCopy and copy app dlls to the temporary folder
>
>
> ---
> WBR, Michael Nemtsev [.NET/C# MVP]. My blog:
>
http://spaces.live.com/laflour
> Team blog:
http://devkids.blogspot.com/
>
> "The greatest danger for most of us is not that our aim is too high and we
> miss it, but that it is too low and we reach it" (c) Michelangelo
>
>