Unable To Load Dll Error 127
Tanesha Prately
I have ArcGIS Enterprise Base Deployment installed on a virtual machine. Both Server and Portal use Web Adaptors and they are federated. It has been in a use for a while when I experienced an error while changing capabilities of feature hosted layer in Portal. When I want to 'enable editing' in settings and save it I got an error:
I struggled with this error for a week, so decided to reinstall the whole environment. Everything was installed on Friday and the error disappeared - I tested couple of times, with different feature layers, from different machines, users, with different capabilities - no problem. I came to an office today, wanted to change capabilities and the error came again.
You can disregard the error as that page requires authentication but you probably haven't provided any. Did you see a certificate error when first browsing to the page? Check the certificate by hitting F12 to bring up the dev tools, then go to Security > View Certificate and under the General tab, does the Issued to hostname match the hostname in the URL within the error, ( :6443). If not, go to Details and then see if a Subject Alternative Name is set for the certificate. If so, does it match the hostname? If not, then the problem is the certificate is mismatched and requests from Portal to that URL will be denied. If the hostname is correct, regenerate the certificate. If this is self-signed, then you can create it using Server Admin:
Can you open :6443/arcgis/rest/admin/ in your browser and see if the browser indicates the certificate is mismatched? The problem is likely that the CN, or common name, of the certificate is yyy but the URL you're accessing that is assigned the certificate is :6443/arcgis/. This indicates a certificate mismatch would be the reason for the java.security.cert.CertificateException: No name matching xxx found error.
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache(Assembly assembly, Boolean loadReferencedAssemblies, Dictionary2 knownAssemblies, Dictionary2& typesInLoading, List`1& errors)
This error has no true magic bullet answer. The key is to have all the information to understand the problem. Most likely a dynamically loaded assembly is missing a referenced assembly. That assembly needs to be in the bin directory of your application.
It would work fine on my development machine (Windows Vista 64-bit). Then when deployed to the server (Windows Server 2008 R2 SP1), it would work until the session timed out. So we'd deploy the application and everything looked fine and then leave it for more than the 20 minute session timeout and then this error would be thrown.
For my situation the missing DLL was Microsoft.ReportViewer.ProcessingObjectModel (version 10). This DLL needs to be installed in the GAC of the machine the application runs on. You can find it in the Microsoft Report Viewer 2010 Redistributable Package available on the Microsoft download site.
If you're using the EntityDataSource in your project, the solution is in Fix: 'Unable to load one or more of the requested types' Errors. You should set the ContextTypeName="ProjectNameNameSpace.EntityContainerName" '
I had a .NET 4.0, ASP.NET MVC 2.0, Entity Framework 4.0 web application developed in Visual Studio 2010. I had the same problem, that it worked on one Windows Server 2008 R2 server but not on another Windows Server 2008 R2 server, even though the versions of .NET and ASP.NET MVC were the same, throwing this same error as yours.
Well, it turns out that installing Windows SDK v7.1 (x64) resolved the issue. Whatever dependency was missing must have been included in the SDK. It can be downloaded from Microsoft Windows SDK for Windows 7 and .NET Framework 4.
Adding my specific problem/solution to this as this is the first result for this error message. In my case, the error was received when I deployed a second application within the folder of my first application in IIS. Both were defining connection string with the same name resulting in the child application having a conflict and in turn generating this (to me) non-obvious error message. It was solved by adding:
By changing the target platform to match the 32-bit server where the web application was being deployed removed the majority of the errors related to not being able to load one or more of the requested types.
I had the same error message reported when compiling a Visual Studio package (VSPackage). The whole solution compiles and the error is thrown when the package is being created by CreatePkgDef. Having said that, it is clear that I cannot catch the LoaderExceptions as it is not my application that throws it, but Microsoft's own tool. (Though I am responsible for the confusion of CreatePkgDef.)
In my case the root cause was that my solution creates a MyDll.dll that has already been registered to the GAC (and they are different), so the CreatePgkDef got confused which one to use and it decided just to throw an error which isn't really helpful. The MyDll.dll in the GAC was registered by the installer of the same product (obviously an earlier version, with /slightly/ different content).
If you are absolutely positive that you are running the build command from the binary directory, this error probably means that you have had an issue during the configuration/generation step that you should have ran before trying the build. You can try to configure again to check (cmake your-build-dir)
So, I have VI loads fine with LabVIEW adapter configured to Development. The moment I configure the adapter to Run-Time, TestStand returns an error saying that it can't load the VI. I have no idea what could be causing this... troubleshooting ideas?
I guess that error description tells everything - most probably, you have missing dependencies. If you'll take normal (not deployed VI), which uses some dependencies VIs, and try to run it via Run-Time Engine, it'll drop you an error b/c dependencies are missing.
2. If I develop the sequence file with the adapter set to Development and save the sequence, then change the adapter to Run-Time and execute the sequence file programmatically from LabVIEW (with the vi that supposedly can't load) it runs correctly. I assume if the subvi actually couldn't load it would throw an error when executing the sequence. This doesn't happen.
Note: Everything LabVIEW I'm talking about here is compiled code as part of a larger application. The API call that won't load, the program that executes my "broken" sequence file... all compiled code running from a Run-Time environment.
2. If I develop the sequence file with the adapter set to Development and save the sequence, then change the adapter to Run-Time and execute the sequence file programmatically from LabVIEW (with the vi that supposedly can't load) it runs correctly.
This brings LV Application Instances to mind. The error you're posting about is mentioned towards the end of this document, but under opposite circumstances from what you've described above. Regardless, it's worth taking the time to understand the content of this white paper.
Since the OI is able to load the dependencies correctly, the place to start would be any subVIs shared between the code module and the OI. Once you figure out the conditions causing it, post a small reproducing case here - or open up a ticket with NI support to see if this is a bug.
Don't fully agree with it. Recently I've played with this topic - changed adapter type from dev. environment to run-time engine for my sequence. And it didn't work. Although, in development environment all code modules loaded fine.
Note: Everything LabVIEW I'm talking about here is compiled code as part of a larger application. The API call that won't load, the program that executes my "broken" sequence file... all compiled code running from a Run-Time environment.dfsfsdf
This can be again issue with VIs conflict in memory. While you run it via LabVIEW application, you already have some VIs loaded to memory. Thus, if those VIs are the one, what are missing for Run-Time engine while running from TestStand, then code modules have all needed Vis already loaded.
So I beleive, that this is all about missing dependencies for code modules, while using Run-Time engine. @WireWeaver gave a good explanation from TS help - there are differences, how TS loads code modules with dev. environment; and with RTE environment.
Do you open your sequence file, when you have also loaded code of that larger application, what you've mentioned? How do you make sure, that code modules in dev. environment are really loaded just within TestStand, and not LabVIEW? I had situations, when I had opened LV project, and sequence which used VIs with the same names, and afterwards TS swapped original code modules steps, with another one, from the different project.
aa06259810