Its a shame that pipeline components do not follow the same flexible
deployment model as the rest of BizTalk e.g. schemas, orchestrations.

Does anyone know why they have a different deployment model? Pipeline
components are just as likely to change as orchestrations. Copying the
pipeline assembly in to the "Pipeline Components" folder is rather limiting.

[ Post a follow-up to this message ]

A pipeline component project is NOT a BizTalk project, it is a regular .NET
class library project. I find it rather easier to work with pipeline
components because they don't need to be deployed. They need to be in the
Pipeline Components directory, I think it is because of the Pipeline
Designer, but I am not sure.

"Xerox" <info@thinkscape.com> wrote in message
news:O6gw1TcGFHA.552@TK2MSFTNGP12.phx.gbl...
> Its a shame that pipeline components do not follow the same flexible
> deployment model as the rest of BizTalk e.g. schemas, orchestrations.
>
> Does anyone know why they have a different deployment model? Pipeline
> components are just as likely to change as orchestrations. Copying the
> pipeline assembly in to the "Pipeline Components" folder is rather
> limiting.
>
>

[ Post a follow-up to this message ]

The axe I have to grind with BizTalk is when rolling out upgrades to a
pipeline component... we can't make use of the standard BizTalk deploy
feature nor the GAC. Yet, pipelines are just as an integral part of a
BizTalk solution as orchestrations, schemas.

"Michel Prévost" <michel.prevost_TAKEOUTTHISPART@cactuscommerce.com> wrote
in message news:OAwZXMdGFHA.332@TK2MSFTNGP10.phx.gbl...
> A pipeline component project is NOT a BizTalk project, it is a regular
.NET
> class library project. I find it rather easier to work with pipeline
> components because they don't need to be deployed. They need to be in the
> Pipeline Components directory, I think it is because of the Pipeline
> Designer, but I am not sure.
>
> "Xerox" <info@thinkscape.com> wrote in message
> news:O6gw1TcGFHA.552@TK2MSFTNGP12.phx.gbl... 
>
>

[ Post a follow-up to this message ]

True, but pipeline components are not as likely to have a need to have
different versions running at the same time.  If your decryption component
has a bug, chances are you want to fix it and apply the changes, not have
bugs in some pipelines.

Now, that is not to say that all pipeline components meet that requirement,
but most will.  One thing to consider if you have application dependencies
is whether you have created your component in the proper way.  You should be
able to make your pipeline components generic enough that the dependencies
are more on the configuration of your send and receive pipelines than on the
component itself.

My $.02.

Matt


"Xerox" <info@thinkscape.com> wrote in message
news:e3POBFeGFHA.904@tk2msftngp13.phx.gbl...
> The axe I have to grind with BizTalk is when rolling out upgrades to a
> pipeline component... we can't make use of the standard BizTalk deploy
> feature nor the GAC. Yet, pipelines are just as an integral part of a
> BizTalk solution as orchestrations, schemas.
>
> "Michel Prévost" <michel.prevost_TAKEOUTTHISPART@cactuscommerce.com> wrote
> in message news:OAwZXMdGFHA.332@TK2MSFTNGP10.phx.gbl... 
> .NET 
>
>

[ Post a follow-up to this message ]

Valid viewpoint Matt. We are using pipeline components to promote certain
portions of filenames so that we can corellate on them. I am pinning my
hopes on the fact that the requirements surrounding that won't change
often - which I am confident that they won't. But when considering the
impact of rolling out a change to a pipeline component I thought it odd that
the approach is inconsistent with the norm - the end result is that I will
always be careful to consider their use.

"Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
news:eQ3Oi8hGFHA.3612@TK2MSFTNGP09.phx.gbl...
> True, but pipeline components are not as likely to have a need to have
> different versions running at the same time.  If your decryption component
> has a bug, chances are you want to fix it and apply the changes, not have
> bugs in some pipelines.
>
> Now, that is not to say that all pipeline components meet that
requirement,
> but most will.  One thing to consider if you have application dependencies
> is whether you have created your component in the proper way.  You should
be
> able to make your pipeline components generic enough that the dependencies
> are more on the configuration of your send and receive pipelines than on
the
> component itself.
>
> My $.02.
>
> Matt
>
>
> "Xerox" <info@thinkscape.com> wrote in message
> news:e3POBFeGFHA.904@tk2msftngp13.phx.gbl... 
wrote[vbcol=seagreen] 
the[vbcol=seagreen] 
the[vbcol=seagreen] 
>
>

[ Post a follow-up to this message ]