I have multiple services that is pulling an assembly from the GAC. When I install one of these services it is updating the GAC with a new assembly that is shared by various services, and inserts a new policy file into the GAC so that all previous versions look for the new assembly. All the services pick up on the policy without restarting the service and uses the new assembly perfectly. The problem and question arises is when I roll back this release, and uninstall the assembly and policy and restart the service related to installing the new assembly. Obviously the restarted service picks up the previous version of the assembly in the GAC. But the other services that are running on the server that use this assembly are still binded to the new version of the assembly from the policy file. My questions are:
Is the binding like a cache where it will eventually release it and pick back up on the old assembly? or will it stay binded until the service restarts?
If it requires a restart is there anyway besides locating all the services that use this assembly and restarting those services, or restarting the server itself to remove the blinding to the assembly that has been removed from the GAC?
The .NET runtime does not unload an assembly until the application domain is shut down (typically when the process exits but its possible to create multiple application domains in a single process).
I think you will need to shut down the other services, remove the policy file and the new assembly, then restart all the services involved.
Related
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.
Is it required to have anything SQL Server related installed on a web server in order to make use of SMO? I've built a web app that programmatically creates a SQL Agent job, adds a step (which ultimately fires of dtexec to run an SSIS package), and executes.
This works fine on my local machine which has SQL client tools installed, however when I move to a web server, I get reference issues and I'm starting to think it's due to something not being installed.
Could not load file or assembly 'Microsoft.SqlServer.SqlClrProvider, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies.
This is a rat hole.
The problem is that once you locate that assembly and copy it to the bin folder of your application it will complain about a completely different one.. or even the same file simply due to missing dependencies.
For more information read this: http://www.sqldbadiaries.com/2010/10/20/how-i-fixed-could-not-load-file-or-assembly-microsoft-sqlserver-smo-version10-0-0-0-issue/
That site lists the files you need and the fact you need to register and gac a few files. Quite frankly, you are much better off just biting the bullet and install the client tools on your web server.
Yes, your application requires this assembly in its bin directory to function. This error means that the server doesn't have the SMO (and its dependant) assemblies.
Back in your solution in Visual Studio, right click on the assembly above, and select/change the "Copy Local" to "True". Copy this for each SMO assembly that you've referenced.
When you publish your application, this will bring those .DLLs on your development machine along in your published bin directory.
Check your web.config file for any references as well
search your code for SqlClrProvider
I have BizTalk orchestration where it reads xml file calls .net class from expression shape and send file to send location but it doesn't work always. It only works like 3 out of 5 times. When it doesn't process my orchestration, I am getting "Could not load file or assembly 'XXXX, Version=1.0.0.3, Culture=neutral, PublicKeyToken=xxxxxx' or one of its dependencies. The system cannot find the file specified."
Please help. Thank you.
On each BizTalk server with a BizTalk host instance, you need to verify that the assembly is in the Global Assembly Cache (GAC). If you can load a Visual Studio or Windows SDK command prompt on each, then run gacutil /l > c:/gac.txt and it will output everything in the GAC to a text file called gac.txt on your C: drive. Look in that file to verify that the assembly (and the right version of that assembly) is deployed on EACH BizTalk server that could be running a BizTalk host instance.
Whenever you make changes to an application, and deploy those changes, I find it helpful to restart the host instance your application is running on.
Also, if you are using an external assembly, perhaps in an orchestration or a map, you need to make sure that assembly is in the GAC (global assembly cache).
I'm working on a BizTalk project and don't understand the reason for both installing (double-clicking) and importing (using biztalk admin console) is needed.
I have a BizTalk project and I added bindings to it's resources and exported an msi file. Now I want to install the application on another server.
As far as I can tell this is what an MSI install does:
Copies files to the file system
Registers assemblies into the GAC
Adds the Application to the Add/Remove programs applet
However, here are my issues:
Installing using the msi doesn't add the application to the Biztalk admin console. We need to import the msi.
Uninstalling using the msi doesn't remove the assemblies from the GAC. It only removes the files it copied to the file system. Is there away for the uninstall to remove the GAC assemblies as well?
If I just import the MSI I'm able to start my biztalk application and it seems to run fine. Combined with issue #1 and #2 why is the MSI needed at all? I can see just importing doesn't add it to the GAC so if other applications depend on it they won't work.
I'm sure I'm missing features/configuration that the msi provides, but could someone help me understand why the msi needs to both be installed and imported into biztalk and why when you uninistall it does not fully uninstall everything it installed?
Two operations need to be undertaken when deploying a BizTalk solution.
Why Deploying BizTalk Solutions is a Two-Step Operations?
Register the BizTalk Solution to the BizTalk Management Database
Install the BizTalk Artefacts and Dependencies to the File System
First, BizTalk assemblies that comprise your solution must be registered to the BizTalk Management Database. This will allow BizTalk to know what Schemas, Maps, Pipelines and Orchestrations are available.
This is done by Importing your Windows Installer package to BizTalk.
Please, remember that a typical BizTalk plaform usually consists of many physical servers. However, all the servers in the BizTalk Group share a single BizTalk Management Database.
Therefore, the import operation needs to be done once for the whole BizTalk Group.
Second, the BizTalk assemblies that have been registered to BizTalk need to physically exist somewhere. Therefore, they must be installed to the file system.
This is done by double-clicking the Windows Installer package.
Notice that the install operation needs to be repeated on any physical server that is part of the BizTalk Group. And since, there is only one definition in the BizTalk Management Database as to what assemblies are part of the solution, this explains why BizTalk assemblies must be installed to the Global Assembly Cache (GAC).
Notice that, so far, the rule is simple :
BizTalk assemblies must be installed in the GAC on each server in the BizTalk Group
BizTalk assemblies must be imported (or registered) in the BizTalk Management Database once
However, we have only dealt with BizTalk assemblies. All other assemblies or other dependencies (Business Rules definitions, COM objects, bindings, configuration files, etc.) that a BizTalk solution needs at runtime are not covered by this two-step operation.
Inter-Environment Deployment
However, when the solution runs, those dependencies must also be present on each BizTalk server as appropriate.
That is why most of those artefacts are also registered to the BizTalk Management Database. But this time, this is only done so that the dependencies are brought in when the Windows Installer package for a BizTalk solution is created, and so that those dependencies can be installed appropriately on the target servers.
Why BizTalk Assemblies are Not Removed from the GAC upon Uninstall?
As a general rule of thumb, assemblies that are registered to the Global Assembly Cache are considered shared resources. Therefore, for safety reasons, BizTalk assemblies are not removed from the GAC upon uninstall. Consider what would happen when a custom BizTalk pipeline is used by more than one application. In that case, the BizTalk pipeline must be part of a separate, common, BizTalk application. Uninstalling this shared BizTalk application would break all other applications that depend on this pipeline...
When adding resources to the BizTalk Management Database, you have the choice to have assemblies be installed to the GAC at import or at install time. I strongly recommend against using the "GacOnImport" feature, that does not make sense in most typical multi-server BizTalk Groups.
However, there is an easier and most flexible way to customize what can be done to BizTalk assemblies or other dependencies, with regards to the Windows Installer package. This is done with Pre Processing and Post Processing Scripts.
Those scripts allow for running arbitrary applications at four specific times during the import/installation operations.
Before Importing
After Importing
Before Installing
After Intalling
If you want assemblies to be removed from the GAC upon uninstall, it is a simple matter of scheduling the appropriate command-line during the "Before Installing" phase of the operation.
Importing the MSI file adds the assemblies from the MSI into the BizTalk database. As you stated, running the MSI adds the assemblies to the GAC. Both are requires for the BizTalk application to be "installed". Only BizTalk assemblies have to be imported onto the BizTalk management database. All DLLs used by BizTalk must be in the GAC.
It may be worth a look at http://msdn.microsoft.com/en-us/library/aa578463(v=BTS.10).aspx to see that you can customize the behavior for install and import for each resource in your BizTalk application. This will allow you to only import the MSI and have that both add the assemblies to the database and install them in the GAC as well, leaving you without additional clutter in your Add/Remove Programs.
As to why the DLLs aren't removed from the GAC when you uninstall an installed MSI, I can tell you that this was by design. If you take a look at this page on MSDN http://msdn.microsoft.com/en-us/library/aa562001(v=bts.10).aspx you can see that this behavior is described as expected. That MSDN article also includes the link, under how to remove an assembly from the GAC, which explains how to use a post-processing script to have your MSI actually remove your assemblies from the GAC upon uninstall of the MSI.
Add service reference to Amazon service fails, saying
"Could not load file or assembly "System.Core, Version=3.5.0.0,...' or
one or more of it dependencies. The module was expected to contain an
assembly manifest."
This is in VS 2008, haven't installed SP1 on this machine yet.
Any ideas?
This can happen if ASP.NET isn't installed. Go to Add/Remove Windows Components and look under IIS; make sure that ASP.NET is checked (meaning that it's installed.) That should clear up your problem!