One of the weird BizTalk errors that's been around since version 2004 goes something like this:
Error 35
symbol 'MyNamespace.DataObject' is already defined; the first definition is in assembly c:\Development\Library\MyObjects.dll
C:\Development\Examples\BizTalk\ObjAlreadDefined.odx 169 50
symbol 'MyNamespace.DataObject' is already defined; the first definition is in assembly c:\Development\Library\MyObjects.dll
C:\Development\Examples\BizTalk\ObjAlreadDefined.odx 169 50
This error has been blogged about several times. Example 1 Example 2
The standard "fix" is to remove the C# code that is found at the end of the orchestration file by:
The standard "fix" is to remove the C# code that is found at the end of the orchestration file by:
- Open the orchestration in notepad or as XML
- Find (Ctrl-F) #endif // __DESIGNER_DATA
- Delete all of the code found below #endif // __DESIGNER_DATA
- Save and Recompile
Recently, I discovered a critical issue with that fix.
The code that you are removing is the code that allows BizTalk to export that orchestration as a public object.
So if you use the standard fix, you can't call the orchestration from another orchestration.
The code that you are removing is the code that allows BizTalk to export that orchestration as a public object.
So if you use the standard fix, you can't call the orchestration from another orchestration.
I believe that I have found the root of the problem and a much simpler fix.
The "Already Defined" object in my example is a reference object called MyNamespace.DataObject.AbstractDatawhich is defined in MyObjects.dll. This object is used to create a varible instance called DataObject.
If I rename the variable DataObject to DataObject_AbstractData the compile issue goes away.
The "Already Defined" object in my example is a reference object called MyNamespace.DataObject.AbstractDatawhich is defined in MyObjects.dll. This object is used to create a varible instance called DataObject.
If I rename the variable DataObject to DataObject_AbstractData the compile issue goes away.
IMHO, when a Web Reference is added to the project, the orchestration compiler is no longer able to distinguish between part of a namespace and a variable instance of the same name.
So the moral of the story is to make sure your variable names don't conflict with any part of a namespace that in reference by your project. This "rule" goes for any variable.
No comments:
Post a Comment
Post Your Comment...