RE: Side-by-Side Deployment Issue
- From: dogirard@xxxxxxxxxxxxxxxxxxxx ("Doug Girard [MSFT]")
- Date: Fri, 09 Sep 2005 22:03:08 GMT
Glynn,
Yes, be careful with schemas as they have a special resolution behavior
unless listed specifically in the disassembler's properties. Also watch
out for version numbers. Standard .NET versioning recognizes assemblies as
being different only if the major or minor version is changed (ie: the
first two numbers). Try 1.2.0.0 rather than 1.0.0.2.
Keep using the same receive ports and locations (yes, receive URIs must be
unique) and then bind another subscriber to these, i.e. the new
orchestration version. Then enlist and start the new orchestration version
and unenlist the old orchestration. This will prevent future publications
from going to the old version and direct them to the new one. Running
orchestration instances on the older version should complete on their own.
Doing the "Then enlist and start the new orchestration version and unenlist
the old orchestration" step should ideally be done transactionally to
prevent duplicate messages. I know there is a way to do this in BTS 2006
via the object model, committing in one swoop, but don't recall if this was
do-able the same way on 2004.
I'm trying to dig up additional documentation on side by side versioning
which I remember from 2004. I will repost when I find it.
Adding your followup below as well:
----------------
I've got some way towards solving this problem, but would still appreciate
some advice:
I moved my SQL schemas into their own assembly, and created a custom
pipeline for the SQL adapter. The custom pipeline XML Disassembler
references
only a specific version number of the schema. So 1.0.0.1 only receives that
same version of the schema. That has overcome my initial problem, but in
the
side-by-side scenario, 1.0.0.2 will also need a pipeline that uses only
1.0.0.2 versions of the schema. As my ports are late-bound, I specify the
pipeline for the receive location. But it looks like I need two sets of
receive locations, one for each version of the assembly. Trouble is, my
messages are physically available to receive from one location (whether
they
be file or SQL "locations") and two receive locations can't point to the
same
place. I'm getting in a twist here, so I'd be really grateful if someone
could spell out the best way to configure receive locations for
side-by-side
deployments.
Thanks again!
Glynn
----------------
HTH,
Doug Girard [MSFT]
Note: This posting is provided "AS IS" with no warranties, and confers no
rights.
--------------------
>Thread-Topic: Side-by-Side Deployment Issue
>thread-index: AcWfUhm5a4Qo9ZaoTTuGYKJwD475HA==
>X-WBNR-Posting-Host: 217.140.1.140
>From: "=?Utf-8?B?R2x5bm4=?=" <Glynn@xxxxxxxxxxxxxxxxxxxxxxxxx>
>Subject: Side-by-Side Deployment Issue
>Date: Fri, 12 Aug 2005 08:25:41 -0700
>Lines: 50
>Message-ID: <75D01552-B59C-4181-81CA-F37B6E8E7720@xxxxxxxxxxxxx>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="Utf-8"
>Content-Transfer-Encoding: 7bit
>X-Newsreader: Microsoft CDO for Windows 2000
>Content-Class: urn:content-classes:message
>Importance: normal
>Priority: normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
>Newsgroups: microsoft.public.biztalk.general
>NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
>Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.biztalk.general:16539
>X-Tomcat-NG: microsoft.public.biztalk.general
>
>Hi,
>
>I have a long-running orchestration, and need to deploy an update to it
>without terminating the existing instances (it's an order-to-invoice, with
>active instances at all stages of the workflow). I decided the best way
was
>to:
>
>1. Update the version number of the orchestration, let's say from V1.0.0.1
>to V1.0.0.2
>2. Deploy 1.0.0.2
>3. Stop the first activate-receive port of 1.0.0.1 (late-bound)
>4. Bind the ports of 1.0.0.2 to the same ones bound to 1.0.0.1
>5. Enlist and start 1.0.0.2 (same host instance as 1.0.0.1)
>6. Un-enlist (but not stop) 1.0.0.1
>7. Start the receive port.
>
>So, everything happens perfectly to begin with. 1.0.0.1 continues to
process
>existing instances, doesn't begin new instances. New instances are instead
>handled by 1.0.0.2. But then, when 1.0.0.2 reaches the "shipment" stage of
>the workflow, it retrieves some data via the SQL adapter. I get this error:
>
>------------
>Received unexpected message type
'KCOrchestrationsSSK.schSQLProteanShipment,
>KCOrchestrationsSSK, Version=1.0.0.0, Culture=neutral,
>PublicKeyToken=b79a0d6956359be3' does not match expected type
>'KCOrchestrationsSSK.schSQLProteanShipment, KCOrchestrationsSSK,
>Version=1.0.0.1, Culture=neutral, PublicKeyToken=b79a0d6956359be3'.
>-------------
>
>So for some reason 1.0.0.2 receives a message with a (strong name schema)
>type matching assembly version 1.0.0.1. The thing is, it only happens with
>one SQL receive location. The SQL receives in the "Order" stage work fine.
>Just one port, and I don't know why!
>
>I can "fix" the problem by stopping and starting the host instance, but
then
>the reverse happens. My Shipment SQL receive fails for 1.0.0.1 instances
>which receive the message schema type 1.0.0.2. Basically the schema strong
>name is always for the wrong assembly version. The SQL schema is in the
same
>assembly as the orchestrations.
>
>Can anyone tell me how to get around this, and also, how it can happen to
>only one port of many? Generally though, I'm trying to find a
straightforward
>way of upgrading long-running orchestrations without terminating instances.
>
>Any pointers would be greatly appreciated.
>
>Many thanks,
>
>Glynn
>
>
.
- Follow-Ups:
- RE: Side-by-Side Deployment Issue
- From: "Doug Girard [MSFT]"
- RE: Side-by-Side Deployment Issue
- Prev by Date: BTS 2004: Envelopes, Message Context, property demotion
- Next by Date: RE: Side-by-Side Deployment Issue
- Previous by thread: BTS 2004: Envelopes, Message Context, property demotion
- Next by thread: RE: Side-by-Side Deployment Issue
- Index(es):
Relevant Pages
|
