Custom Data Flow Components, DllImport, and third party dlls

I've been having an issue with the integration of a third-party DLL into a custom data flow component.

The company sent me a C# project that generates a simple console application. The project includes a class that calls their DLL with DllImport. The console application runs fine.

I created a stand-alone class using the C# class they sent to expose the methods of their DLL. In my custom component, I'm referencing this class to pass data to and from their DLL.

The first method from that stand-alone class that my component encounters simply gets their installation path from the registry and does not use DllImport. That path retrieval works fine. The next method calls a function that is declared with DllImport. Each time the call fails with "System.DllNotFoundException = {"Unable to load DLL AMZip.dll': Exception from HRESULT: 0xE06D7363"}".

I've copied this DLL to countless locations (e.g., the PipelineComponents directory, the project/solution bin directory) and included these paths in all manner of path variables.

What am I missing here? Their DLL is not strong named (does this matter since I'm using DllImport?), my stand-alone class is, and of course, the custom component itself is. I appreciate the help.

No bites, eh? OK, is there a standard directory for C++ dlls used in custom components?|||I think the question on everyone's mind is, what does this have to do with SSIS?|||Strictly speaking, your question might be better served in a C# forum or something. While we do custom development here, this isn't a programming forum.|||

Phil Brammer wrote:

I think the question on everyone's mind is, what does this have to do with SSIS?

Thanks for giving me the opportunity to explain why I posted this question in the SSIS forum!

Like I said, the class in my sample console application hums like a sewing machine. When I try to integrate it into an SSIS component it fails by an error for which I can find no explanation and the finest .NET programmer I know can find no explanation, having not dealt much with SSIS internals. There aren't a whole lot of people on Earth who program SSIS components, but one place they can be sure to be found is on this forum.

I guess the upshot is, I'm hoping to get a suggested nugget from someone who may have been down this road before, as opposed to a cocksure question.

|||If your application is built on the .net 2.0 framework, then this shouldn't be that hard. The 1.1 framework won't work in SSIS, I believe.

Getting your DLLs registered in the GAC might also help.|||

The third-party component in question is a C DLL. It has dependencies to msvcm80.dll, msvcp80.dll, msvcr80.dll, and Microsoft.VC80.CRT.manifest. I have a wrapper class for the DLL with DllIImport statements that makes its functions available for .NET.

The question is... does SSIS look for non-.NET dependencies in the system path? They are obviously not in the GAC since they're not .NET.

I am getting an error that leads me to believe the dependencies are not found; however, they are in one of the directories in the system path. What else can I do to get SSIS to find them?

|||

I would expect SSIS to behave much like any other program. Really the SSIS package will be hosted, but I would expect system32 to be a good location. Similarly your dependencies for the C++ DLL would need to be there. You could look at the SSIS install bin folder, not the project, but is a bit unreliable as may not always use a MS host that is in that bin folder. Getting system32 to work I think would be better in the same way that we say always put .Net dependencies in the GAC to ensure the runtime can find what it needs.

So if you try or have tried system32 and it still fails, what is missing? Use Filemon to look for file not found or access denied events and see where it is really looking. http://www.microsoft.com/technet/sysinternals/default.mspx

|||Are you using Vista? Ever since I brought my applications into Vista, I get that error when I try to link any DLL other than windows API. The same applications worked fine on XP. I copied the file all over the place and used the full path when linking and it still says that. I get this problem with all languages, not just C#.|||

Solution -1

1.Copy DLLS to your application\ bin folder(Virtual Dir)

2. Then do the following in code.........before you do a pInvoke

StringBuilder LocalFolder = new StringBuilder(AppDomain.CurrentDomain.BaseDirectory);

LocalFolder.Append("bin");

Directory.SetCurrentDirectory(LocalFolder.ToString());

3. Then give security permission "modify" for the "bin" folder for the following

a. ASP.Net Machine accounts..

b. Network services

c. youself!!!!!!!!!!(ur login)..

4. Try ur luck..

This happens when u are in a comapany with strict access

DISCLAIMER...

I tested it out..works for me..may not work for u..I am not responsible for the damage caused due to this post

Soultion -2

The Administrator need to grant you access to the ASP.NET temporary directory (somewhere in the WINNT ).

DISCLAIMER...

I didn't test it out...got a clue from net..which lead to my solution..I am posting it bcos it may help other poor souls who has this problem..I am not responsible for the damage caused due to this post.

Pls exuce my weak knowledge of .net tehnologies.. I am a C++ /Windows programmer forced to do .Net deployment