I have a managed DLL (written in C++/CLI) that contains a class used by a C# executable. In the constructor of the class, I need to get access to the full path of the executable referencing the DLL. In the actual app I know I can use the Application object to do this, but how can I do it from a managed DLL?
Assembly.GetCallingAssembly()
or
Assembly.GetExecutingAssembly()
or
Assembly.GetEntryAssembly()
Depending on your need.
Then use Location or CodeBase property (I never remember which one).
#leppie: Thanks - that was the pointer I needed.
For future reference, in C++/CLI this is the actual syntax that works:
String^ appPathString = Assembly::GetEntryAssembly()->Location;
GetExecutingAssembly() provided the name of the DLL
GetCallingAssembly() returned something like System.Windows.Forms
GetEntryAssembly returned the full path, similar to GetModulePath() under Win32.
Related
I've got a situation where I can't change a CLI header that declares several symbols in the global scope, and then those symbols are then used by a function which IS inside a namespace, and that function is exported in an assembly I need to make use of.
Below is a bit of puedo code to help illustrate the Visual Studio setup. Also, I'm using the 2008 toolchain which is pre C++11 making the 'enum class' a managed object. Also note that it also doesn't have the access specifier (I did not write this) which makes it private.
ExportingAssembly.vcxproj
|->SomeHeader.h
| |->enum class SomeSymbol
|->SomeSource.c
|->SomeNamespace
|->void SomeFunction(SomeSymbol arg)
ImportingAssembly.vcxproj
|->Ref ExportingAssembly
|->ImportingSource.c
|->Using SomeNamespace;
|->void MyFu(){ SomeSumbol a = 0; SomeFunction(a); }
The problem is that those global symbols are obviously not visible to the importing assembly and if I include the header for those symbols it results in an incompatibility between my assembly and the one I'm importing
error C2664: 'ExportAssemblyNamespace::SomeFunction(SomeSymbol arg)': can't
convert parameter 1 from 'SomeSymbol" to 'SomeSymbol'
Now I CAN change the exported assembly (the project file and/or the source file) so I just hope I can somehow make those global symbols part of the exported assemblies' namespace so the importing assembly will see them. Or failing that, somehow locate the global symbols in the exported assembly (I can see the global symbols are in the PE MetaData Tables).
Any ideas. Or is a symbol without an access specifier private and impossible to make use of via referencing the assembly?
Or is a symbol without an access specifier private and impossible to make use of via referencing the assembly?
Yes, a symbol without an access specifier is private. It's not quite "impossible" to make use of; the only way is via reflection.
The fact that you have some things in a namespace, and some not, doesn't matter here. But you should have your function as part of a class, since global functions aren't part of the CLR. (C++/CLI creates a class to hold the global functions, but it's not a public class, and I think it has an invalid name anyway.)
Add the keyword public to your enum, and enclose your function in a public ref class.
I have an application where I want to instantiate a class that is completely outside the application, perhaps written at a later date by a third party. So the class cannot be known, but the interfaces in the class are known. So I want to use late binding.
In my code (VB.NET), I have the following:
Dim a As Object
a = Activator.CreateInstance("MyNameSpace.CustomClass", "")
MsgBox(a.Name)
I get an exception at the second line: Could not load file or assembly 'MyNameSpace.CustomClass' or one of its dependencies. The system cannot find the file specified. even though the assembly is in the same folder as the executable. I can't use Type.GetType() because the type is not known to the calling assembly.
You need the CreateInstanceFrom method.
var typeReference = Activator.CreateInstanceFrom(assemblyPath,
fullyQualifiedClassName);
But, for me, MEF would be a better solution as you can bind the Import/Export on the interface.
i have a compiled dll library but i have no documentation about it. There is a way to get the public interface of a dll (at least function names, params numbers and type).
Thanks
You would have to decompile it and analyze each function, its calling convention, parametrs count, parameters meaning (unless it comes with some PDB, but I doubt it), I've done something like this before, it's complicated work, but it can be done.
In order to retrieve the public symbols (functions and variables) exported by a Dynamic-Link Library, one can use the well-known dependency walker. Parameters and Types are only available when the associated PDB file is available (which does not seems to be your case).
You could use the OLEViewer that comes with Visual Studio to view the TypeLib of the DLL if it is a COM library. This would give you the information you need.
I have found out that it is essential to derive my base MFC class from CWinApp and use AFX_MANAGE_STATE(AfxGetStaticModuleState()) for every exported method! (if MFC is dyn. linked)
I would like also using an pointer to external native C++ object in MFC dll constr (I should use extension dll - but how work this with CLI???)
Have someone a good example for doing this kind of wrapping ?!
Thanks and greets,
leon22
I'm not sure what your question or your problem is. You don't always need to use the AFX_MANAGE_STATE macro, it depends on the circumstances. What's a 'MFC dll constr' ? What does 'I should use extension dll' mean? (I know what an extension dll is, but what do you mean by 'should' in this context?) What does 'this kind of wrapping' mean?
I'm getting a compiler error saying that "Acme.Business.User" is not defined.
I have a class library project called "Acme.Business" that has "Acme.Business" as the assembly name and root namespace as well. None of the classes use the "Namespace" keyword, so they all should exist in the namespace "Acme.Business".
I also have a class library project called "Acme.Web" that has a project reference to "Acme.Business". Again "Acme.Web" is the project name, assembly name, and root namespace.
Here's the weird part. If I add a class to "Acme.Web" I can type "Imports Acme." at the top and see both namespaces appear in intellisense like you'd expect, but if I try to do "Dim x as New Acme.Business.User" then "Business" doesn't show up in intellisense and I get an error saying "Acme.Business.User" is not defined.
I can't see what I'm doing wrong! Please help. Thanks.
I think you may be misunderstanding how project default namespaces work. The default namespace is a project file setting that simply tells Visual Studio what namespace to add to each file when you add a new class file to the project. If you have removed all of these namespaces from the code files then your types do not exist in that namespace.
This means that all of your types in the Acme.Business assembly live in the global namespace which is probably not what you want. In order to get the desired behavior you will need to add the namespaces back into your code files as that is the only way the compiler will create type names with that namespace.
OK, I figured out that the behavior I was seeing was because I was declaring namespaces within the code in Acme.Web the way I was used to in C# which is to fully qualify it, ie. Namespace Acme.Web.UI.WebControls. I didn't realize that in VB.NET it's building on top of what was specified for the root namespace. I removed the portion that was specified in the "root namespace" setting of my project and it started working. So my namespaces in code for Acme.Web now look like Namespace UI.WebControls.