dotnet deployment in the real world

[Thomas]

Hi,

Some quick background: Most of my experience with CGI has been with
Perl. We'd write perl scripts that shared custom modules where we'd put
all of our utility functions and OO code that could be re-used across
scripts. If we wanted to update a function in a module, we just updated
the module, and all scripts across the site instantly saw the changes.
No restarting IIS necessary.

With .net, I am trying to figure out how to best accomplish the same
type of thing. So far I am running into nothing but brick walls.

We have some class library assemblies (DLLs) we've written in .net,
which we want to be able to use from any asp.net program on our
webserver.

First thing I noticed is our asp.net programs default to making a copy
of these modules into their own folders. This destroys the reasoning
behind these modules -- we want any changes to the modules to be
reflected instantly across the server.

So then I looked into installing these modules as shared assemblies in
the GAC. But that requires you run the gacutil to update the GAC
whenever you make any changes. In our environment, we make many changes
a week to code, and having to run gacutil to freshen the cache every
time is tedious. But it is my understanding that even if we did do
that, we'd still have to restart IIS for the changes to be picked up by
the scripts. Apparantly .net only detects changed files if they are
private assemblies being used, not shared.

So next I looked into adding some configuration changes to the
<runtime> area of machine.config. For example,

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Our.Common" publicKeyToken="ae7d1e231700e31b"
/>
<codeBase version="1.0.0.0"
href="file:///D:\OurClassLibrary\Our.Common.DLL" />
</dependentAssembly>
</assemblyBinding>
</runtime>

Now, this basically works. It is like sharing an assembly in the GAC,
with the advantage that we can just upload the latest file to our
D:\OurClassLibrary folder.

However, in reality, it still has two problems:

1. Apparantly IIS locks the DLLs in that directory when it first loads
them, so you have to stop IIS to upload the latest changes!

2. Even if you didn't have the locking problem, you'd still have to
restart IIS for your .net apps to see the changes -- same as with the
GAC.

This seems completely insane to me. We can't be the only ones trying to
share our code across our web applications, and needing to make changes
frequently.

How does everyone else handle this problem?

Thanks!

 

[Guest]

Hi,

Some quick background: Most of my experience with CGI has been with
Perl. We'd write perl scripts that shared custom modules where we'd put
all of our utility functions and OO code that could be re-used across
scripts. If we wanted to update a function in a module, we just updated
the module, and all scripts across the site instantly saw the changes.
No restarting IIS necessary.

With .net, I am trying to figure out how to best accomplish the same
type of thing. So far I am running into nothing but brick walls.

We have some class library assemblies (DLLs) we've written in .net,
which we want to be able to use from any asp.net program on our
webserver.

First thing I noticed is our asp.net programs default to making a copy
of these modules into their own folders. This destroys the reasoning
behind these modules -- we want any changes to the modules to be
reflected instantly across the server.

Yes and no. From a global perspective, certainly, but remember that the
Global Assembly Cache is the solution for global assemblies. By copying, you
give the apps the ability to run on different versions of an assembly (until
you can get a specific application up to snuff on a particular assembly,
while other apps are already retooled).

So then I looked into installing these modules as shared assemblies in
the GAC. But that requires you run the gacutil to update the GAC
whenever you make any changes. In our environment, we make many changes
a week to code, and having to run gacutil to freshen the cache every
time is tedious. But it is my understanding that even if we did do
that, we'd still have to restart IIS for the changes to be picked up by
the scripts. Apparantly .net only detects changed files if they are
private assemblies being used, not shared.

So next I looked into adding some configuration changes to the
<runtime> area of machine.config. For example,

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Our.Common" publicKeyToken="ae7d1e231700e31b"
/>
<codeBase version="1.0.0.0"
href="file:///D:\OurClassLibrary\Our.Common.DLL" />
</dependentAssembly>
</assemblyBinding>
</runtime>

Now, this basically works. It is like sharing an assembly in the GAC,
with the advantage that we can just upload the latest file to our
D:\OurClassLibrary folder.

However, in reality, it still has two problems:

1. Apparantly IIS locks the DLLs in that directory when it first loads
them, so you have to stop IIS to upload the latest changes!

2. Even if you didn't have the locking problem, you'd still have to
restart IIS for your .net apps to see the changes -- same as with the
GAC.

This seems completely insane to me. We can't be the only ones trying to
share our code across our web applications, and needing to make changes
frequently.

How does everyone else handle this problem?

Thanks!

First, most shops do not change code at a stellar pace, so it is not
normally a major problem. The most common scenario, to solve the issue you
talk about, is setting up a web farm. Bring down one machine, update, bring
it up and switch. User requests get trafficed to the new machine after
deploy. This also gives you a high availability solution.

If you want to have a more robust drag and drop, you can use Component
Services (ie, COM+). There are a couple of issues:

1. For the flexibility of being able to quickly dump new assemblies, you end
up with some performance loss
2. You are using interop

The problem you speak of will be conquered, in one way, in the 2.0
Framework. The new code directory allows you to dump new source files and
have them compile. The negative is you want assemblies common to all
applications, and I am not certain the code directory can be a common
location (Not quite true, I am sure there is some way around this, but I do
not believe it is default).

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Thomas]

The problem you speak of will be conquered, in one way, in the 2.0
Framework. The new code directory allows you to dump new source files and
have them compile. The negative is you want assemblies common to all
applications, and I am not certain the code directory can be a common

location (Not quite true, I am sure there is some way around this, but I do
not believe it is default).

Hi Cowboy,

Thanks for the reply. I am disappointed that .NET seems to encourage
code copying rather than code sharing in live environments. It sounds
like people are either using web farms, or they are just copying their
libraries to all their individual apps. Sounds like a nightmare to
maintain.

I guess what I don't understand is why IIS doesn't detect changes in
the GAC just as it detects changes in the private application
directories? If that was fixed, it would be simple for us to roll out
updated class libraries that our apps could pick up instantly.

In regards to .NET 2.0, I cannot find anything describing this new
feature you are describing ("code directory"), or how exactly it might
help me reuse my code across our website rather than copying it
everywhere. Can you point me to a page that discusses this new feature?
Thanks,
Thomas

 

[Thomas]

It seems as though one (hacky) solution is to kill aspnet_wp.exe after
uploading the latest DLLs into the GAC. Apparantly this is not as
destructive as restarting IIS. Are there downsides to doing this?