Side-By-Side cooexistence of my own assemblies

[dave.dolan]

I have two versions of the same dll, one is in a production app, and the
other is in a test app. When I run the test app, it intereferes with the
operation of the production app, which leads me to believe that it's not
really using the right version of the assembly... The two versions of the dll
are not compatible, the new one completely restructures a lot of the way the
old one worked, so i can't forklift the old one outright.. Is there
something I'm missing? I just put the two dlls in separate apps on a windows
2000 host, and set each one to run isolated (but it doesn't appear that it is
isolated afterall..)

I have static and singleton components in each of the dlls... and when I
start the test one up, it messes up the production one's singleton details...
there has to be a way to tell it not to use the one that's already loaded by
the production app when I start up the test app... I even gave the dll's
different version numbers... I think the problem wouldn't exist if I had 2k3
server and separate app pools, but that's not an option, becasue of some
legacy stuff I have to use at the moment... is there anything I can do to
work around this?

[bruce barker \(sqlwork.com\)]

if there is no unmanaged code and the virdirs are seperate application
(giving each is own domain) thn you should not have a problem.

-- bruce (sqlwork.com)

"dave.dolan" <da********@nospam.beginswithg.comwrote in message
news:2A**********************************@microsof t.com...

>I have two versions of the same dll, one is in a production app, and the
other is in a test app. When I run the test app, it intereferes with the
operation of the production app, which leads me to believe that it's not
really using the right version of the assembly... The two versions of the
dll
are not compatible, the new one completely restructures a lot of the way
the
old one worked, so i can't forklift the old one outright.. Is there
something I'm missing? I just put the two dlls in separate apps on a
windows
2000 host, and set each one to run isolated (but it doesn't appear that it
is
isolated afterall..)

I have static and singleton components in each of the dlls... and when I
start the test one up, it messes up the production one's singleton
details...
there has to be a way to tell it not to use the one that's already loaded
by
the production app when I start up the test app... I even gave the dll's
different version numbers... I think the problem wouldn't exist if I had
2k3
server and separate app pools, but that's not an option, becasue of some
legacy stuff I have to use at the moment... is there anything I can do to
work around this?

[dave.dolan]

I wouldn't have thought so either, but the fact is that I do... One of my
singletons keeps a dictionary, and when I startup the test version, the
dictionary on the production one throws duplicate key errors as soon as I hit
the thing. It's really strange.

"bruce barker (sqlwork.com)" wrote:

if there is no unmanaged code and the virdirs are seperate application
(giving each is own domain) thn you should not have a problem.

-- bruce (sqlwork.com)

"dave.dolan" <da********@nospam.beginswithg.comwrote in message
news:2A**********************************@microsof t.com...

I have two versions of the same dll, one is in a production app, and the
other is in a test app. When I run the test app, it intereferes with the
operation of the production app, which leads me to believe that it's not
really using the right version of the assembly... The two versions of the
dll
are not compatible, the new one completely restructures a lot of the way
the
old one worked, so i can't forklift the old one outright.. Is there
something I'm missing? I just put the two dlls in separate apps on a
windows
2000 host, and set each one to run isolated (but it doesn't appear that it
is
isolated afterall..)

I have static and singleton components in each of the dlls... and when I
start the test one up, it messes up the production one's singleton
details...
there has to be a way to tell it not to use the one that's already loaded
by
the production app when I start up the test app... I even gave the dll's
different version numbers... I think the problem wouldn't exist if I had
2k3
server and separate app pools, but that's not an option, becasue of some
legacy stuff I have to use at the moment... is there anything I can do to
work around this?

[dave.dolan]

haha well ook, I shouldn't maybe... but I do... I cleared the asp.net temp
files out just in case, and neither assembly is int he gac, so I have no idea
why this is happening. The only thing that I can think of is that it's win2k
and they're all using the same processes?

"bruce barker (sqlwork.com)" wrote:

if there is no unmanaged code and the virdirs are seperate application
(giving each is own domain) thn you should not have a problem.

-- bruce (sqlwork.com)

"dave.dolan" <da********@nospam.beginswithg.comwrote in message
news:2A**********************************@microsof t.com...

I have two versions of the same dll, one is in a production app, and the
other is in a test app. When I run the test app, it intereferes with the
operation of the production app, which leads me to believe that it's not
really using the right version of the assembly... The two versions of the
dll
are not compatible, the new one completely restructures a lot of the way
the
old one worked, so i can't forklift the old one outright.. Is there
something I'm missing? I just put the two dlls in separate apps on a
windows
2000 host, and set each one to run isolated (but it doesn't appear that it
is
isolated afterall..)

I have static and singleton components in each of the dlls... and when I
start the test one up, it messes up the production one's singleton
details...
there has to be a way to tell it not to use the one that's already loaded
by
the production app when I start up the test app... I even gave the dll's
different version numbers... I think the problem wouldn't exist if I had
2k3
server and separate app pools, but that's not an option, becasue of some
legacy stuff I have to use at the moment... is there anything I can do to
work around this?

[dave.dolan]

Well you're sort of right there Bruce, they don't interfere with one and
other, but I figured it out, I had to go into the web.config and specify the
fully qualified assemblyname of each of the referenced assemblies, including
the version numbers, otherwise I was getting the luck of the draw,
apparently. (which meant whichever version loaded first.)

"bruce barker (sqlwork.com)" wrote:

if there is no unmanaged code and the virdirs are seperate application
(giving each is own domain) thn you should not have a problem.

-- bruce (sqlwork.com)

"dave.dolan" <da********@nospam.beginswithg.comwrote in message
news:2A**********************************@microsof t.com...

I have two versions of the same dll, one is in a production app, and the
other is in a test app. When I run the test app, it intereferes with the
operation of the production app, which leads me to believe that it's not
really using the right version of the assembly... The two versions of the
dll
are not compatible, the new one completely restructures a lot of the way
the
old one worked, so i can't forklift the old one outright.. Is there
something I'm missing? I just put the two dlls in separate apps on a
windows
2000 host, and set each one to run isolated (but it doesn't appear that it
is
isolated afterall..)

I have static and singleton components in each of the dlls... and when I
start the test one up, it messes up the production one's singleton
details...
there has to be a way to tell it not to use the one that's already loaded
by
the production app when I start up the test app... I even gave the dll's
different version numbers... I think the problem wouldn't exist if I had
2k3
server and separate app pools, but that's not an option, becasue of some
legacy stuff I have to use at the moment... is there anything I can do to
work around this?