I trying to use ssl connection on class library application but i tried to authenticate
as a client to server i got following error message.
"Unable to find an entry point named 'EnumerateSecurityPackagesW' in DLL 'security.dll'."
Have any body experience about this?
Security.dll is also the same name for the Windows DLL containing the SSPI implementation, which is used for authentication. When loading DLLs, the local bin directory will be checked before the Windows directory. As a result, your System.dll is being loaded instead of the SSPI System.dll.
So if in certain situations your custom Security.dll is loaded before
c:\winnt\system32\security.dll then LoadLibrary thinks it has the dll
already loaded (since it's just a Win32 Dll, only name matter, NOT version
information). But as we know this is not the correct dll and hence the
problem.
The workaround is to change the dll name.
Related
I am calling an old (ca 2014) COM assembly in a .NET application. The system that this application is running on has been moved from one domain to another, and apparently the COM assembly requires settings or some other values that are present in the profile, so we moved/copied profile data over to the new domain users profile. This has fixed a number of issues concerning the use of this COM assembly, but at least one still remains. It is attempting to access some file during the execution of a method, and it throws a The specified path is invalid exception.
The developer for this tool is no longer available, and what I really need is to just find out what file it is trying to access, and get that file back into the filesystem where it is looking for it. The documentation is not helpful in this regard.
My .Net 4.5.2 WPF Application is deployed to C:\Program Files\Folder A\FolderB. Its copied to that location by a custom deployment service that is basically a copy job with some additional features. The application itself is xcopy deployable, given you have the required C++ runtimes, .Net Framework installed.
The application includes several com components, registered via the application manifest file, which used to work just fine. After an update to the applications binary files, several calls in the form System.Activator.CreateInstance fail
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
If i simply rename the application folder to c:\Program Files\FolderA\FolderC everything is working correctly
Attaching ProcessMonitor and WinDbg, i can trace that the application is searching the registry for the given classid, doesnt find it and then, if started from the first folder fails as described above. Started from the renamed or copied folder the process loads the associated dll and just goes on.
Any hints on diagnosing this issue?
To anyone struggeling as I did: as far as i currently see it, the problem was the SideBySide Cache.
In short, Windows caches the manifest information for an application, and if it determines the application has not changed, uses the cache (you will notice that the existing external manifest is never loaded by your process).
In my case the executable did not change, but the rest of the application, including the manifest information.
The solution is to touch the modification date of the executable, causing the cache to become invalidated.
Basically also answered in this question
I have an old .TLB file which is called 'GrpSvr.tlb', it contains a class called GrpCall. I have registered the .tlb on my Win7 x64 machine using regtlibv12.exe which worked correctly. I want to invoke the methods withing this library from C#, so first I tried:
Type objectType = System.Type.GetTypeFromProgID("GrpSvr.GrpCall");
dynamic thirdPartyDLLObject = System.Activator.CreateInstance(objectType);
but this returns null for objectType.
Question 1. can I invoke my .TLB file this way and what I am I doing wrong in this case?
Moving away from this method I then decided to follow
Import TLB into C#
which describes how to create a C# DLL using MSs Type Library Importer. I followed this and created GrouperServer.dll from GrpSrv.tlb using the command:
C:\Program Files (x86)\Microsoft Visual Studio 12.0>tlbimp F:\Groupers\DRGROUP\GrpSvr.tlb /out:C:\GrouperServer.dll /nam
espace:GrouperServer
Microsoft (R) .NET Framework Type Library to Assembly Converter 4.0.30319.33440
Copyright (C) Microsoft Corporation. All rights reserved.
TlbImp : Type library imported to C:\GrouperServer.dll
I then imported this DLL into my C# project (and set Embed interop Types = false following this answer) and attempted to invoke the class via
GrouperServer.GrpCallClass grouperServer = new GrouperServer.GrpCallClass();
but this does not work and at run-time I get the following error:
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in DrGroupIN.exe
Additional information: Retrieving the COM class factory for component with CLSID {FFB54BC4-B15E-11D1-99BC-0000E803C444} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
Following the advice given in
Retrieving the COM class factory for component with CLSID {XXXX} failed due to the following error: 80040154
I then set the project to target x86, but this does not help in this case.
Question 2: Why is this error being thrown and how can I resolve it?
Yeah, you are doing this wrong. A type library is not a COM server, using regtlibv12.exe is never necessary. You'll need to read the exception for what it is trying to tell you, as tens of thousands of Google hits do, the COM server is not registered.
A COM server is executable code, usually stored in a .dll. Sometimes an .ocx or an .exe. An installation step is required to register that file so that COM can find it back later when a program tries to create a COM object that the server implements. The Regsvr32.exe utility is a very common way to do that, but you should always use the installer provided by the vendor or author. Which ensures that the executable file(s) are copied onto your machine and writes the registry entries. Including the ones for the type library. The exception tells you that this wasn't done, COM cannot find the registry entry that tells it where the file is stored.
A .tlb file only describes the COM component, it tells a compiler what the declarations looks like. Helping the compiler to generate correct code to use the component and telling you when your code is wrong. It is metadata, very similar to the metadata that's present in a .NET assembly that describes the .NET types that are implemented by the assembly. It is usually embedded in the DLL or EXE as a resource, much like metadata is embedded in a .NET assembly. You can look at it with OleView.exe, File + View Typelib. Also used by Tlbimp.exe, a .NET utility that converts a type library to a .NET interop assembly, converting the declarations into a format that the CLR can easily understand.
Can't help you find the correct installer, it isn't anything standard.
Put GrpSvr.Dll and its dependencies under the exe folder, and try again. The error is because it can not the find the GrpSvr.Dll based on the GUID in the registry.
Or you can search the registry with that GUID, you will find an entry which specify where the DLL is.
One tool to debug this kind error is the process monitor in the system internal kit, the log will give you a great detail on how the exe is searching registry and files, from the log, you should find the missing parts.
I'm trying to use a 3rd party COM DLL (I don't believe its a .NET component) from a .NET service without registering the COM DLL but I'm having no luck so far.
I've copied the manifest files from here (http://stackoverflow.com/questions/465882/generate-manifest-files-for-registration-free-com) to use as a starting point (I generated the COM DLL manifest using the referenced mt.exe/regsvr42.exe). However all I get is the following error:
Exception: System.InvalidCastException
Message: Unable to cast COM object of type 'LOGICLib.LogicClass' to interface type 'LOGICLib.ILogic'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAA3E8FB4}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
Source: Interop.LOGICLib
at LOGICLib.LogicSecuredClass.Connect(String IP, UInt16 Value, Int32& Result)
at My.Server.MyAssembly.Loader.Connect() in D:\MyProject\Source\Server\MyAssembly\Loader.cs:line 461
The application manifest is named after the exe that starts the service - I've also tried naming it after the assembly that calls the COM DLL. I've tried starting on the command line and via Visual Studio's debugger. I've also tried using the Interop file supplied by the third party and generating my own.
(Note - I've only tested under Windows XP so far.)
I've spent two days on this now and have not progressed at all. Any ideas what I may have missed?
The application manifest is named after the exe that starts the service
Yes, this does not work. Windows always looks for a manifest in the EXE itself, embedded as an unmanaged resource. Only when it cannot find one in there will it look for a .manifest file on disk. Problem is, a managed program built with VS2008 and up already has a manifest. The default one says "I'm Vista aware" only.
You can verify this for yourself by using File + Open + File and selecting your EXE. Open the RT_MANIFEST node and double-click resource 1. If you don't see your reg-free COM manifest entries there then it isn't going to work.
To fix, use Project + Add New Item and select the Application Manifest File item template. You'll get the boilerplate manifest, copy and paste your regfree COM entries in there.
Well, from the exception, you're getting a cast error when trying to cast an object of type LogicClass to an interface type of ILogic. Looks like LogicClass doesn't implement ILogic.
You didn't supply what the DLL is or where you got it, so you're best bet is to look at the documentation for the library you're trying to use. Just a wild guess, but it looks like you're implementing it incorrectly.
I've created and registered a managed COM library in C# on my development machine. I've successfully registered it and created a .tlb file with regasm, and successfully imported the tlb into a c++ console app used for testing.
My COM assembly is called "efcAPI.dll" and it references another assembly that has not been set up for COM or registered in anyway called "efcServerDiscovery.dll". This second dll contains some code used by my COM dll and exists in the same folder as efcAPI.dll.
Everything concerning loading the COM assembly works fine. I can create instances of my classes defined in the COM and call methods from them. However when I call certain methods that use the code defined in efcServerDiscovery.dll I get a _com_error which reports that it could not load file or assembly 'efcServerDiscovery'.
I've verified that everywhere on my hard drive where efcAPI.dll exists there's a copy of efcServerDiscovery.dll (which is just the location I built and registered efcAPI.dll from). I've also attempted to place efcAPI.dll and efcServerDiscovery.dll in the same directory as the c++ app with no success.
Any suggestions as to where the c++ app is looking for the assembly or how to discover where it's looking would be great!
Yes, this is a problem with COM components having non-COM dependencies. Windows doesn't consider the location of the COM DLL when it searches for dependent DLLs. The normal search rules are in effect, the folder that contains the EXE first, Windows directories, current working directory, PATH environment. The location of the COM server does not play a role.
Assuming you don't want to deploy to the EXE folder, none of these are good places to store your DLL, although plenty of installers made the desperation move of storing it in c:\windows\system32 or modify the system PATH environment variable.
One thing you could do is P/Invoke SetDllDirectory() in your C# code before running any code in the DLL. Using Assembly.GetExecutingAssembly().Location will do it. That is however not a safe thing to do though, it might alter the search rules for the app that uses your component.
The only real fix is to install the DLL in the Windows side-by-side cache (WinSxS) and to include a manifest in your C# executable. Given the state of the documentation, I can only wish you the best of luck.
In these situations i always start with Dependency Walker verifying that what & where its trying to load is what i think it is.
fuslogvw will tell you where the CLR is looking for assemblies
Or use GAC.
(here are your characters, stackoverflow)