IJW在静态库上？初学者问题 [英] IJW on static library? Beginner question

问题描述

你好，


我有一个很大的遗留MFC应用程序。通常，有一个

可执行文件以及几个MFC DLL。这些DLL中的一个是由

在许多库中静态链接创建的，从而产生一个非常大的DLL，其中包含大部分代码的

。


我已经下载了MFCWinFormsSample.EXE，并注意到主应用程序

可以保留为本机可执行文件（即没有CLR支持），而各种

..DLL可以被标记为具有CLR支持（使用/ clr开关）。


我的问题是，可以应用CLR的粒度级别是什么？
支持 - 它是仅在可执行文件/ DLL级别还是可以在

静态库级别应用，其中该静态库链接到一个DLL

没有启用CLR支持（其他静态库也没有？b $ b启用了CLR支持）？我希望后者是不可能的，但我想我会问b $ b。我的动机是我有很多原生代码，并希望尽可能保持原生，以保持最佳性能

并避免放置所有其他静态库中的一堆pramas

让它们保持原生。我正在使用VS 2005，如果它有任何区别。


谢谢，

Notre

Hello,

I have a large legacy MFC application. As is typical, there is an
executable along with several MFC DLLs. One of these DLLs is created by
staticly linking in many libraries resulting in one very large DLL that has
the bulk of the code.

I''ve downloaded the MFCWinFormsSample.EXE and have noticed that the main app
could stay as a native executable (i.e. no CLR support) whereas the various
..DLLs can be marked as having CLR support (using /clr switch).

My question is, what is the level of granularity that one can apply the CLR
support - is it only at the executable/DLL level or can it be applied at a
static library level, where that static library is linked into a DLL that
does not have CLR support enabled (and the other static libraries also don''t
have CLR support enabled)? I expect the latter is not possible but thought I
would ask. My motivation is that I''ve got a lot of native code and would
like to keep it native as much as possible, to maintain optimal performance
and to avoid putting a bunch of pramas in all the other static libraries to
keep them native. I''m using VS 2005, if it makes any difference.

Thanks,
Notre

推荐答案

" Notre Poubelle" <无************ @ online.nospam>在留言中写道

news：33 ********************************** @ microsof t.com ...

"Notre Poubelle" <no************@online.nospam> wrote in message
news:33**********************************@microsof t.com...

你好，

我有一个很大的遗留MFC应用程序。通常，有一个
可执行文件以及几个MFC DLL。其中一个DLL是通过静态链接在许多库中创建的，从而产生了一个非常大的DLL，它具有大部分代码。

我已经下载了MFCWinFormsSample.EXE，并注意到主要的
应用程序可以保留为本机可执行文件（即没有CLR支持），而
各种
.DLL可以标记为具有CLR支持（使用/ clr开关）。

我的问题是，一个人可以应用的CLR
支持的粒度级别是什么 - 它只在可执行文件/ DLL级别还是可以在静态库级别应用，其中静态库链接到一个没有启用CLR支持的DLL（其他静态库也可以不用） 't
启用了CLR支持）？我希望后者是不可能的，但我想
我会问。我的动机是我有很多原生代码，并希望尽可能保持原生，以保持最佳的性能
并避免放入一堆pramas在所有其他静态库中
使它们保持原生。我正在使用VS 2005，如果它有任何区别。

Hello,

I have a large legacy MFC application. As is typical, there is an
executable along with several MFC DLLs. One of these DLLs is created by
staticly linking in many libraries resulting in one very large DLL that
has
the bulk of the code.

I''ve downloaded the MFCWinFormsSample.EXE and have noticed that the main
app
could stay as a native executable (i.e. no CLR support) whereas the
various
.DLLs can be marked as having CLR support (using /clr switch).

My question is, what is the level of granularity that one can apply the
CLR
support - is it only at the executable/DLL level or can it be applied at a
static library level, where that static library is linked into a DLL that
does not have CLR support enabled (and the other static libraries also
don''t
have CLR support enabled)? I expect the latter is not possible but thought
I
would ask. My motivation is that I''ve got a lot of native code and would
like to keep it native as much as possible, to maintain optimal
performance
and to avoid putting a bunch of pramas in all the other static libraries
to
keep them native. I''m using VS 2005, if it makes any difference.

实际上，你可以在每个功能上控制CLR /本机编译

基础。保持大部分代码原生

并将其与几个与WinForms交互的支持CLR的模块链接应该没有问题。


-cd

Actually, you can control the CLR/native compilation on a per-function
basis. There should be no problem with keeping the bulk of your code native
and linking it with a few CLR-enabled modules that interact with WinForms.

-cd

非常感谢您的回复Carl。当你说你可以在每个函数的基础上控制
CLR / native编译时，你的意思是使用pragma吗？

或者这是另一种方法吗？


理想情况下，我不需要对我的大多数静态
库做任何事情，而是创建一个新的静态库CLR支持并且

将此链接到通用DLL中，该DLL没有启用CLR支持。


此方案是否合理？

谢谢，

Notre

Thank you very much for your reply Carl. When you say you can control
CLR/native compilation on a per function basis, do you mean by using pragmas?
Or is this another way to do this?

Ideally, I wouldn''t have to do anything at all to most of my static
libraries, but instead create a new static library CLR support enabled and
link this into the common DLL, which does not have CLR support enabled.

Is this scenario reasonable?
Thanks,
Notre

" Notre Poubelle" <无************ @ online.nospam>在消息中写道

新闻：EE ********************************** @ microsof t.com ...

"Notre Poubelle" <no************@online.nospam> wrote in message
news:EE**********************************@microsof t.com...

非常感谢你的答复卡尔。当你说你可以在每个函数的基础上控制CLR /本地编译时，你的意思是使用
编译指示吗？
或者这是另一种方法吗？


是的，＃pragma（un）管理

理想情况下，我不需要对我的大部分静电做任何事情
库，但改为创建一个新的静态库CLR支持启用，并将其链接到没有启用CLR支持的公共DLL。

这种情况是否合理？

Thank you very much for your reply Carl. When you say you can control
CLR/native compilation on a per function basis, do you mean by using
pragmas?
Or is this another way to do this?
Yes, #pragma (un)managed

Ideally, I wouldn''t have to do anything at all to most of my static
libraries, but instead create a new static library CLR support enabled and
link this into the common DLL, which does not have CLR support enabled.

Is this scenario reasonable?

我相信它应该可以正常工作，是的。


-cd

I believe it should work just fine, yes.

-cd

这篇关于IJW在静态库上？初学者问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！