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.
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 have two BizTalk applications. I updated the source code for 1 of them, checked it in TFS and it's ready to go. I've read that I have to delete the application that's currently there, so I exported msi, and bindings. The application is NOT in the control panel to remove so I went to BizTalk to delete it. I'm getting an error, Delete of ApplicationNode failed and that I have to "Remove assembly, first, it references assembly etc... " I tired to remove the assembly from Resources but it's throwing the same error.
The code change I made was a hard coded address that need updating. I have to go through all of this to update a BizTalk Application?
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.
I have several DNN modules that I wish to update silently, using the portal's built-in module upgrade facilities called from a separate application, in this case a Windows service. I was able to make it all work with version 4.3 of the portal by modifying the DNN source in key areas to allow DotNetNuke.dll to function outside of a web application. I'm now trying to do the same thing with the 4.9.0 source code and I'm having problems.
Everything works fine until DNN tries to read from the database. I have my Windows service project, the DNN library project, and several other related projects loaded in one VS solution (the additional projects are the same ones that are in the main solution file provided with the DNN source). I call PaInstaller.Install in my service to update each module. Execution gets to reflection.vb and then it tries to create a DotNetNuke.Data.SqlDataProvider object based on the type name. It raises an exception when calling System.Web.Compilation.BuildManager.GetType. The exception says:
Could not load type 'DotNetNuke.Data.SqlDataProvider' from assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I read this to mean it simply couldn't locate the DotNetNuke.SqlDataProvider.dll assembly. What's strange is that assembly is in the Bin folder for the DNN library project, and I also have it in the folder where my Windows service is running. The actual SqlDataProvider project is also loaded in the solution. I can't for the life of me understand why the runtime environment can't locate the assembly.
Has anyone tried something like this before, or know what could cause an assembly not to be found while stepping through the DNN source? Am I better off using something other than BuildManager.GetType to get an instance of the SQL provider type?
Chris,
Honestly depending on your needs, I would look at doing this a different way, as this is going to be very fragile with each DNN upgrade that happens in the future.
I'd look more towards using the "bulk install" option that DNN already has. Have your service upload the module zips to the /install/modules folder, then from there, call /install/install.aspx?mode=installresources and you are done!
If you need a third party solution to parse the results, have your windows service go through and pull the HTML response and parse it to validate success.
On page load I am populating my own list object, storing in session & it is getting stored, When I am debugging i can see that list object is stored in session, But When I am reading that session variable in next page, it's throwing error like
The type 'Dispensary.ResourceScheduling.Views.SchedulingPopup' exists in both 'WebApplication.dll' and 'App_Web_6bndsqgu.dll'
So Can u please help me how to resolve this issue.
Thanks in advance.
Do a full rebuild on your project.
If that still doesn't work, delete everything in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\[mywebsite] folder, where [mywebsite] is the name of your project. If the DLLs are locked you will have to stop and restart the website in IIS.
Occasionally I've noticed that Visual Studio gets confused and leaves behind the temporary DLLs. This doubles up your classes but is has nothing to do with session values.
You have corrupted .NET temporary files. Before the full rebuild or anything else, do a "Clean Solution". This reliably cleans up .NET temporary files, plus any other accumulated sludge.
Corrupted .NET temporary files can occur from a number of situations, most notably editing binding expressions mixed into markup in .aspx pages. The key to identifying .NET temporary file problems is an obfuscated file name, such as "App_Web_6bndsqgu.dll". Problems can include duplicate .dlls (as noted), inability to find or load some pages and services dynamically (ASP.NET-hosted WCF services are vulnerable to this), and more. So "clean solution" is the first thing to reach for when any of these happen.
When working with source control, it's my basic practice now to do "get latest", "clean solution", and "rebuild solution" before any further work.