In one of my project, the developer forgot to check in the changes done to biztalk orchestration but the changes were delivered and installed in production server. I would like to know the best way to get the Biztalk orchestration source code from MSI file/Biztalk. I have read a thread about using a Decompile too but not sure how to get the source code.
Another option is to BizTalk documenter for 2006, 2010 (and soon to be released BizTalk 2013) and generate a help file that documents the Orchestration.
Update: Both of the version above are no longer being supported. The latest versions of BizTalk Documenter for BizTalk 2006 through BizTalk 2013 R2 can be found here
Full Disclosure: I'm one of the developers on this new version.
While you can't decompile to the original Project, you can extract the 'source' files for the artifacts themselves. They're included in the assembly as string resources.
So, once you find the Orchestration source, save that as a .odx in a new Project.
Update:
Note that
The ODX code will be in a private const string _symODXML. Copy that string.
The string will has a lot of \n through it, remove those. After this it should be valid XML.
The string starts at <?xml and finishes at </om:MetaModel> whereas the ODX has some bits before and after that string. So you need to paste into the ODX file so that you replace the central part that matches it in the ODX file and leaving the parts before and after it intact.
Related
First and foremost I would like to draw your attention to this:
That's because I have been to all of those links. I've tried those suggestions (I'll get into that). I've even been to the second page of Google.
I'm working on an existing setup which I think I might have broke when I imported bindings from another server without backing up the current bindings. When the imported bindings failed I had nothing to revert to. My bad, I know you are always supposed to back things up but this time I did not. Anyways, or maybe the bindings have nothing to do with any of it, I really don't know.
When executing a stored procedure it says This Assembler cannot retrieve a document specification using this type: "http://Foo.Bar.SQLIO#A_sqli". Now the namespace and database server are covered up here but trust me, they are correct.
Now this is where people will insist the only possible reason this ever happens is either:
There is a namespace collision and you have to explicitly specify the strong name.
The assembly is not in the GAC.
So let's talk about 1 first... So I'm gonna grab the SchemaStrongName, AssemblyName AKA Foo.Bar.SQLIO, Foo.Bar, Version=1.5.0.0, Culture=neutral, PublicKeyToken=585b3f1e468ca8f5 and paste that into the DocumentSpecNames of the XMLTransmit Send pipeline on the Send Port.
Now I rerun and the namespace ambiguity/collision/problems should be gone but they are not. Instead I get a new error which basically says the same thing.
Okay but I am pretty sure that the schema exists exactly once and the dll is deployed to the GAC correctly. Why? Several reasons:
First, the schema is listed only once. .
I can further validate that by programmatically referencing the assembly in a standalone console app, and printing the schema to a file.
static void Main(string[] args)
{
var x = new Foo.Bar.SQLIO();
Console.WriteLine(x.XmlContent);
File.WriteAllText(#"C:\Users\CoolSean\Desktop\OUT-OF-ASSEMBLY.xsd", x.XmlContent);
}
As for the dll being in the GAC I can verify that with gacutil -l Foo.Bar and it is there. If I do gacutil -u Foo.Bar and restart the host instances it fails because it can't find the assembly, meaning I am poking at the right assembly. It does exist and it does contain the schema and even the BizTalkMgmtDb database knows about it.
What can I do to run this down? I've got a working copy of this BizTalk application on another server and I setup a SQL Profiler trace on the broken box and the working box. The database calls are identical right up until the broken box starts logging errors about how it can't find that schema. idk man. What if I recompile Foo.Bar.dll such that it writes to a file any time anyone calls any of its methods. That would tell me ....something. Maybe. Probably not. I'm out of ideas.
I am having some trouble with BizTalk saying a schema doesn't exist when it does exist.
I can see it in the BizTalkMgmtDb using
select * from bt_documentspec where msgtype like '%myschema%'
I can see it in the BizTalk Server Administration Console > <All Artifacts> > Schemas > My Schema.
This paragraph is optional. I'm only including it so you know I already tried the answer you get when you google this problem.
The exact error message I get is something like "This Assembler cannot retrieve a document specification using this type" which if you google that tells you the schema is either not deployed or the root element you're using exists in two separate namespaces so you should supply a DocSpecName on the SendPorts XMLTransmit 1 2.
I've also tried reinstalling the dll that contains the problem schema into the GAC as per the answer to this question. That didn't work either but now I have more questions anyways.
if I do gacutil -l none of my assemblies are listed there.
So I was wondering what does this even do?
Because those assemblies are not listed under gacutil -l. Also when you look at those assemblies
it shows a source location and a destination location.
Why? Why not just THE location? I can't even find %BTAD_InstallDir% on my computer so there are a minimum of 4 possible locations where this schema dll might be.
source location
destination location (%BTAD_InstallDir%)
"the GAC"
wherever it actually is because there doesn't seem to be a %BTAD_InstallDir%.
So if I want to "update the GAC" to make sure this schema is there how do I do that? What dll is BizTalk ACTUALLY using? The one in %BTAD_InstallDir% or the one in the GAC?
BizTalk 2010.
It has nothing to do with where the DLL is, it has to do with the fact that either
The XML payload namespace and root node does not match any schema
You have two or more schemas with exactly the same namespace and root node that match.
If you don't have any namespace on the XML, then it will try and match on Root node only, but again if you have more than one schema with the same root node, it will fail.
What you need to do is look at the suspended message and look at it's context properties and see what it's Message Type is, and compare that against the schema in BizTalk. There should be exactly one that matches.
vs
But to answer your question,
The source location is usually just the path of where the DLL was when it was initially imported in Dev.
the %BTAD_InstallDir% is the directory you chose when importing a MSI, the default location is C:\Program Files (x86)\Generated by BizTalk. However that is just where it puts it initially
Yes, in the end the actual one it uses will be in the GAC, which is under C:\Windows\Microsoft.NET\assembly\GAC_MSIL
Note: If the DLL has been previously been deployed and you are deploying a new one then make sure you restart the host instances afterwards, as it will cache DLLs in memory for a period.
We are updating a BizTalk 2009 application that I inherited. I'm converting them into BizTalk 2013 R2.
I get the following reasonably famous error, when I try to re-compile
Exception Caught: Cannot load source/destination schema: MyCompany.Schema.AppConfig.
Either the file/type does not exist, or if a project dependency exists, the dependent project is not built.
There are only two posts in SOF related to this error:
Biztalk Map Destination Schema Imports Multiple Schemas
Reference trouble with BizTalk schema project in Visual Studio 2008
and only a few meaningful posts in elsewhere.
The solution has 4 projects organized as follows:
Common (contains an 1 schema AppConfig.xsd file)
Orchestration (1 Orchestration file)
Schema (references an ASMX web service)
Map (1 map file, references Schema and Common Projects)
The Map project attempts to translate an source message of type AppConfig to the type AppConfigBE which is one of the Complex Types in the Web Service.
I keep getting the compile time error above.
Tried all of the following, as recommended in the two SOF posts, and a few other posts on MSDN forums, but none of it worked.
Tried alternating Copy Local on the Maps project (From true to false, and vice-versa)
Tried Replacing schema on source and destination on the map file
Schemas are referenced using fully qualified .Net type name
Tried referencing the .dll as opposed to the Schema and Common projects.
Updated the web reference; also removed and re-added the web references
Is there a solution/hot fix etc for this? Any other suggestions I can try?
UPDATE 1:
We had to call Microsoft for help; the engineer took my project file to try on their computers; he said they too had the same problem and as a fix, recommended to set the Build Action property of the .BTM map file to None instead of BTSCompile. After this, the project builds successfully. He said to test the project with this build and let them know. What I'm not sure is, what are consequences of this? Many topics on Build Action refers to the schema files, not the map files in a BTS project. What is the standard Build Action for Map files?
One more item is to clear any Assemblies from the GAC or re-GAC them with a Post-Build script.
I ran into the same problem. I needed to add
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.XLANGs.BTXEngine;
[assembly: Microsoft.XLANGs.BaseTypes.BizTalkAssemblyAttribute(typeof(BTXService))]
to the AssemblyInfo.cs into the project.
Usually we need to modfiy the code for new requirements, then rebuild the project and gac the dll files modfied on the biztalk server, that way works fine before last month. Now I find that's not enough, I have to add the dll files mannully by 'Add resource' and then everything goes well as before. I got no idea about that as I took over the biztalk 2006 project rencently but I know nothing about that before.
I read the ms document How to Add a BizTalk Assembly to an Application, I found a problem when excute 'BTSTask AddResource /ApplicationName:MyApplication /Type:System.BizTalk:BizTalkAssembly /Overwrite /Source:"C:\BizTalk Assemblies\MyOrchestration.dll" /Destination:"C:\New BizTalk Assemblies\ MyOrchestration.dll "', an error prompt that I must unenlist the orchestrations before add the assmebly just like what I do 'Add resource' manully.
Is there a way to add modfied dll files by just using 'gacutil.exe /i' as I do before?
Whether or not you can "sneak" a new Assembly in depends on several factors. However, in no cases is this a supported production operation.
If only the internals of an Artifact have changed, Schemas and Maps being the least complicating, you can usually get away with it, in DEV only. But if any interface (Ports) or definitions (Schema/Message Type) changes, you have to remove and redeploy.
So, sorry to say, but you've probably just been lucky up to now.
I imported a Form object from a text file. When I try to compile it I get the following error message:
This message is for C/AL programmers:
The OLE control or Automation Server identified by 'Microsoft Common Dialog Control 6.0 (SP3)'.CommonDialog requires a design time license.
This license cannot be obtained.
Make sure that the OLE control or Automation server is installed correctly with an appropriate license"
I am developing in Dynamics NAV using a developer license. The OCX is registered correctly, gets listed in NAV's "Custom Controls" as pointing to "C:\Windows\SysWOW64\comdlg32.ocx".
Why am I not allowed to compile the object?
The license in question is, as you said, purely for using the CommonDialog component in design-time environments. This has nothing to do with your NAV license or your customers being able to run code that uses the component. The design-time license (which is nothing more than a key in your system registry; not an actual license file) used to get installed with e.g. Microsoft Visual Basic 6.0 or older versions of Microsoft Visual Studio.
If you have access to VB6.0 or VS2005, you can use VB6Controls.reg on the installation disk as described here: http://support.microsoft.com/default.aspx?scid=kb;en-us;318597.
As the message said, the components loads, try to get a license and don't get one. So you don't have one as it says or you don't have it in the path lookup the components looks at it.
There is one more trick you can do to fix this problem and avoid installing a lot of crap like VB6.0.
This message is related to certain automation type variable in the object you trying to compile.
You can copy this variable from any other compiled object in other database or any other compiled object in the same database. And then your imported object will magically compile. Just delete the variable from your imported object's variable list and copy it from compiled object with copy-paste.
I don't know what magic is that but it worked for me many times. I copied variable from the same object in restored backup of the database.