"Thomas" wrote:
[color=blue]
> 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.[/color]
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).
[color=blue]
> 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![/color]
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!
***************************
