标签: dllexport

我最近遇到了一个安装在我的系统上的DLL,Dependancy Walker(以及我试过的其他所有实用程序)说按名称或序号导出零,但文件大小约为4mb.我认为DLL的唯一目的是导出函数供其他代码使用,那么没有可见导出的dll的目的是什么？

出于安全目的,我想将我的宏从Excel工作簿中的VBA保存到我稍后将从该文件调用的DLL库文件.

这样就可以将我的宏的任何版本部署到公司的PC上,但没有人会看到它背后的真实代码.

这怎么可能？我已经读过转换为C++和创建DLL.这有什么分步解决方案吗？

我正在尝试将一些代码移动到共享库中(在独立编译时工作正常)但是遇到了类内联函数的一些问题.mingw/gcc v4.7.2.

部分问题似乎是因为我更喜欢在类声明之外定义我的内联函数(它使类声明更整洁,更容易阅读).我一直认为这是可以接受的,等同于在类声明中定义......但似乎并非总是如此.我已经创建了一个简单的示例来演示问题.(显然dllexport通常会在宏中导入/导出.)

标题:

// Uncomment one at a time to see how it compiles with: -O2 -Winline
//#define INLINE_OPTION 1 // implicit - builds without inline warnings
#define INLINE_OPTION 2 // simple external inline - gives inline warnings
//#define INLINE_OPTION 3 // external forced inline - gives inline errors

class __attribute__((dllexport)) Dummy {
public:
    Dummy() : m_int{0} {}
    ~Dummy() {}
    #if INLINE_OPTION == 1
    int get_int() const { return m_int; }
    #else
    int get_int() const;
    #endif
    int do_something();
private: …

我正在尝试使用 Clang++ 构建一个共享库（Windows 的 dll）。

我已经运行了以下命令：

clang++ -c -o hello.o hello.cpp
clang++ -shared -v -o hello.dll hello.o

第一个命令工作正常，但是当我尝试构建 dll 时出现此错误：

clang version 3.2 (tags/RELEASE_32/final)
Target: i686-pc-mingw32
Thread model: posix
 "c:/MinGW/bin/g++.exe" -shared -v -m32 -o worker.dll worker.o
Using built-in specs.
COLLECT_GCC=c:/MinGW/bin/g++.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)
COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.6.2/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../;/mingw/lib/
COLLECT_GCC_OPTIONS='-shared' '-v' '-m32' '-o' 'worker.dll' '-shared-libgcc' '-mtune=i386' '-march=i386'
 c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/collect2.exe --shared -Bdynamic -e _DllMainCRTStartup@12 --enable-auto-image-base -u …

问题简介:

我必须通过提供DLL文件,LIB文件和c函数头文件的API来控制某个设备,其函数被声明为dllimport.

当我在C++项目中使用API​​时,一切正常 - 我包含头文件,lib,dll,并调用头文件中声明的函数.

当尝试使用[DllImport]属性从C#.NET项目调用这些函数时,问题就出现了:使用确切的名称和参数声明函数,并且运行代码不会抛出任何异常.然而,设备根本没有响应,就像从未实际调用过的函数一样.

它是如何在C头中声明的:

int __declspec(dllimport) Init_Card_RTx(unsigned short device_num, unsigned short enabled_channels, unsigned short xmt_channels);

它是如何在C#中声明的:

[DllImport(Path, CallingConvention = CallingConvention.Cdecl, EntryPoint = "Init_Card_RTx")]
public static extern int Init_Card_RTx(UInt16 device_num, UInt16 enabled_channels, UInt16 xmt_channels);

问题:

• 那是因为标题中的函数被声明为dllimport吗？
• 在这种情况下,我是否必须使用声明为dllexport的C++函数包装DLL？
• 可以从C#访问C DLL所需的步骤是什么？
• 在C#项目中,我是否还必须包含LIB文件？不只是DLL文件本身？

我们正在处理的项目（在 cpp 中）从 dll导出枚举类型。在导出时我们遇到了一些问题，所以我想问一些与导出 枚举类型相关的问题。

我认为枚举的行为类似于“某种”常量，因此它们不向用户提供任何“功能”。那么，我们可以省略enum 的导出吗？

或者

枚举是否为最终用户提供了一些功能（除了作为常量），因此有必要导出它们？

更多细节 ：

我们有一个包含以下代码的头文件：

