Develop Reference

Importing nested COM references

In Visual Studio 2015 if I create a "class library" C# project and then add a reference to a custom COM DLL (created using VB6), VS will then also automatically add all (?) the COM references that the VB6 DLL depends on.
How does it do this? How can it statically figure out what those references are?
Note -- Our VB6 DLL uses "early binding", but even still there is no equivalent of an imports table for COM items like you would see in a traditional "C" style DLL.

You are actually adding a reference to a type library. It is embedded inside the DLL as a resource. You can see it when you use File > Open > File, select the DLL, open the TYPELIB node. It plays the exact same role as metadata in a .NET assembly, listing the type definitions of the exposed interfaces and classes. It has a binary format, you can decompile it with the OleView.exe utility.
And has dependency info as well, the registry helps to find such dependent type libraries (HKLM\Software\Wow6432Node\Classes\Typelib key). Roughly the same role that the GAC plays in .NET. COM just isn't as different from .NET as everybody assumes :) The first version of the CLR was created by the COM+ group at Microsoft. Eliminating the registration and DLL Hell problems associated with COM were on the top of the todo list.
Type libraries are not exactly legacy, they still play a pivotal role in the brand-new WinRT (aka UWP, aka Modern UI). Which is COM-based at its core, very well hidden. But the olden format was retired because of limitations, replaced by the .winmd format. Which is exactly the same as the .NET metadata format. Any .NET decompiler can show their content.

The reason that Visual Studio type library importer chases type library dependencies is to gather type information to map to .NET.
A type library doesn't have direct dependency information. So this is a very good question: how to track type library dependencies?
The only feasible way to detect type library dependencies is by referring to a type which states the declaring type library.
For instance, if your type library references IXMLDOMDocument in a method's signature, it'll be recorded in a type info record.
You can crawl a type library, by loading one, getting a ITypeLib from it and enumerating ITypeInfos recursively.
You'll eventually see this record. Then, you can get the type's containing type library ID through ITypeInfo::GetContainingTypeLib. If it refers to another type library, you found a dependency.
A crawler may track dependencies all the way until it has no more type libraries to load.
You don't have to crawl every type of every type library to find the strictly necessary set of types, but the job of the type library importer is to mirror type library information to .NET type info and metadata assemblies, so it imports type libraries in full. It's easier to implement, to explain/understand what it's doing and the output is reusable outside the context of the root type library.
If you didn't use early binding, your type library would instead mention IDispatch, IUnknown and/or VARIANT, which would make it impossible to detect any dependency.
You may use registration-free COM in isolated applications to have the dependencies sorted out, but it still doesn't have to be a proper dependency tree, e.g. you may state all dependencies in one manifest.
And remember that type library != DLL. A type library may be embedded as a resource in a DLL or in its own TLB file.
So, this whole talk is about type dependencies, not class/component or other runtime dependencies.

I don't think it is actually statically analyzing all the dependencies.
I think it is just adding the COM references which are part of the public API of the DLL. These would be plainly visible in the typelib which is part of the DLL, as far as I understand it.
Probably other dependencies which are used internally but not in the public interface are neglected.

Implementing Interface using Reflection c#

I have a requirement where I need to implement an interface in my project which is present in a third part DLL. I'm loading this DLL using reflection. Is it Possible?
class MyClass : I3rdPartyInterface
{
//implementing interface
}
Here, the I3rdPartyInterface is the interface present in my 3rd Party DLL.
This DLL could, or could not, be present on Client machine my software product is installed. If it is present, then i should implement the interface methods.

Your best option is to write a new project that references that dll and implements the interface - and load that in runtime.
The new dll "translates" between the external dll types and your application's types - that way there is no direct dependency between your app and the external dll.
You can generate and compile code at runtime but for this scenario it's just simpler to create a wrapper/translator dll

Embed native dll or .NET assembly into COM

