Error when compiling orchestration project

This is driving me nuts and I hope someone can help. I have a orchestration project and one of the orchestration uses request-response direct bound ports. Message sent to this port will be transformed to a wcf request on a send-receive port configured in the biztalk application. In the orchestration request-response port I am trying to catch faults so right clicked the operation and clicked "New Fault Message". This new fault is of the type "BTS.soap_envelope_1__1.Fault"

Now when I compile the project, I am getting compile error

Error 522 The type or namespace name 'soap_envelope_1__1' does not exist in the namespace 'MyNameSpace' (are you missing an assembly reference?) [Orchestration project path]\obj\Debug\BizTalk\XLang\File0.cs 

I have verified that the project contains a reference to Microsoft.BizTalk.GlobalPropertySchemas dll

I would appreciate any help.

September 14th, 2012 12:17am

Hi,

What is the namespace of your project? Is it "BTS" ? Or a namespace ending with "BTS"? You seem to have a namespace clashing problem.

Francois

http://www.malgreve.net

Free Windows Admin Tool Kit Click here and download it now
September 14th, 2012 12:25pm

Hi Francois,

Yes "BTS" is part of my namespace. Right now I am trying to get rid of this namespace and see if the error goes away.

Is there anything else I should be aware of?

September 14th, 2012 6:21pm

Hi,

I ever had problem when the last part of a namespace was conflicting with a class name. I know that this is not exactly the same as your problem, but there are limitation in XLang/s which are not always obvious due to the fact that it looks so much like C#.

So is "BTS" the last part of your namespace?


Free Windows Admin Tool Kit Click here and download it now
September 14th, 2012 6:48pm

"BTS" is smack in the middle of the namespace. As an example our namespace is ABC.BTS.some.something.somethingelse

Btw I tried to get rid of the BTS portion of the namespace from all the orchestrations in the project. I also updated default namespace on the project to not include BTS, but the problem persists.

September 14th, 2012 6:58pm

Okay then I am out of option for you. I have used the BTS.soap_envelope_1__1.Fault schema numerous times and never had a problem with it.

Sorry :(

BTW, I guess that in your error message in your original post, 'MyNameSpace' is the namespace of your project isn't it? So it looks like Visual Studio is confused with an existing type in your project as it looks for the Fault schema in YOUR namespace (which is odd).

Also, did you have a look in the c# file generated? You might get some clues from something there. 

Maybe another option for your to find out what is the problem is to create a new empty BizTalk project, create a dummy port, add the fault  message to the port and see if it compiles. It definitely should and then take it from there.

Hope this helps you,

Francois

Free Windows Admin Tool Kit Click here and download it now
September 14th, 2012 7:30pm

Yes I have created a test project, created a request-response port and added a fault and this project compiles just fine.

At this point I am pretty confident that namespace of my project is causing this compile error, just don't know how to work around it.

September 17th, 2012 6:21pm

Hi,

This is what I originally thought, namespace issue. Now that I think of it, it might not even need to be just the last bit of the namespace to make problem. I unfortunately don't really have to time now to demonstrate it or investigate it further but it is very possible.

Anyhow, for your problem at hand, I am afraid that you will be left with no choice but to change your namespace. I have never been able to work around it.

I learned this the hard way as well and since then I am always careful when choosing my namespace. I avoid any reserved words. Also when using .Net libraries in your BizTalk project, never give your class the same name as part of your namespace.

Moreover, for schema namespace, I would avoid anything listed here:

For now that is all I can advise you. If someone else has a work around or proper explanation I would be glad to hear about it as well.

Good luck!

Francois

  • Marked as answer by BizTalkAdmin Monday, September 17, 2012 6:41 PM
Free Windows Admin Tool Kit Click here and download it now
September 17th, 2012 7:03pm

I have updated namespace of all the orchestrations in the project to get rid of "BTS". I have also updated default namespace (not that this should make a huge different) and assembly name (again per me not a game changer). No difference, still get the same compile time error. I guess just another kink that I stumbled upon.

I am going to have to take a different approach now, may be try a solution with dynamic port that subscribe to fault message types.

Thanks for your help Francois.

  • Marked as answer by BizTalkAdmin Monday, September 17, 2012 6:41 PM
September 17th, 2012 9:41pm

Hi,

This is quite frustrating. Did you ask a colleague? If you are the sole BizTalk developer, you can send me your solution and i can have a look at it in my spare time. You can contact me at http://www.malgreve.net/contact/

The really frustrating part is that I have used that message type dozens of times without a problem.

Cheers,

Francois

Free Windows Admin Tool Kit Click here and download it now
September 18th, 2012 3:34am

Having experienced this very problem with my File0.cs when compiling an orchestration, I eventually solved it by changing the way I structured my namespaces. It looks like in Xlangs the namespaces can be short circuited such that an item called one.two.three.Item1 can be referenced by a shorter form of three.Item1 or two.three.Item1, which seems rather bizarre.

So an item physically located in namespace two.three.Item2 will not be found during compilation in an orchestration which lives in namespace one.two.three even if you have a reference to the assembly that contains two.three.Item2 - hope that makes at least some sense as it confuses me just typing it up.

Those were my findings or perhaps I've fundamentally missed something that seems to manifest itself in this way but it looks like a namespace that contains another: "one.two.three" contains "two.three",  in Xlangs is simply two different forms of the same thing - this seems insane and I hope i'm wrong.

February 20th, 2015 5:06pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics