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.
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.
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 am adding this item in the ItemGroup in the project wpp.targets file.
<MsDeploySourceManifest Include="setAcl">
<Path>%windir%\TEMP</Path>
<setAclUser>IIS_IUSRS</setAclUser>
<setAclAccess>Read,Write,Modify</setAclAccess>
<setAclResourceType>Directory</setAclResourceType>
<AdditionalProviderSettings>setAclUser;setAclResourceType;setAclAccess</AdditionalProviderSettings>
</MsDeploySourceManifest>
and this on the parameter section
<MsDeployDeclareParameters Include="TempFolderPermissionSetAclParam">
<Kind>ProviderPath</Kind>
<Scope>setAcl</Scope>
<Description>Add read, write permission for IIS_IUSRS to the temp folder.</Description>
<DefaultValue>%windir%\TEMP</DefaultValue>
<Value>%windir%\TEMP</Value>
<Tags>Hidden</Tags>
<Priority>$(VsSetAclPriority)</Priority>
<ExcludeFromSetParameter>True</ExcludeFromSetParameter>
</MsDeployDeclareParameters>
it generate this line in the manifest xml file
but there is an error message says:
Error: A value for the 'setAclUser' setting must be specified when the 'setAcl'
provider is used with a physical path.
what's missing here?
It's been a while since you asked this, but on the surface this looks more or less correct: the key point for specifying an absolute path are that you include setAclUser in the AdditionalProviderSettings, as well as an element for setAclUser.
Ultimately, while your SourceManifest file might appear correct when you build the package, what seems to matter though is the setAclUser settings on the setAcl elements within the archive.xml file contained within the zip that is created. Open that up and ensure that the value you expect for setAclUser is present.
As well, Visual Studio makes liberal use of caching where MSBuild files are concerned; practically speaking it seems that Visual Studio will respect changes made only to pubxml files and project files such as csproj. When making changes to any other target files, you should close Visual Studio and reopen after making each edit. This could explain why your seemingly-correct solution wasn't working: it might have simply been stale target file caches.
I have a Biztalk application that is basically a housing for a schema that other applications are using. I now want to remove this application, but am unable to from the BizTalk Server Admin Console, when I right-click --> Remove I get an error that says
Could not load file or assembly <assembly_name>.dll or one of its dependencies. The system cannot find the path specified (mscorlib)
followed by:
The system cannot find the path specified (Exception from HRESULT: 0x80070003)
So I go to remove the assembly from the Application and get the exact same error. I remove all references to it in other biztalk resources and still the same error when trying to delete the application or resource. I did notice that in the Modify Resouces dialog of referencing assemblies, this rogue assembly is listed as a dependency status of Not Found.
The strange thing is, when Messages come through, the resources which depend on the rogue assembly, still work fine and no errors are thrown (despite them using components of the assembly which shows as Not Found).
I have made sure to check the GAC and the assembly is loaded to it.
So now I have to ask:
where is Biztalk actually looking for this assembly?
is there a way I can just force a deletion of this application?
why does it care if the assembly is not found, when I'm trying to delete it?
why does it show as Not Found, yet still work?
Thanks.
I think the key is "or one of its dependencies." If it's a dependency it may be using the standard windows mechanism for finding a dll. It searches the current directory and the windows directory for them.
"where is Biztalk actually looking for this assembly?"
Look in the 'resources' section of your application in the biztalk management console. It shows a column with the location of the assembly.
I'd stop all the host instances/orchestrations, and then unload all your stuff from the GAC - if messages are actually still going through then stuff is still loaded that is using your schema.