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).
Related
I'm using VS2012 to try to remote debug a service running on a remote server on our network.
I have created a shared folder on the remote server that points back at my development machine and allows me to start the msvsmon.exe 64 bit
I have copied the dll and pdb files from my dev machine to the server for the service i wish to debug. These files are identical.
I can attach to the remote process.
At which point my breakpoints state "No symbols have been loaded for this Document".
"Enable just my code" is NOT ticked.
Service web.config has Debug="true"
I've restarted the appPools since loading my assemblies.
When i debug locally the loaded modules window shows the assemblies i want to debut as "Symbols loaded" If i attach remotely the none of the assemblies even appear in the list.
I'm not sure if this is important for remote debugging or not. If it is I don't know how i can fix this.
Assemblies and pdb files are together in the same folder on the remote server.
However, i read that the dll and pdb files must be the same file structure as on the DEV machine.
I don't know if this is right, but i don't see how this would be possible. VS structure are individual project and solution. Once deployed the assemblies all sit in the same bin folder.
Can any one provide any additional possible causes for this issue ? Can the loaded modules issue be fixed if indeed it is an issue?
Thanks
I have an ASP.Net application which uses the Microsoft Graph API (Nuget packages Microsoft.Graph and Microsoft.Identity.Client). The application has two execution modes. In one mode it will run the Graph API calls in the ASP.Net web context. In its other mode, it offloads the process to a Windows service running on the same server, with ASP.Net calling the service asynchronously.
The Graph API calls are working fine in ASP.Net, but when I go to test the Windows service, I'm getting DLL load errors.
System.IO.FileLoadException: 'Could not load file or assembly
'Microsoft.Graph.Core, Version=2.0.3.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)'
The relevant Nuget package versions are:
Microsoft.Graph: 4.3.0
Microsoft.Graph.Core: 2.0.4.0
The windows service executes up to the point where it instantiates the class that contains the Graph service client. Then it goes looking for Microsoft.Graph.Core 2.0.3.0 and throws an exception because the only version available is 2.0.4.0.
I don't know why it's looking for 2.0.3.0. I can't find any reference to 2.0.3.0 anywhere in my project.
It might be worth mentioning that as a post build step I'm copying the Windows service .exe and all .dll files in the service project "bin" folder to a separate folder that the service executes from. I'm wondering if this is the cause of the problem, and there's some other dll that Asp.Net can access, but isn't being copied to the bin folder. I still don't know why the Windows service tries to load an old copy of the dll instead of using the version installed by Nuget.
To summerise:
Asp.Net correctly runs with dll version 2.0.4.0
Windows service fails to load after trying to access 2.0.3.0, which it doesn't have
Both Asp.Net and Windows service are running exactly the same code base. Neither are configured in Nuget to have a dependency on Graph. They both reference a separate project that has the Graph dependencies.
Asp.Net loads the dll at the same point in the code as the Windows service, but the logs indicate its plucking the dll out of the ASP.Net temporary files in C:\windows. The version it pulls is still 2.0.4.0 though, so I don't see any issues here.
Been stuck on this one for several hours. Are there any tools for analysing DLL issues in .Net? I want to know what's trying to access version 2.0.3.0 and why.
Edit:
Here's the assembly binding info. It looks like the service might be ignoring my app.config file for some reason, as it says "no application configuration file found". If that's the case, then it would be ignoring the binding redirect telling it to use v2.0.4.0.
FusionLog "=== Pre-bind state information ===\r\n LOG: DisplayName =
Microsoft.Graph.Core, Version=2.0.3.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35\n (Fully-specified)\r\n LOG: Appbase
= file:///C:/inetpub/SurewayImsDev/ImsServiceBin/\r\n LOG: Initial PrivatePath = NULL\r\n Calling assembly : Microsoft.Graph,
Version=4.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.\r\n
===\r\n LOG: This bind starts in default load context.\r\n LOG: No
application configuration file found.\r\n LOG: Using host
configuration file: \r\n LOG: Using machine configuration file from
C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.\r\n
LOG: Post-policy reference: Microsoft.Graph.Core, Version=2.0.3.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35\r\n LOG: Attempting
download of new URL
file:///C:/inetpub/SurewayImsDev/ImsServiceBin/Microsoft.Graph.Core.DLL.\r\n
WRN: Comparing the assembly name resulted in the mismatch: Build
Number\r\n ERR: Failed to complete setup of assembly (hr =
0x80131040). Probing terminated.\r\n" string
Turns out the problem was I hadn't copied the app.config files over. This was causing the windows service to run without knowing how to map the dll files. All working now.
I'm getting this error message when I submit the input file (which BizTalk eats up as expected)...
There was a failure executing the receive pipeline:
"FileName.BizTalk.Pipelines.Receive_ResponsePipeline,
FileName.BizTalk.Pipelines,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=040e2e09e19196ce"
Source: "Unknown "
Receive Port: "rcv_Response"
URI: "C:\Data\drops\in\*.txt"
Reason: Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft
BizTalk Server 2013 R2\Pipeline Components\FileName.BizTalk.Core.dll' or one of its
dependencies. The system cannot find the file specified.
I checked that directory and the DLL it's looking for is there. I even rebuilt it from the solution along with all its dependencies.
Could this simply be a case of a corrupt file/installation or could it be something else?
The BizTalk solution builds with no issues and I was able to deploy to the BizTalk Server without issues.
To deploy a BizTalk pipeline component, you need to:
Add the file to the "Pipeline Components" folder as the error suggest.
Add it to the Global Assembly Cache (GAC).
Make sure you restart the host instance(s) after deployment AND be sure to deploy it on all BizTalk servers within the BizTalk Group.
Here are the few check points that may be cause of issue:
Check if all the dependent assemblies(Required/imported in given assemby) are also present in GAC & wherever necessary. Any missing dependent assembly gives the same error.
Receive Location handler (check if it is 32 or 64 bit host)
Check if the receive handler is running on all nodes of the farm, if
yes check required dlls are in place
Does EDI component has been properly installed on production box
Check if your project is properly build from Visual Studio, probably
clean the solution and then rebuilt and deploy from VS on dev
environment and then move to prod
After deployment hosts are restarted
Check if receive handler is defined for the host instance Adapters-->File-->New-->Receive Handler and check if the HostInstance is added. Check Receive Location and updated the Receive Handler property.
Check the application pool to Integrated and targeted the v4.0 Framework. This clears the initial error, but then you can receive a new error from IIS that the svc handler was not correctly mapped. I then realized that I needed to run the "aspnet_regiis.exe -I" command against the correct version of aspnet_regiis (the v4.0 framework version).
Sources:
http://social.msdn.microsoft.com/Forums/en-US/246d306b-5a18-497d-a4f6-f8b3a9aacdb8/receive-pipeline-error-could-not-load-file-or-assembly?forum=biztalkgeneral
http://social.technet.microsoft.com/wiki/contents/articles/7204.biztalk-server-list-of-errors-and-warnings-causes-and-solutions.aspx
http://blogs.msdn.com/b/joscot/archive/2013/08/14/biztalk-2013-hosted-wcf-service-fails-because-it-could-not-load-microsoft-biztalk-interop-ssoclient.aspx?utm_source=buffer&utm_campaign=Buffer&utm_content=buffer52156&utm_medium=twitter
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
Using .NET 4.0, I have a small ASP.NET app that utilized the ReportViewer object, I have created a web page that takes some user input and generates a report that is displayed using the ReportViewer control with ProcessingMode set to local.
Naturally, it works perfectly when run via VS 2010 in debugging mode and if I publish it to IIS running on my local machine. However, when I push it to production, I get the following error when actually trying to run the report
For the image impaired:
Failed to load expression host assembly. Details: Could not load file or assembly 'Microsoft.ReportViewer.Common, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Access is denied.
I have verified that the assembly (as well as the other reportviewer dependencies) is in the GAC. There don't seem to be any errors in the event log on the server.
Any ideas what the permission problem might be?
What authentication are you using in IIS? (e.g. windows, anonymous, ASP.NET impersonation)
As it happens, the production environment I was deploying to is a web farm and the virtual directories point to a location on a network drive. When I tried deploying to a non farm server, with a virtual directory located on the server itself, this worked. The permissions are identical in the two environments, so I can only assume that something about this control didn't like being located on a different box than IIS and ASP.NET.
I'm not sure if this is actually an "answer", so apologies in advance if I've handled this wrong from a stackover perspective.