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?
Related
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 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 am using a COM dll in my .Net web application. This works fine on multiple different machines.
However on one particular machine I get the following error:
Unable to cast COM object of type 'CServer.CApplicationClass' to interface type 'CServer.ICApplication'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{CF0DFA28-046B-4C7D-8AA9-F4B7477D8CAE} ' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
I have registerd the dll using the regsvr32 command.
I have also created a COM+ application for this dll.
Running a search through the registry
I can find the key in numerous places.
I have also tried unregistering the dll and deleting all referneces on the computer to this dll. And afterwards re-adding the dll and re-registering it.
I have written a simple windows script file which tests the dll. This works fine. However the problem exists in my .net project which is running in iis.
Can anyone help me with this?..
If you need anymore info please leave a comment. Thanks.
I had a similar problem, with the "TYPE_E_CANTLOADLIBRARY" message.
Background:
I had a project which used Interop.ReferenceA.dll. This file was created using tlbimp ReferenceA.dll /out: Interop.ReferenceA.dll.
Solution:
When I took a look at ReferenceA.dll using RegDllView I noticed that ReferenceA.dll had a subclass, which was the IID shown in the error message.
I looked around in the source code of the subclass and noticed that it had a dependency to Interop.ReferenceB.dll.
Turns out that the subclass needed Interop.ReferenceB as a type-library to work. So I ran this:
regasm /tlb:Interop.ReferenceB.tlb Interop.ReferenceB.dll (the 32-bit version of regasm was used.)
And the error went away.
Make sure your AppPool is set to x86. Also make sure your assembly is targeting only x86.
I was having a similar issue. First got Access Denied, which after some looking around was resolved, only to be faced with this error message (TYPE_E_CANTLOADLIBRARY). Mind that I'm running a COM+ Component on Windows 7.
After some fruitless attempts which involved messing with the registry, my workmate and I found a way of getting it up and running:
1) Unregister your dll (regsvr32 -u dllname)
2) make sure your references to the dll are cleared up from registry (backup first)
3) Create an empty com+ application (server app) in Component Services
4) Copy the application id to the clipboard
5) go to "c:\program files (x86)\Complus applications" and create a folder with the id on your clipboard
6) copy your dll into that folder and register it
7) Go back to your Component Services and add the component to the app you created using the dll on "c:\program files (x86)\Complus applications{*app id*}"
that did it for me. Hope it helps.
I had a similar problem where the error was triggered on my PC but not on that of other developers.
It turns out that I had been testing an automatic build process on my PC that had updated the version number of the assembly, thus registering the TLB in the registry with a version number higher than the one we were normally using.
When trying to get the interface, the server was consistently using the wrong TLB information leading to the wrong assembly. Once I deleted the higher version entry in the registry, it worked fine.
Now we just have to ensure the build process is not going to cause that issue again. :)
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.
I have a local website which I run through Visual Studio 2008's internal development web server (through the run / compile button).
I have an external library which is referenced on a page of that website and resides inside the web site's "bin" folder.
I've recently changed a class' property name inside that library (renaming it, from "ValidFrom" to "VisibleFrom"), recompiled its dll and have overwritten the original dll inside the bin folder.
This class is mapped with FluentNHibernate, I've also changed the mappings and recompiled / redeployed the library.
When I try to run the site and navigate to the page where the library is used, I'm getting a MethodNotFound exception for the method get_ValidFrom, related to FluentNHibernate's configuration call. This should be get_VisibleFrom now!
Now I've reconfigured my NHibernate SessionProvider so that it generates a new Configuration for NHibernate on each call, and does not retrieve it from the Http Session entity like it did before, because I figured there might lie the problem.
I'm still getting the exception however. I've then deleted the Temporary ASP.NET folder's content... but I'm still getting the error.
Where is the generated schema for NHibernate stored, when using FluentNHibernate?
Anyone knows where else this could somehow be cached?
Thanks
FNH does not cache the schema, it is generated on-the-fly when you make a call to Fluently.Configure() and the schema is passed directly into an NHibernate Configuration object which is used to build an ISessionFactory.
Try clearing out all compiled objects/libraries/executables, removing the reference to your library from all projects that use it, add it back in, and then re-compile everything. Also check your all your code for "magic strings" that may be referencing this property or causing it to be referenced by the old name.
If that doesn't work, it might be helpful to see a stack trace to get an idea of what is being called from where.