471,357 Members | 1,090 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,357 software developers and data experts.

How can I disable shadow copying for my assembly?

I have a component that needs to access files which exist in the same
directory as the DLL containing the component itself. To determine the
component's installation directory, I'm using
System.Reflection.Assembly.GetExecutingAssembly(). Location. This worked fine
on my computer, but for another user, it failed because the assembly was
being loaded using a shadow copy of the DLL located in a different directory.
Is there a way, programmatically, to determine the location of the original
DLL, or is there a way to turn off shadow copying?

Thanks,
Bill
Aug 10 '05 #1
5 6911
You could try:

AppDomain.CurrentDomain.BaseDirectory

I'm not sure if this will work though as I have never tired it.

--
Brian Delahunty
Ireland

http://briandela.com/blog
"Bill Rust" wrote:
I have a component that needs to access files which exist in the same
directory as the DLL containing the component itself. To determine the
component's installation directory, I'm using
System.Reflection.Assembly.GetExecutingAssembly(). Location. This worked fine
on my computer, but for another user, it failed because the assembly was
being loaded using a shadow copy of the DLL located in a different directory.
Is there a way, programmatically, to determine the location of the original
DLL, or is there a way to turn off shadow copying?

Thanks,
Bill

Aug 10 '05 #2
Hi Bill,

Thanks for your post.

Based on my understanding, your assembly DLL access files relative to its
directory. However, if the user loads your assembly DLL with shadow copy
feature, because the files will not be copied to the cache directory, the
assembly can not find the files any more. If I misunderstand you, please
feel free to tell me.

Normally, we use AppDomainSetup to set the shadow copy function for our
AppDomain. In our appdomain, all the shadow copy process has been over, so
it is impossible to disable it now. However, we can use
AppDomain.CurrentDomain.SetupInformation property to get the AppDomainSetup
reference, then we can use AppDomainSetup.ShadowCopyDirectories to get the
directory names our assembly original reside. Also, we can use
AppDomainSetup.CachePath property to get the cached shadow copy directory.

Hope this helps.
================================================== ==
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Aug 11 '05 #3
Hi Bill,

Does my reply make sense to you? If you still have any concern, please feel
free to tell me. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Aug 16 '05 #4
Hi Jeffrey,

Your reply makes sense, but I'm not sure it solves my problem because it
just tells me which directories are being shadow copied, but it doesn't tell
me which directory my component came from. At any rate, a co-worker informed
me of a different solution which appears to work. Rather than calling
System.Reflection.Assembly.GetExecutingAssembly(). Location, I call
System.Reflection.Assembly.GetExecutingAssembly(). CodeBase which gives me the
install directory.

Thanks,
Bill

""Jeffrey Tan[MSFT]"" wrote:
Hi Bill,

Does my reply make sense to you? If you still have any concern, please feel
free to tell me. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Aug 16 '05 #5
Hi Bill,

Thanks for your feedback.

Yes, System.Reflection.Assembly.GetExecutingAssembly(). CodeBase should meet
your need, it will return the original assembly location.

However, I think the solution I provided in the last reply should also get
what you want. Once we have used AppDomainSetup.ShadowCopyDirectories to
get where the assembly is shadown copied from, we can just add the assembly
dll name to this directory to get its original location, this should be the
same as what System.Reflection.Assembly.GetExecutingAssembly(). CodeBase
returns.

Because Asp.net used shadow copy technology, we can do the test in an
Asp.net application. I print out the different path with the code snippet
below:
private void Page_Load(object sender, System.EventArgs e)
{
this.Response.Write(AppDomain.CurrentDomain.BaseDi rectory+"<br>");

this.Response.Write(AppDomain.CurrentDomain.Shadow CopyFiles.ToString()+"<br>
");

this.Response.Write(AppDomain.CurrentDomain.SetupI nformation.CachePath.ToStr
ing()+"<br>");

this.Response.Write(AppDomain.CurrentDomain.SetupI nformation.ShadowCopyDirec
tories.ToString()+"<br>");

this.Response.Write(System.Reflection.Assembly.Get ExecutingAssembly().CodeBa
se+"<br>");
// Put user code to initialize the page here
}
On my machine, the output is:

c:/inetpub/wwwroot/webapp/shadowcopytest/
True
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Tempo rary ASP.NET
Files\webapp_shadowcopytest\7a027e7d
c:\inetpub\wwwroot\webapp\shadowcopytest\bin
file:///c:/inetpub/wwwroot/webapp/shadowcopytest/bin/shadowcopytest.DLL

As we can see, we can add
AppDomain.CurrentDomain.SetupInformation.ShadowCop yDirectories with the dll
file name to get the original assembly location full path.

Hope this clarify my point.
================================================== =====
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Aug 16 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Mr 071 | last post: by
4 posts views Thread by Barry Kelly | last post: by
reply views Thread by Damien Anselmi | last post: by
2 posts views Thread by Oenone | last post: by
reply views Thread by Patrick F | last post: by
1 post views Thread by Patrick F | last post: by
5 posts views Thread by mark_overstreet | last post: by
reply views Thread by Mark | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.