I have multiple dll which build from different projects in different solutions, build for different logic for different company.
Each of the dll have the same assembly name and same namespace and same version.
Some DLLs have some methods and types with the same name but different implementation and some unique methods and types.
How can I reference those dlls to use in a new project.
I tried to use add all DLLs as reference and change the alias name of each reference alias.
After, add the extern alias for each DLLs.
But I found out extern alias only work the last DLL has been referenced to.
All previous dlls shown an error
The extern alias 'xxx' was not specified in a /reference option in visual studio 2017.
Any idea what is the cause of this and how to resolve?
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.
Good day,
I have used dll imports for "user32.dll" in the past.
However, I am trying to import a class library into my application which has some namespaces which come into conflict with namespaces which are already imported and referenced from other class libraries.
How can I reference this dll and only use the namespaces contained in it, or override the other namespaces imported from other class libraries in one class without it affecting the rest of the application.
I am still pretty new, this may not be possible.
Thank you.
To summarize the relevant issues:
In VB.NET one can use the Declare statement to call win32 functions in DLL's with typical EntryPoint constructs.
.NET Assemblies do not provide classical Win32 type EntryPoints (as such they cannot be 'declared')
If one needs to reference a .NET Assembly [or COM] you need to add a reference to the target library when compiling (usually done in the VS IDE or with the /r: switch)
In some cases Namespaces of such referenced Assemblies may collide with others. (i.E. referencing the same Assembly in different versions)
In that case one needs to import the required (conflicting) Namespaces with an Alias
For example:
Assuming you have an assembly with a root namespace Net that could collide with System.Net use:
Imports System
Imports ExtNet = SomeNetworkAssembly
Then in this case to access members of that assembly use ExtNet instead of Net
Note you can name the ExtNet part as you wish.
In C# one can do it via the using keyword instead.
I'm writing a CLR wrapper for an unmanaged C++ library.
There are two files I'm including from the unmanaged lib:
//MyCLIWrapper.h
#include "C:\PATH\TO\UNMANAGED\Header.h"
#include "C:\PATH\TO\UNMANAGED\Body.cpp"
Then I'm writing CLI implementations for the unmanaged library functions:
//MyCLIWrapper.h
// includes ...
void MyCLIWrapper::ManagedFunction()
{
UnmanagedFunction(); // this function is called successfuly
}
However, if my Unmanaged function contains calls to other functions that are defined in other unmanaged header files. This causes a compiler linkage error.
If I add includes to the unmanaged headers that define these functions, my errors get resolved. However, there is a lot of functions, and a lot of includes required.
Is there a different way to approach this?
EDIT:
P.S.
My managed code is in a separate Visual Studio project (output - DLL), and the compile settings are set to /CLR. Unmanaged code is in a separate Win32 project (output - DLL).
Also, after more research I concluded that theoretically I could set my Win32 unmanaged project to CLR and just add my managed classes and headers in there as an entry point, and then it would all compile into a single DLL file. That would probably solve (?) the linkage errors. However, I would prefer to preserve the loose coupling as well as the additional series of problems that can raise from setting my unmanaged project to CLR.
EDIT #2:
The unmanaged class that I'm referencing (body.cpp, header.h) contains includes to the required files that define the functions that are causing the problems. However, my managed code doesn't pick up on the includes that are in the unmanaged body.cpp and header.h.
Linker errors are a different kettle of fish from compiler errors. You forgot to document the exact linker errors you see, but a very common mishap when you compile code with /clr in effect is that the default calling convention for non-C++ member function changes. The default is __clrcall, a convention that's optimized for managed code. While functions compiled without /clr defaults to __cdecl. Which changes the way the function name is mangled. You see this back in the linker error message, is shows that it is looking for a __clrcall function and can't find it.
You'll need to either explicitly declare your functions in the .h file with __cdecl. Or tell the compiler that these functions are not managed code. Which is the best way to tackle it:
#pragma managed(push, off)
#include "unmanagedHeader.h"
#pragma managed(pop)
Solution was fairly simple:
I added both unmanaged and managed projects to a single solution in Visual Studio.
Set the unmanaged project's "Configuration Type" to "Static Library" (.lib).
Right click on the managed project -> References -> Add Reference -> Projects -> -> Add Reference.
Then in my managed class, I include the header.h (only) just like I did in my question.
Compiled successfully!
Thank you
I've googled for creation of namespaces and found some very useful examples, what these examples didn't have is how do I compile and implement my created namespace on my system so I can include it from my various applications.
So for example, if I create a namespace to load a config file from my application path and insert it to an array, Do i need to include the namespace on any project I use or is there a way to make it part of my environment?
You're thinking of Class Library (DLL) projects.
When you start up a new Visual Studio project, select Class Library rather than Windows Form project. This will compile your namespaces as a DLL (exposing your public classes), which can be referenced in other projects.
If you want to include a namespace that you created you have to add a reference to your project first. If you have compiled your code into a .dll file, then simply add the reference to the .dll file to your project and then at the top of your classes put the "Imports [Namespace]". If you haven't compiled your namespace, add the project (with the namespace that you created) to your solution, add the reference to it (under the Projects tab), and then use the Imports statement.
You are confusing the concept of a namespace with the concept of a project, especially of a class library project.
A class exists within a namespace. If no namespace is defined, then the class still exists within the global namespace (the one with no name).
In any case, it's classes that do the work. Namespaces are only so that you can have a class named Book, and I can have a class named Book, and so that TriDat.Book can exist at the same time as JohnSaunders.Book.
I have .lib file with its header (.h) file. This file have a few functions that need to be used in C# application.
After googling I found that I need to create a dynamic DLL from this static library and call this dynamic DLL from C# code using interop.
I have created a win32 project and selected type DLL.
Included header file and added .lib to additional dependencies.
I am able to see the functions defined in the static library (when I press ctrl + space).
As a total newbie I do not know how I can export the function, which is, in .lib with following signature:
void testfun( char* inp_buff, unsigned short* inp_len, char* buffer_decomp,unsigned *output_len,unsigned short *errorCode)
I want same signature in my dynamic DLL with a different name.
What to write in header file and .cpp file?
If you can recompile your lib, just add __declspec(dllexport) to the signatures of all of the functions you want to be exported.
void __declspec(dllexport) testfun( char* inp_buff, unsigned short* inp_len, char* buffer_decomp,unsigned *output_len,unsigned short *errorCode)
If you can't do that, then you can export them by writing a .def file instead. Using def files you can even change the name of a function as it is exported.
http://msdn.microsoft.com/en-us/library/28d6s79h.aspx
---- contents of mylib.def ----
LIBRARY
EXPORTS
testfun
newname=testfun2
Then when you link the dll, include mylib.def
link /dll /machine:x86 /def:mylib.def mylib.lib
Edit2:
note that pinvoke assumes that the functions you import will have _stdcall calling convention unless you say otherwise. So you might need to do this as well, in your C# code.
[DllImport("mylib.dll", CallingConvention=CallingConvention.Cdecl)]
Or, you could change your C++ code to be __stdcall
void __declspec(dllexport) __stdcall testfun( char* inp_buff, ...
This is what you can do
Add the following code to you .H file. rename "MYPROJECT" to your project name
#ifdef MYPROJECT_EXPORTS
#define MYPROJECT_API __declspec(dllexport)
#else
#define MYPROJECT_API _declspec(dllimport)
#endif
Go to Properties->C++->Preprocessor and Add the defenition - MYPROJECT_EXPORTS
Add MYPROJECT_API to all the functions you want the dll to expose eg:
MYPROJECT_API void Test();
Go to Project properties General -> Configuration Type change it to Dynamic Dll
You are done
Create new Dll project using Visual Studio Application Wizard, and check "Exports Symbols" in one of the Wizard steps. It creates sample Dll which exports class, function and variable. You can learn from this sample, how to do this.
Generally, every exported function is declared as __declspec(dllexport). In a client project it is declared as __declspec(dllimport). Dll code uses the constant which is defiled as __declspec(dllexport) inside of Dll project, and __declspec(dllimport) in any other place.
there are two versions of LIB can be generated,
the fist is the dynamic lib, (source file + header+ dynamic lib) --> to access the DLL
or static lib=(dynamic lib+DLL) --> (Source file+header) --> to access the DLL.
if you have the Dynamic Lib > there is no way to create the DLL (you cannot get something from nothing), dynamic lib is just an interface,
but if you have the Static Lib then there is no need to DLL to access it is functions.
Take a look at my answer to this question for a possible solution. Almost positive this will work for you...
In short: Enable the "Use Library Dependency Inputs" option in your Linker settings. If set to "true", it will force linking ALL symbols & code declared in every LIB specified as input to the project.
The issue here is not how the code is decorated, it's the extra step of creating a static library that contains all of the entry points, and trying to build the dll out of that.
If you go with the __delcspec approach and build the static library first, then try to link to it when building a DLL, you'll have to solve the dead-code stripping problem.
When you link, the obj srcs are used to find all of the decorated exports and dependencies are resolved, everything else is stripped. If you have no DLL src, so no obj files (except maybe a dll main), all of the code in the lib you want to export will be stripped (regardless of the attributes).
So, you either have to:
Tell the linker not to strip unused code, which is probably going to give you a lot of stuff you don't want.
Use a def file to expose the exports manually
Link the dll against the obj files used to create the lib instead of linking to the lib directly.
Or maybe create dummy code that references the functions you want to export from something you are exporting.