I have a .NET library and I want to wrap it by COM to invoke its functions from C++. Fortunately, this library is open source and if I add COM-visible class right inside this project - it works:
[Guid("38F752CC-20F1-4729-B1E3-EE0AAD145052")]
public interface IQRCodeUI
{
string GetDecodedString(string encodedString);
}
[Guid("D4CFCDFA-6718-494D-A23F-EBC0F9550377")]
public class QRCodeUI : IQRCodeUI
{
public string GetDecodedString(string encodedString)
{
return decoder.decode(encodedString);
}
}
decoder is a class from this very library.
But what to do in case if I would have compiled assembly? I tried to create class library (COM) and add .NET library as embedded resource to it. Without results! During compile it said something like cannot register assembly "path\name". Cannot load file or assembly "nameOfAssembly" or its dependency. Cannot find the file. Apologise, I can't provide original text of the error, because I have MSVS which language differs from English. Is it possible to resolve this issue?

If your task is to call .NET library from C++ via COM, why you're adding .NET library as an embedded resource into some new COM class library?
Just make existing third party assembly COM-visible and call it from C++, VB6, etc.
There are a number of docs all over the internet of how to make .NET assembly COM-visible. None of them, as I recall, contain recommendations to embed .NET assembly into COM class assembly.
Start with:
Best Practice in Writing a COM-Visible Assembly (C#)

Access .net dll through JNA in java

I have a .net 4.0 dll it has a namespace and in that namespace there is a class, I wants to access procedures inside that class using jna.
I have included jna.jar as well as platform.jar(in case) using maven,
My java code looks like this
MyConfiguration interface
import com.sun.jna.Library;
public interface MyConfiguration extends Library{
public void callInterface();
}
Accessing dll code
MyConfiguration myAPI = (MyConfiguration) Native
.loadLibrary("dll/MyAPI.dll", MyConfiguration.class);
System.out.println("Interface Created");
System.out.println("Calling Interface");
myAPI.callInterface();
but i am getting the exception--->
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking up function 'myInterface': The specified procedure could not be found.
at com.sun.jna.Function.<init>(Function.java:208)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:536)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:513)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:499)
at com.sun.jna.Library$Handler.invoke(Library.java:199)
at com.sun.proxy.$Proxy0.myInterface(Unknown Source)
at foo.App.main(App.java:83)
I have checked the dll using dll decompiler tool, and it has the called function, can somebody help out.

dll using dll decompiler tool
You need to use a PE (portable executable) viewer to look for entries in the export table. (Depends is one.)
Most .NET DLLs don't export functions that way. When they do, it's through a mechanism called Reverse P/Invoke, which isn't supported by most Microsoft .NET language compilers. The C++/CLI language was designed for this purpose.
You might find a shorter path to success with a Java-.NET bridge product. Or, a Java-COM bridge product if the .NET DLL exposes classes as COM objects. (Use OLE/COM Object Viewer to inspect a COM DLL.)
Also, be sure the DLL has the same bitness as your JVM process (e.g., java.exe or javaw.exe), unless you are using as an out-of-process COM object.

System namespace in another DLL

Here's my problem:
I am using a DLL library (not from the .NET framework) which contains a System namespace with the Tuple and Lazy classes.
When I try to compile my project the compiler throws some errors stating that these classes exist in mscorlib.dll and another DLL.
So, how can I use the classes from the .NET Framework and don't delete the reference to the other DLL?

If they have the same namespace etc, then the only way to disambiguate is to use an extern alias. In the solution explorer, change the Aliases property of this rogue reference to something else, for example foo (instead of global).
Now, in the class files where you need types from that assembly, you'll have to add (at the very top):
extern alias foo;
And then later down in the code you can use:
foo::Some.Namespace.TheType
or equally:
foo.Some.Namespace.TheType
Basically, the alias name becomes an extra level of disambiguation. The default alias, for reference, is global. Note also, however, that while the compiler is fine with this, the VS2012 IDE still has a few... kinks with extern alias: https://connect.microsoft.com/VisualStudio/feedback/details/770464/ide-but-not-compiler-incorrectly-reports-an-error-when-using-extern-alias-to-disambiguate-types

It sounds like the third party library you're using was designed to be used for .NET 2.0 or .NET 3.5.
I'd be very surprised if the third party didn't also supply DLLs for .NET 4+ - I strongly suspect you can just replace the DLLs which the ones for your target framework version and rebuild.

This is probably a library targeted for .NET 2 or 3.5, which added own implementations for .NET 4 features (Tuple and Lazy). Look for an updated .NET 4 version of this library.