Prev: code seems not executing: giving request failed
Next: High performance database messaging or pushing
From: Mark on 27 Apr 2010 17:26
Hi...

We've got a fair pile of .net code supporting our ASP.Net side. Some of our
C# objects are also exposed through COM interop (to talk to our old ISAPI
filters and legacy asp code).

Recently I was asked to see what it would take to run multiple versions of
our code on a single box - both for development ease and migration
flexibility.

Seemed to me that we needed to start differentiating our assembly versions
between builds.

I've got 2 builds of 2 different release trees built and set up as different
websites in IIS 7. Our software is built to say one tree is version 1.0.0.0
and the other is 2.0.0.0. Looking in the registry after regasm runs, I see 2
different version keys under InprocServer32 - one for each build - for each
class exposed as COM.

What puzzles me is that we an HttpModule that seems to be reaching over into
the website with the highest build number for the code. The http module, say
mod.dll, is in the website root's /bin directory and plugged in with the
local web.config, as is the assembly of the referenced class.

I had the http module output the build version of the assemblies it was
using, and on both websites it says it's running the highest build number
despite the fact that other config values come out different.

The http module references one of these C# objects that also has COM
exposure but since they're all in C#, the httpmodule doesn't instantiate the
object as COM - it just does a new ().

But in the output, the website with the version 1.0.0.0 tree is using the
code from the v 2.0.0.0 tree (I had the output include the Assembly.Fullname
of the component in question). More specifically (since the regasm is done
as a post-build event in the project) it's running the code from the v
2.0.0.0 tree where the regasm got run.

I tried adding the same diagnostic output to the v2.0.0.0 http module code,
but the website doesn't seem to be picking it up, despite numerous IISRESETs.

I'm obviously missing a lot on how asp.net is resolving, finding, and
caching assemblies. Where have I gone off track?

Thanks
Mark

From: Mark on 28 Apr 2010 15:40
Never mind... I found the httpmodule wasn't actually getting invoked at all
- an isapi was highjacking the request and going through the COM door...

"Mark" wrote:

> Hi...
>
> We've got a fair pile of .net code supporting our ASP.Net side. Some of our
> C# objects are also exposed through COM interop (to talk to our old ISAPI
> filters and legacy asp code).
>
> Recently I was asked to see what it would take to run multiple versions of
> our code on a single box - both for development ease and migration
> flexibility.
>
> Seemed to me that we needed to start differentiating our assembly versions
> between builds.
>
> I've got 2 builds of 2 different release trees built and set up as different
> websites in IIS 7. Our software is built to say one tree is version 1.0.0.0
> and the other is 2.0.0.0. Looking in the registry after regasm runs, I see 2
> different version keys under InprocServer32 - one for each build - for each
> class exposed as COM.
>
> What puzzles me is that we an HttpModule that seems to be reaching over into
> the website with the highest build number for the code. The http module, say
> mod.dll, is in the website root's /bin directory and plugged in with the
> local web.config, as is the assembly of the referenced class.
>
> I had the http module output the build version of the assemblies it was
> using, and on both websites it says it's running the highest build number
> despite the fact that other config values come out different.
>
> The http module references one of these C# objects that also has COM
> exposure but since they're all in C#, the httpmodule doesn't instantiate the
> object as COM - it just does a new ().
>
> But in the output, the website with the version 1.0.0.0 tree is using the
> code from the v 2.0.0.0 tree (I had the output include the Assembly.Fullname
> of the component in question). More specifically (since the regasm is done
> as a post-build event in the project) it's running the code from the v
> 2.0.0.0 tree where the regasm got run.
>
> I tried adding the same diagnostic output to the v2.0.0.0 http module code,
> but the website doesn't seem to be picking it up, despite numerous IISRESETs.
>
> I'm obviously missing a lot on how asp.net is resolving, finding, and
> caching assemblies. Where have I gone off track?
>
> Thanks
> Mark
>
 | 
Pages: 1
Prev: code seems not executing: giving request failed
Next: High performance database messaging or pushing