RE: Side-by-Side Deployment Issue
- From: dogirard@xxxxxxxxxxxxxxxxxxxx ("Doug Girard [MSFT]")
- Date: Fri, 09 Sep 2005 22:48:15 GMT
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/deploying/h
tm/ebiz_depl_assemblies_wzyq.asp
HTH,
Doug Girard [MSFT]
Note: This posting is provided "AS IS" with no warranties, and confers no
rights.
--------------------
>X-Tomcat-ID: 473339490
>References: <75D01552-B59C-4181-81CA-F37B6E8E7720@xxxxxxxxxxxxx>
>MIME-Version: 1.0
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>From: dogirard@xxxxxxxxxxxxxxxxxxxx ("Doug Girard [MSFT]")
>Organization: Microsoft
>Date: Fri, 09 Sep 2005 22:03:08 GMT
>Subject: RE: Side-by-Side Deployment Issue
>X-Tomcat-NG: microsoft.public.biztalk.general
>Message-ID: <gEtxFpYtFHA.780@xxxxxxxxxxxxxxxxxxxxx>
>Newsgroups: microsoft.public.biztalk.general
>Lines: 145
>Path: TK2MSFTNGXA01.phx.gbl
>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.biztalk.general:17413
>NNTP-Posting-Host: TOMCATIMPORT1 10.201.218.122
>
>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
>>
>>
>
>
.
- References:
- RE: Side-by-Side Deployment Issue
- From: "Doug Girard [MSFT]"
- RE: Side-by-Side Deployment Issue
- Prev by Date: RE: Side-by-Side Deployment Issue
- Next by Date: SQL receive Location
- Previous by thread: RE: Side-by-Side Deployment Issue
- Next by thread: SQL receive Location
- Index(es):
Relevant Pages
|
