J
john
I am occasionally getting a strange error when deploying an asp.net
assembly to a \bin directory in our production environment.
CSC0006: Metadata file xxxxx could not be found.
We then have to run around drain stopping web servers and bouncing IIS
throughout the farm, and this seems to fix the problem. It seems to
be completely random as to which machine seems to be causing the
problem, and I'm not sure how to determine which one it is before
taking the above action. Maybe we could look at the application event
log, but that's not the real issue here.
Here's a little background: We have six web servers in the production
farm. Our development environment is a single web server, and our
staging environment is a two web server cluster. We have never
experienced this problem in development or staging. The assembly is
not strong named and therefore doesn't reside in the GAC, but instead
in the local \bin directory along with a few other assemblies that are
referenced by the main application assembly. The reason we have not
placed the assembly in the GAC is because I think that I remember
reading that if an assembly is updated or changed often, it is easier
to have it in the local \bin directory. Also, and I may be wrong
about this, but at some point in time we may need different
applications to reference different versions of the shared assembly,
and I don't think that is possible if it is located in the GAC.
Now, this problem does not occur every time we push the code to
production, it kind of seems to depend on the time of day (i.e. the
number of users currently on the site). If we do it in the middle of
the night, no problems, but if done early in the day, I'd say we have
about a 50/50 chance. Microsoft Application Center 2000 does our load
balancing and synchronizations, and I was wondering if there is
anything special we need to be doing here. Again, our staging
environment uses app center as well, and there has never been a
problem there. I'm kind of at a loss, and any help would be
appreciated. What ever happened to xcopy deployment?
Thanks,
John
assembly to a \bin directory in our production environment.
CSC0006: Metadata file xxxxx could not be found.
We then have to run around drain stopping web servers and bouncing IIS
throughout the farm, and this seems to fix the problem. It seems to
be completely random as to which machine seems to be causing the
problem, and I'm not sure how to determine which one it is before
taking the above action. Maybe we could look at the application event
log, but that's not the real issue here.
Here's a little background: We have six web servers in the production
farm. Our development environment is a single web server, and our
staging environment is a two web server cluster. We have never
experienced this problem in development or staging. The assembly is
not strong named and therefore doesn't reside in the GAC, but instead
in the local \bin directory along with a few other assemblies that are
referenced by the main application assembly. The reason we have not
placed the assembly in the GAC is because I think that I remember
reading that if an assembly is updated or changed often, it is easier
to have it in the local \bin directory. Also, and I may be wrong
about this, but at some point in time we may need different
applications to reference different versions of the shared assembly,
and I don't think that is possible if it is located in the GAC.
Now, this problem does not occur every time we push the code to
production, it kind of seems to depend on the time of day (i.e. the
number of users currently on the site). If we do it in the middle of
the night, no problems, but if done early in the day, I'd say we have
about a 50/50 chance. Microsoft Application Center 2000 does our load
balancing and synchronizations, and I was wondering if there is
anything special we need to be doing here. Again, our staging
environment uses app center as well, and there has never been a
problem there. I'm kind of at a loss, and any help would be
appreciated. What ever happened to xcopy deployment?
Thanks,
John