|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Programmatic diagnostic questions about dllsI 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) Michelangelo 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 Show quote "Michael Nemtsev" <nemt***@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 > > 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. Show quote "Michael Nemtsev" <nemt***@msn.com> wrote in message news:a279a63a3f00808c95c990a89fccc@msnews.microsoft.com... > 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> > 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> Show quote JR> "Michael Nemtsev" <nemt***@msn.com> wrote in message JR> news:a279a63a3f00808c95c990a89fccc@msnews.microsoft.com... 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> 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 Show quote "Michael Nemtsev" <nemt***@msn.com> wrote in message news:a279a63a3f01518c95cc4b2bce5bc@msnews.microsoft.com... > 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> "Michael Nemtsev" <nemt***@msn.com> wrote in message > JR> news:a279a63a3f00808c95c990a89fccc@msnews.microsoft.com... > 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> > >  |
|||||||||||||||||||||||
Other interesting topics