By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,846 Members | 1,646 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,846 IT Pros & Developers. It's quick & easy.

Question on article by Scott about "Shadow copy of an assembly"

P: n/a
Hello All,

I just finished reading an interesting article by Scott about App Domains:
http://odetocode.com/Articles/305.aspx

Scott, I have a question about the section "Shadow Copies and Restarts". You
talked about "Drain Stopped" and "Shadow Copy" concepts in this article. I
maintain a web application which is in production. Every morning the way we
build the project is using Visual Studio's IDE to use "Build ->
Build<proj-name>" which basically builds all the files and copies the DLL
into the bin directory. Now during this build process, users are still using
our web application and sometimes they notice a weird error because of the
build process.

Now according to your article, if we simply copy the DLL into the bin
directory without building the project while users are using the machine can
we still take advantage of "Drained Stopped" behavior of AppDomains?

Why are my users noticing the weird errors if you think that App Domains use
the "Drain Stopped" phenomenon?

What are the differences between using IDE's build to build the web app
while users are using the web app VS Shadow copy?

Thanks a bunch
Feb 2 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Building a site using the IDE is not the same as "shadow copy". You still
need to provide the updated DLL to the website. For instance, suppose that
some bug was fixed, you still need to compile the assemblies in the IDE.
Then you would copy the DLL to the bin folder of your production website.

"Shadow copy" simply means that IIS will copy the assembly into a temp
location. Therefore the actual assembly running is not the one in the bin
folder but someone else, thereby preventing locks from happening.

I am not sure what "weird" issues your customers are having, but there are
some consequences the way I understand it to reloading the AppDomain. It is
my understanding that the sessions and other cross-post persistent
information is cleared when an AppDomain recycles. The AppDomain can
recycle in other situations as well like when the server determines that too
much memory is being used and other issues. It might recycle the AppDomain
to clear things like memory leaks.
"Diffident" <Di*******@discussions.microsoft.com> wrote in message
news:11**********************************@microsof t.com...
Hello All,

I just finished reading an interesting article by Scott about App Domains:
http://odetocode.com/Articles/305.aspx

Scott, I have a question about the section "Shadow Copies and Restarts".
You
talked about "Drain Stopped" and "Shadow Copy" concepts in this article. I
maintain a web application which is in production. Every morning the way
we
build the project is using Visual Studio's IDE to use "Build ->
Build<proj-name>" which basically builds all the files and copies the DLL
into the bin directory. Now during this build process, users are still
using
our web application and sometimes they notice a weird error because of the
build process.

Now according to your article, if we simply copy the DLL into the bin
directory without building the project while users are using the machine
can
we still take advantage of "Drained Stopped" behavior of AppDomains?

Why are my users noticing the weird errors if you think that App Domains
use
the "Drain Stopped" phenomenon?

What are the differences between using IDE's build to build the web app
while users are using the web app VS Shadow copy?

Thanks a bunch

Feb 2 '06 #2

P: n/a

Peter,

Thanks for your reply but I have a question. Earlier in my post when I said
"build" I was referring to the fact that I usually open the production web
app's csproj file using the "File > Open From Web" option and then build the
project while users are using it. Bin directory in my case would be the App
Base's bin directory as I am building the project on server.

So in my case does "Build" cause the AppDomain to reload?

Why would it reload the AppDomain if IIS shadow copied my old assembly?

Thanks for your clarification.

"Peter Rilling" wrote:
Building a site using the IDE is not the same as "shadow copy". You still
need to provide the updated DLL to the website. For instance, suppose that
some bug was fixed, you still need to compile the assemblies in the IDE.
Then you would copy the DLL to the bin folder of your production website.

"Shadow copy" simply means that IIS will copy the assembly into a temp
location. Therefore the actual assembly running is not the one in the bin
folder but someone else, thereby preventing locks from happening.

I am not sure what "weird" issues your customers are having, but there are
some consequences the way I understand it to reloading the AppDomain. It is
my understanding that the sessions and other cross-post persistent
information is cleared when an AppDomain recycles. The AppDomain can
recycle in other situations as well like when the server determines that too
much memory is being used and other issues. It might recycle the AppDomain
to clear things like memory leaks.
"Diffident" <Di*******@discussions.microsoft.com> wrote in message
news:11**********************************@microsof t.com...
Hello All,

I just finished reading an interesting article by Scott about App Domains:
http://odetocode.com/Articles/305.aspx

Scott, I have a question about the section "Shadow Copies and Restarts".
You
talked about "Drain Stopped" and "Shadow Copy" concepts in this article. I
maintain a web application which is in production. Every morning the way
we
build the project is using Visual Studio's IDE to use "Build ->
Build<proj-name>" which basically builds all the files and copies the DLL
into the bin directory. Now during this build process, users are still
using
our web application and sometimes they notice a weird error because of the
build process.

Now according to your article, if we simply copy the DLL into the bin
directory without building the project while users are using the machine
can
we still take advantage of "Drained Stopped" behavior of AppDomains?

Why are my users noticing the weird errors if you think that App Domains
use
the "Drain Stopped" phenomenon?

What are the differences between using IDE's build to build the web app
while users are using the web app VS Shadow copy?

Thanks a bunch


Feb 2 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.