Hi

A guy (I think it is a guy, anyways :-) ) on the microsoft.public.biztalk.orchestration newsgroup has a problem with this issue. And since I had the issue myself a long time ago, and always wanted to write a quick blog entry about it, this seemed like a perfect time for it :-)

A quick note: This issue appears on both BizTalk 2004 and BizTalk 2006.

So basically, the problem is: When compiling a BizTalk project, you get the "'projectname.orchestrationname': cannot resolve imported 'service'" error. This occurs when you are compiling a project that has an orchestration inside it, that calls another orchestration in another project that again calls an orchestration in a third project. Confused? I bet! I will give you details, screenshots and explanations in just a few lines.

The quick answer is: The project you are trying to compile must reference the third project.

BUT, to the long answer:

I have created a solution with three projects:

• ProjectA with ABCSchema.xsd and OrchestrationA.odx
  • Orchestration A does this
    • Receive a message of type ABCSchema.xsd
    • Initialize a string variable to receive the value from a distinguished field in ABCSchema
    • Write the value to the eventlog
    • Call OrchestrationB
• ProjectB with OrchestrationB.odx
  • Orchestration B does this:
    • Receive the string parameter from OrchestrationA
    • Write the value to the eventlog
    • Call OrchestrationC
• ProjectC with OrchestrationC.odx
  • Orchestration C does this:
    • Receive the string parameter from OrchestrationB
    • Write the value to the eventlog

Screenshots:

The (very small) schema:

OrchestrationA:

OrchestrationB:

OrchestrationC:

No hokus pokus at all!

In order to call OrchestrationC from OrchestrationB, I added a reference to ProjectC from ProjectB. Both ProjectB and ProjectC compile just fine.

In order to call OrchestrationB from OrchestrationA, I add a reference to ProjectB from ProjectA, but ProjectA wont compile. I get this error:

The famous "cannot resolve imported 'service'" error.

BUT, referencing ProjectC from ProjectA solves this issue, and I can compile just fine.

Actually, the error description indicates it. When compiling ProjectA, it can't import the "ProjectC.OrchestrationC" service. But often, you are maybe compiling the entire solution, and you just see that the file in quesion is projectb.dll. But the error just states that ProjectA cannot import ProjectC.OrchestrationC, which it needs to according to projectb.dll.

Should anyone think that it is really silly that ProjectA needs to reference a dll that another dll references and that this breaks all nice architectures, I would agree. If someone gives me a set of 20 dll's that make up a nice solution he/she has made, and I need to call an orchestration in one of them, then I also need to reference all the dll's that this one dll references, assuming there are internal "Call Orchestration"s between these dll's. I will need to know how these dll's reference eachother in order to reference one of them. Really silly, indeed.

I don't know why they have made it like this, but they have.

I hope this post helps others.

Should you have comments, please don't hesitate... My three projects can be found here: A_calls_B_calls_C.zip (137,08 KB)

--

eliasen

Hi

I ran into this one a while ago. I couldn't find any information about the error on the internet, so I tried the microsoft public newsgroups. Again, no help (although those newsgroups are a GREAT place for getting help...). Anyway, I found out, what the error was, and it can probably be found in google groups by now, but I thought I'd just share it here as well.

Basically, the problem was that BizTalk 2004 SP1 apparently has a bug. If you have a "Call Orchestration"-shape (or a "Start Orchestration"-shape) in your orchestration, and this shape is placed in some particular unreachable code, you get this error.

I had a decision shape in my orchestration, but I hadn't gotten around to deciding what the rule in the decision shape was going to be. So I entered "1 == 1" in order for the assembly to compile and then I could deploy it and test it for that branch of my decision shape. Then, I wanted to test the other branch, still not knowing what the final rule would be. So I modified the orchestration to have the rule to be "1 != 1" - but then I couldn't compile - weird, eh?

Below is my orchestration.




So, as you can see - no funny stuff. Another weird thing is, that I can compile just fine with my "Call Orchestration"-shape after a Terminate-shape. But that is unreachable code as well.

I don't know what is happening, but it sure is weird.

I hope this posting has helped some of you.

You can find a copy of my project here: CompileErrorWhenDecisionShapeRuleIsFalse.zip (59.09 KB)

Let me know if you have any comments.

--
eliasen