Programmatic diagnostic questions about dlls

  • Thread starter Thread starter Jason Ratke
  • Start date Start date
J

Jason Ratke

Hi,

I am currently working on a diagnostic utility for developers, and some of
the things I want to check are whether a dll in a project output folder is
locked and cannot be over-written, or if an incorret version of a dll has
been cached in the temporary internet files folder.

A friend said that I could possibly open a file stream on a dll, and attempt
to lock it, and if it failed, it would give info on which process currently
had it locked, which might solve the first requirement - does anyone else
have any ideas or suggestions on this?

As for checking for cached dlls, I was thinking that I could maybe use
reflection on the dlls in the temp inet folder to check for inconsistent dll
versions, but I'm not sure if this is the best approach, or would even
work - suggestions?

Thanks,
Jason
 
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) Michelangel
 
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
 
Hello Jason,

Which kind of app - win or web and what's the windows version?

PS: Seems that it's ShadowCoping behaviour on win2k3.

---
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

JR> We run into a problem somewhat frequently where the application,
JR> when run locally, appears to be using an older, cached version of
JR> one of the project dlls from the solution. This obviously causes
JR> problems because debugging won't work properly when attaching to the
JR> application process
JR>
 
It's a web app, and all of the developers are running on Windows XP Pro;
most are still using IE6, although our QA department just certified our app
with IE7, so some may be using that.
 
Hello Jason,

How do you make sure that u use the same dll running locally?
Do you debug HTTP web project or File web project? or maybe using remove
debugger?


---
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

JR> It's a web app, and all of the developers are running on Windows XP
JR> Pro; most are still using IE6, although our QA department just
JR> certified our app with IE7, so some may be using that.
JR>
JR> JR>
Hello Jason,

Which kind of app - win or web and what's the windows version?

PS: Seems that it's ShadowCoping behaviour on win2k3.

---
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

JR> We run into a problem somewhat frequently where the application,
JR> when run locally, appears to be using an older, cached version of
JR> one of the project dlls from the solution. This obviously causes
JR> problems because debugging won't work properly when attaching to
the
JR> application process
JR>
Click to expand...
Click to expand...
 
Hi Michael,

We have the web project set up as part of our solution, and we have the
other projects in the solution. All projects are referenced as file
references (the debug output dll of the projects are referenced by the
projects that depend on them), not project references. The web project has
reference paths pointing to all the other projects in the solution. The
reference properties are all set to Copy Local.

I have seen myself that when attaching to the aspnet_wp process, sometimes
the module that is loaded into the debugger is an old, cached version of the
dll that is in the temporary internet files folder...

Hope that helps,
Jason

Michael Nemtsev said:
Hello Jason,

How do you make sure that u use the same dll running locally?
Do you debug HTTP web project or File web project? or maybe using remove
debugger?


---
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

JR> It's a web app, and all of the developers are running on Windows XP
JR> Pro; most are still using IE6, although our QA department just
JR> certified our app with IE7, so some may be using that.
JR> JR>
Hello Jason,

Which kind of app - win or web and what's the windows version?

PS: Seems that it's ShadowCoping behaviour on win2k3.

---
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

JR> We run into a problem somewhat frequently where the application,
JR> when run locally, appears to be using an older, cached version of
JR> one of the project dlls from the solution. This obviously causes
JR> problems because debugging won't work properly when attaching to
the
JR> application process
JR>
Click to expand...
Click to expand...
Click to expand...
 
Back
Top