enum DECL_BASE logical_state
{
    LOGICAL_TRUE,
    LOGICAL_FALSE,
    LOGICAL_DEFAULT
};

//DECL_BASE is __declspec(dllexport)

这段代码编译得很好，没有警告或错误。我只是想知道导出这个有什么用途。

谢谢

我在MSVC2017中有以下场景：

1. 具有该功能的静态库bool foo()
2. 链接上面静态库的动态链接库
3. 使用显式运行时链接加载动态链接库并foo()通过以下方式调用的应用程序GetProcAddress

在静态库中，foo()定义如下：

extern "C" __declspec(dllexport) bool foo() 
{
    return true;   
}

现在，由于foo()不被动态链接库使用，因此它的符号不会被导出，因此在应用程序使用时无法找到GetProcAddress。

我努力了：

#pragma comment(linker, "/include:foo")

和：

#pragma comment(linker, "/export:foo")

如果我将定义移动到动态链接库（不是可行的解决方案） ，我可以使用 Dependency Walker 看到导出的内容foo()，但是当我使用上述链接器开关将定义保留在静态库中时，我似乎无法导出符号。我认为这是因为该符号仍未使用，因此仍然没有导出？

我想要一个适用于 Windows 上的 MSVC 和 Linux 上的 Clang 的解决方案。谢谢！

当我尝试将以下函数导出为dll时:

extern "C" __declspec(dllexport) void some_func()
{
  throw std::runtime_error("test throwing exception");
}

Visual C++ 2008给了我以下警告:

1>.\SampleTrainer.cpp(11) : warning C4297: 'some_func' : function assumed not to throw an exception but does
1>        The function is extern "C" and /EHc was specified

我需要extern"C",因为我使用Qt QLibrary加载DLL并解析函数名称.没有extern"C"就找不到some_func()函数.

我在共享库中有这个类：

class Interface {
    int m_ref;
public:
    FOO_EXPORT virtual ~Interface();
    virtual void foo() = 0;

protected:
    void ref() { ++m_ref; }
    bool deref() { return --m_ref; }
};

// cpp file:
Interface::~Interface() {}

哪里FOO_EXPORT是__attribute__((visibility=default))GCC 的，我正在使用-fvisibiliy=hidden -fvisibility-inlines-hidden.

但是当我使用Interface另一个库中的 时，我得到了 typeinfo 和 vtable 的未定义引用。

在 MSVC 上，其中FOO_EXPORT) declspec(dllexport/dllimport` 工作正常，因为导出虚拟函数时会导出 vtable。

我当然可以导出整个班级：

类 FOO_EXPORT 接口 {

但这也导出所有内联方法。

是否有一个中间立场，仅导出~Interface()vtable，而没有其他内容？

如果您知道：为什么 GCC 与 MSVC 不兼容？

我正在尝试使非托管导出基本示例正常工作。

我正在执行的步骤：

• 创建一个新的类库项目。
• 使用 nuget 添加 UnmanagedExports。
• 将 CPU 目标更改为 x86。
• 将我正在关注的教程中的代码添加到 .cs 文件中。
• 建造

该项目已成功构建，但是当我使用DLL Export Viewer检查我的 dll 时，我看不到任何函数。

我使用的是 32 位操作系统和 SharpDevelop 4.4（我也尝试过其他 SharpDevelop 版本和 64 位操作系统，结果相同）。

我的 sln 文件：

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "test", "test\test.csproj", "{AFAA816C-65B2-4B58-9FB2-EB7482AA0F5F}"
    EndProject
    Global
        GlobalSection(SolutionConfigurationPlatforms) = preSolution
            Debug|x86 = Debug|x86
            Release|x86 = Release|x86
        EndGlobalSection
        GlobalSection(ProjectConfigurationPlatforms) = postSolution
            {AFAA816C-65B2-4B58-9FB2-EB7482AA0F5F}.Debug|x86.ActiveCfg = Debug|x86
            {AFAA816C-65B2-4B58-9FB2-EB7482AA0F5F}.Debug|x86.Build.0 = Debug|x86
            {AFAA816C-65B2-4B58-9FB2-EB7482AA0F5F}.Release|x86.ActiveCfg = Release|x86
            {AFAA816C-65B2-4B58-9FB2-EB7482AA0F5F}.Release|x86.Build.0 = Release|x86
        EndGlobalSection
    EndGlobal

我的 csproj 文件：

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build"> …