Question, I just had an error that my assembly (deployed to BizTalk) could
not be found when I posted a message to my port exposed as a web service. In
an older Usenet posting I found the solution, add your assembly to the GAC.

Now my question, why do I need to deploy my assembly into BizTalk, AND into
GAC before it works? Does this mean that when I redeploy a working assembly
via VS.NET it will still use the older assembly version deployed into the
GAC to process the orchestration when called to an Web service?

So new scenario is, get a working assembly and orchestration receiving msg
through an exposed web service port.

On every update/redeploy of the orchestration,

1)stop and unlist and terminate orchestration.

2)redeploy via VS.NET and BizTalk explorer

3)remove assembly from GAC

4)add new version of assembly to GAC

5)start and enlist orchestration (and bind if required)

Looks like a hell of a job when developing orchestrations in this ridicules
under-documented product..

[ Post a follow-up to this message ]

yes you need to deploy into the GAC.  When you deploy to biztalk, you are
deploying meta data, including the strong name of the assembly.  biztalk
uses this strong name to load the assembly from the GAC.  If you are using
VS.net, then on the properties page for your biztalk project, you can
indicate that deploy should deploy to your GAC as well.  Then you don't have
to do this manually during development.

The following are the documentation links that most closely relate to this.
This stuff is documented pretty well know that the April 2 update was
released.

ms-help://BTS_2004/Deploying/htm/ebiz_depl_assemblies_ehph.htm
ms-help://BTS_2004/Deploying/htm/ebiz_depl_assemblies_kann.htm

Matt


"caviar" <caviar-at-xsfourall.nl> wrote in message
news:%23zTcTLDLEHA.1144@TK2MSFTNGP12.phx.gbl...
> Question, I just had an error that my assembly (deployed to BizTalk) could
> not be found when I posted a message to my port exposed as a web service.
In
> an older Usenet posting I found the solution, add your assembly to the
GAC.
>
> Now my question, why do I need to deploy my assembly into BizTalk, AND
into
> GAC before it works? Does this mean that when I redeploy a working
assembly
> via VS.NET it will still use the older assembly version deployed into the
> GAC to process the orchestration when called to an Web service?
>
> So new scenario is, get a working assembly and orchestration receiving msg
> through an exposed web service port.
>
> On every update/redeploy of the orchestration,
>
> 1)stop and unlist and terminate orchestration.
>
> 2)redeploy via VS.NET and BizTalk explorer
>
> 3)remove assembly from GAC
>
> 4)add new version of assembly to GAC
>
> 5)start and enlist orchestration (and bind if required)
>
> Looks like a hell of a job when developing orchestrations in this
ridicules
> under-documented product..
>
>
>

[ Post a follow-up to this message ]

"Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
news:%23dWOASFLEHA.2456@TK2MSFTNGP12.phx.gbl...
> yes you need to deploy into the GAC.  When you deploy to biztalk, you are
> deploying meta data, including the strong name of the assembly.  biztalk
> uses this strong name to load the assembly from the GAC.  If you are using
> VS.net, then on the properties page for your biztalk project, you can
> indicate that deploy should deploy to your GAC as well.  Then you don't
have
> to do this manually during development.
>
> The following are the documentation links that most closely relate to
this.
> This stuff is documented pretty well know that the April 2 update was
> released.
>
> ms-help://BTS_2004/Deploying/htm/ebiz_depl_assemblies_ehph.htm
> ms-help://BTS_2004/Deploying/htm/ebiz_depl_assemblies_kann.htm
>
> Matt

Ok thnx,

but I keep getting the idea that my orchestration is not running the final,
just deployed, version of my assembly sometimes...

Aslo after re-deploying a working version of a orchestration, the receiving
port of the webservice faiels with this message:

Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5683
Date:  27/04/2004
Time:  15:10:59
User:  N/A
Computer: HLBIZTALK
Description:
The Messaging Engine did not recognize the
InboundTransportLocation:"/Pms2004.Demo1_Proxy/Pms2004_Demo1_Demo1OrchPermit
Request_WSPort.asmx". Check the receive location configuration.

I then go around and stop-start several things till it suddenly works
again.. I'm working on this biztalk now for several days, but still cannot
explain (nor find tutorials which do step by step setting things up instead
of firing a couple of scripts and voila it works) in which order I should
build an orchestration from scratch which publish some receive ports as
webservices.

regards
hjm

[ Post a follow-up to this message ]

You might be running into a .net issue, not biztalk specific.  If you are
deploying the same version of your assembly to the GAC, any running
processes that have the old one loaded into memory will continue to use that
one.  To remedy this you  can do one of two things.

1) restart the biztalk host when you redeploy
2) increment your version number each time you deploy

Matt


"caviar" <caviar-at-xsfourall.nl> wrote in message
news:ud8QhpFLEHA.3012@tk2msftngp13.phx.gbl...
>
> "Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
> news:%23dWOASFLEHA.2456@TK2MSFTNGP12.phx.gbl... 
are[vbcol=seagreen] 
using[vbcol=seagreen] 
> have 
> this. 
>
> Ok thnx,
>
> but I keep getting the idea that my orchestration is not running the
final,
> just deployed, version of my assembly sometimes...
>
> Aslo after re-deploying a working version of a orchestration, the
receiving
> port of the webservice faiels with this message:
>
> Event Type: Error
> Event Source: BizTalk Server 2004
> Event Category: BizTalk Server 2004
> Event ID: 5683
> Date:  27/04/2004
> Time:  15:10:59
> User:  N/A
> Computer: HLBIZTALK
> Description:
> The Messaging Engine did not recognize the
>
InboundTransportLocation:"/Pms2004.Demo1_Proxy/ Pms2004_Demo1_Demo1OrchPermit
> Request_WSPort.asmx". Check the receive location configuration.
>
> I then go around and stop-start several things till it suddenly works
> again.. I'm working on this biztalk now for several days, but still cannot
> explain (nor find tutorials which do step by step setting things up
instead
> of firing a couple of scripts and voila it works) in which order I should
> build an orchestration from scratch which publish some receive ports as
> webservices.
>
> regards
> hjm
>
>
>

[ Post a follow-up to this message ]