sharing resource in applications

I am trying to develop several biztalk applications in bt 2006.

For each application I need to use a shared assembly containing the schemas
to be used. So I created a new shared application in bt 2006, added the
schema resource and referenced this application in the other apps.  But if I
now want to update the schema assembly I get the following error:

Cannot update assembly "CRM.Adapter.Schemas" because it is used by
assemblies which are not in the set of assemblies to update.

And the suggesting to remove the referencing assemblies. How can I get this
to work? I do not want to remove and redeploy all the other assemblies (and
configure etc) every time I need to add a new schema to the shared assembly.
I did a full stop on all applications.

What am I doing wrong?

sharing resource in applications

On Fri, 16 Feb 2007 02:41:00 -0800, Daisy

You are not doing anything wrong. That is the way it works. If you
need to redeploy a BizTalk assembly to the configuration database, and
other BizTalk assemblies depend on it, they must be undeployed first.

Basically, the design best practice is to NOT have all schemas in just
one assembly. You should try to group all schemas, maps, pipelines,
and orchestrations that should be versioned together in one assembly.

If you have a schema that multiple orchestrations use, for instance,
you should put it in its own assembly. But you still need to redeploy
all dependant assemblies. But by splitting your solution up into
several smaller assemblies, there is less running functionality you
need to undeploy.

--
eliasen, representing himself and not the company he works for.

Private blog: http://blog.eliasen.dk

Private email: jan@eliasen.dk

Sharing resources

You are not doing anything wrong. That is the way it works. If you

need to redeploy a BizTalk assembly to the configuration database, and

other BizTalk assemblies depend on it, they must be undeployed first.



Basically, the design best practice is to NOT have all schemas in just

one assembly. You should try to group all schemas, maps, pipelines,

and orchestrations that should be versioned together in one assembly.



If you have a schema that multiple orchestrations use, for instance,

you should put it in its own assembly. But you still need to redeploy

all dependant assemblies. But by splitting your solution up into

several smaller assemblies, there is less running functionality you

need to undeploy.