I have a DLL which is GAC'ced (c:\windows\assembly) which is being used by my Biztalk Application, for some requirement, I changed a function in that DLL and:
I uninstalled the old DLL which was in GAC (version 1.0.0.0)
I GAC'ced the newly built DLL into GAC (version 1.0.0.0)
I also restarted the BizTalk Host Instances.
But still the output seems to be from the old DLL's function. I am not getting the problem, why still I am getting the old output.
Can anybody help me?
Some tips that might be helpful:
(1) If you have multiple BizTalk servers in your group, be sure to update all of the servers!
Depending on your host instance configuration, your instance may run on any server the host instance is active on.
(2) Make sure you restart the correct biztalk host instance. This is often overlooked. Don't forget about the BizTalk Isolated Host! Perform a recycle of the specific IIS application pool if necessary. If you are unsure, perform an iisreset.exe
(3) To update a DLL in BizTalk it is often necessary to update it in the BizTalk database as well. For some changes it may work just updating the DLL in the GAC, but often I find that this is not enough (especially with orchestrations).
What you are describing here is correct. You should see the new DLL taking over. A couple things to check:
Did you recycle the correct host instances?
Did you recylce the host instances on all servers?
Did you veriiify the Create date on the GAC'd DLL to ensure the new one was installed?
Another issue might be based on what you changed in the Application. You can only Gac/Restart under particular circumstances. See this When can you just re-gac and re-start on Jon Flander's blog for reference.
If you want to be really sure that the correct assembly that has been GAC:ed, click "Run" and type "%systemroot%\assembly\gac" for .Net 1.1 or "%systemroot%\assembly\gac_msil" for > 2.0.
There you have the physical files for each version number to be checked (or overwrited).
It might help us support you if you let us know what part of BizTalk you are using the assembly, pipeline, functoid, schema etc.
Is that DLL used under a BizTalk process (BTSNTSvc.exe) or by an Isolated Host Instance?
If this DLL is used in a Receive Location which Receive Handler (Host) is Isolated, for example a SOAP Receive Location, you have to restart the Application pool from IIS and not the Host Instance.
Related
I use a Weblogic 10.3.6 Server on which I have numerous Enterprise Applications, Web Applications and Libraries deployed.
A few days ago, after a deployment glitch, the Console's deployment view does not show applications anymore. Only libraries are listed.
Does anyone know where I can start looking to fix the problem? How are enterprise and web applications found by the server to be displayed?
Edit 1:
Applications are in fact running, accessible and listed under the /Environment/Server//Deployments tab. From there I cannot update/start/stop them, however. They are missing only in the /Deployments view.
config/config.xml seems to be correct. All applications are listed there.
Okay, that fixed it.
The Admin Server had an application called wls-cat.war installed, which failed upon server start. Apparently, it is Oracle's Classloader Analysis Tool which may come in useful in debugging. Not in this case, though. It failed on Admin Server startup. You cannot start, stop, deploy, undeploy or redeploy it with the standard means (it is an internal application).
In the end, I shut down the server and manually removed it from the /config/config.xml file.
<app-deployment>
<name>wls-cat</name>
<target>SBV00PG9_PERM01_ADMIN_SPU_PORTAL</target>
<module-type>war</module-type>
<source-path>${WL_HOME}/server/lib/wls-cat.war</source-path>
<security-dd-model>DDOnly</security-dd-model>
<cache-in-app-directory>false</cache-in-app-directory>
</app-deployment>
After that, the server shows applications again. I may need to reinstall the app at a later time, but for now the server seems to run well without it.
Very special thanks to Emmanuel Collin for setting me on the right path.
I have an ASP.NET web application (Visual Stuido project type) in which everything is compiled into a single assembly, it is deployed in IIS. My question is if I have a new version of the assembly, is OK to replace it in IIS without bringing down the IIS? Or for a safe consideration, should I firstly shutdown the web server and then replace the assembly and restart? I am looking for a better solution to reduce server down time?
Yes. but it will cause an immediate Application Pool Recycling.
Quoting MSDN Blog:
Altering the following files will also trigger an immediate restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
We've reinstalled applications numerous times usnig the Visual Studio installer and it has replaced the assemblies with no problems. The only thing we find is that the first time we open the web page it takes a little while to open - possibly as it reads in the new assembly. We haven't had to to do an IIS reset or anything like that.
In addition on our dev environments (and because I am lazy) I often simply overwrite the assembly on the web server and that exhibits the same behaviour as above.
Taking down IIS is not an option for us, as we have many websites running on the same server.
I can't guarantee this is the best way to do it or that it won't cause problems, but it works for us.
I am developing against a BizTalk 2009 environment. I am using BizTalk Deployment Framework (BTDF) to deploy my solution to the server. The problem I am facing is that when I tweak any aspect of my maps, the changes are not reflected in the BizTalk message body or output messages I use for testing. For instance, removing a link to a mapped element still shows the data being mapped from source to destination as if nothing has changed.
Between each deployment, the BTDF uninstalls the application, re-GAC's the assemblies, installs the application, and then bounces the host application. Ever so often BizTalk essentially catches up to my map version and it is working without issue until I make another tweak.
Is it possible that BizTalk is caching the map in a way that I cannot refresh?
Are you making your map changes in the BizTalk Mapper, or an XSLT?
Visual Studio does not recognise changes in an XSLT as requiring a re-build of the assembly. You would need to explicitly perform a "Rebuild" of the Map assembly in order to see these sort of mapping changes apply.
Hope this helps.
Are you building your dll's for deployment on your development machine?
Then remember that version of the map from GAC will take priority over your local map from visual studio.
I was many times cought by map dll taken from GAC instead of local folder.
Hope it helps
i'm a newbie in biztalk.
i have data service access dll which are linked to the wcf.
i've just added a new column so i've updated my wcf.
so the next thing would be to update the dll which are already in the GAC.
just wondering if there's any msdn documentation about this?
or what's the best practice here?
and what exactly goes on when you restart host instance vs restarting the application?
thanks
Stopping/starting a BizTalk application simply stops and restarts the associated Receive and Send ports, and prevents the Orchestrations from acting on any pending subscription items. If you go one step further and un-enlist the Orchestration/Send Port, this removes the relevant subscription from the BizTalk Message Box database.
By compiling and deploying a new definition of your WCF datatype, you have changed the assembly within the GAC (all schemas are compiled and represented as .Net datatypes under the hood). To have this change reflected inside the running Host Instance, you would effectively need to alter the existing DLL that is in the .Net AppDomain. The .Net runtime does not support the removal of assembly types from an AppDomain, so you need to stop, and restart the Host Instance to effect this.
Short answer: Restart your Host Instance for any changes in data definition.
Since, for various reasons, I can't use IIS for an ASP.NET website I'm developing, I run Cassini from the command line to test the site. However, after installing Visual Studio 2008 SP1, I get a System.Net.Sockets.SocketException when I try to start up the web server. Is anyone else having this problem, and if so, how did you fix it?
Is there anything in the Application section of the event log?
Have you tried using a different port?
Per this thread, try:
Unbind from Visual Source safe, delete the web project from the solution, rename the folder where the website is stored and then re add to the solution as an existing web site and then bind to source safe again.
There may be some incorrect info in your .suo or .sln file. You can safely rename the former, as it is user-specific (solution user options); the latter (the solution itself) would be a bit more of a hassle to recreate.