Greetings!
Some classes that once compiled without problems on VS 2003 have now
problems on VS 2005 Beta 1. I'm talking about a __nogc class that is
exported with __declspec(dllexport).
The compiler message is this:
VCSelectLibraryForm.cpp
...\Forms\QiForm.h(48) : error C3395: 'TQiForm::GetDotNetMouseButton' :
__declspec(dllexport) cannot be applied to a function with the __clrcall
calling convention
This is odd because I'm not using "__clrcall" anywhere in my code (at least
not explicitly). Not in the function declaration, not in the class
declaration, anywhere!
I have 2 questions then:
1st) Any reason why this could be happening? Project options, parameter that
might make all calls on a given project __clrcall, etc?
2nd) Independently of the problem: I know an exported function from a DLL
can't be guaranteed to be called from a managed site. Thus, theoretically it
can't be exported. Is this the end of the story? I mean, if I compile code
with /clr:safe or /clr:pure in order to cut the unmanaged entry points from
functions and have a complete MSIL code, I won't be able to modularize it in
DLLs?
My compilation parameters are:
("Arquivos de programas" is the portuguese version of the "Program Files"
folder) ;)
/Od /Og /Ob2 /Oi /Ot /I "C:\Arquivos de programas\Microsoft Visual Studio
..NET 2003\Vc7\PlatformSDK\Include" /I "." /I ".." /I "..\..\Libbuilder" /I
"..\..\Persistence" /I "..\..\QiReportBuilder" /I
"..\..\Controls.NET\QiControls" /AI "..\VCRLibDll" /D "WIN32" /D "NDEBUG" /D
"_WINDOWS" /D "_USRDLL" /D "QIVFORMS_EXPORTS" /D "VISUAL_C" /D "NULL=0" /D
"_USE_MATH_DEFINES" /D "__TRACE" /D "_WINDLL" /D "_MBCS" /FD /EHa /MD /GS
/GR /Fo"..\VCRObj/" /Fd"..\VCRObj/vc80.pdb" /W3 /nologo /c /Wp64 /Zi
/clr:oldSyntax /TP /wd4290 /wd4251 /wd4275 /wd4311 /wd4800 /FU
"QiVControls.dll" /FU
"c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Micro soft.VisualC.Dll" /FU
"c:\WINXP\Microsoft.NET\Framework\v2.0.40607\mscor lib.dll" /FU
"c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.dll" /FU
"c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.Data.dll" /FU
"c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.Design.dll" /FU
"c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.Drawing.dll" /FU
"c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.Windows.Forms.dll" /FU
"c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.XML.dll"
Thanks,
Fabro 7 2595
1) __clrcall is implicit for managed types (__nogc and __gc) classes.
__declspec(dllexport) does not apply to managed types. Hence, it is now
disallowed.
2) I am not sure I understand your question here. As long as your type is
not a managed type and you don't explicitly specify __clrcall, you should be
able to export it
Thx,
--
This posting is provided "AS IS" with no warranties, and confers no
rights."Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm"
"Gustavo L. Fabro" <gu************************@hotmail.com> wrote in message
news:36*************@individual.net... Greetings!
Some classes that once compiled without problems on VS 2003 have now problems on VS 2005 Beta 1. I'm talking about a __nogc class that is exported with __declspec(dllexport).
The compiler message is this:
VCSelectLibraryForm.cpp ..\Forms\QiForm.h(48) : error C3395: 'TQiForm::GetDotNetMouseButton' : __declspec(dllexport) cannot be applied to a function with the __clrcall calling convention
This is odd because I'm not using "__clrcall" anywhere in my code (at least not explicitly). Not in the function declaration, not in the class declaration, anywhere!
I have 2 questions then:
1st) Any reason why this could be happening? Project options, parameter that might make all calls on a given project __clrcall, etc?
2nd) Independently of the problem: I know an exported function from a DLL can't be guaranteed to be called from a managed site. Thus, theoretically it can't be exported. Is this the end of the story? I mean, if I compile code with /clr:safe or /clr:pure in order to cut the unmanaged entry points from functions and have a complete MSIL code, I won't be able to modularize it in DLLs?
My compilation parameters are:
("Arquivos de programas" is the portuguese version of the "Program Files" folder) ;)
/Od /Og /Ob2 /Oi /Ot /I "C:\Arquivos de programas\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include" /I "." /I ".." /I "..\..\Libbuilder" /I "..\..\Persistence" /I "..\..\QiReportBuilder" /I "..\..\Controls.NET\QiControls" /AI "..\VCRLibDll" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "QIVFORMS_EXPORTS" /D "VISUAL_C" /D "NULL=0" /D "_USE_MATH_DEFINES" /D "__TRACE" /D "_WINDLL" /D "_MBCS" /FD /EHa /MD /GS /GR /Fo"..\VCRObj/" /Fd"..\VCRObj/vc80.pdb" /W3 /nologo /c /Wp64 /Zi /clr:oldSyntax /TP /wd4290 /wd4251 /wd4275 /wd4311 /wd4800 /FU "QiVControls.dll" /FU "c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Micro soft.VisualC.Dll" /FU "c:\WINXP\Microsoft.NET\Framework\v2.0.40607\mscor lib.dll" /FU "c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.dll" /FU "c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.Data.dll" /FU "c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.Design.dll" /FU "c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.Drawing.dll" /FU "c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.Windows.Forms.dll" /FU "c:\WINXP\Microsoft.NET\Framework\v2.0.40607\Syste m.XML.dll"
Thanks, Fabro
Hi there! 1) __clrcall is implicit for managed types (__nogc and __gc) classes. __declspec(dllexport) does not apply to managed types. Hence, it is now disallowed.
Hmmm Let me get this straight:
You said "managed types (__nogc and __gc) classes". Don't you mean managed
code?
As far as I knew (please clear up my mess, if that's the case), a __nogc
keyword "Explicitly declares an unmanaged type."
(http://msdn.microsoft.com/library/de...clrf__nogc.asp)
Still from the help,
"Objects of this type are similar to standard C++ objects in that they are
allocated from the standard C++ heap and are not subject to the restrictions
of a managed object"
This is one of the restrictions (not being able to export). In that case
(with the __nogc keyword), it wouldn't have the restriction. Right?
2) I am not sure I understand your question here. As long as your type is not a managed type and you don't explicitly specify __clrcall, you should be able to export it.
I should be able to export it even if It's an unmanaged type running on a
managed code (because it was compiled with /clr)?
My question was for managed types. It's a design question:
Suppose I want to write a 100% C++/CLI code, using only .NET, MSIL and not a
line of native code.
In this particular scenario, by the information I'm having, I cannot use
__declspec(dllexport) to export a function from a DLL. Does this means DLLs
do not exist on .NET Framework World? Because what would be the point of
having a DLL if I couldn't acess any of its functions? :)
Thanks for the attention,
Fabro
1) Sorry. I meant gc classes (value and ref types (in new syntax)) have
implicit clrcall calling convention and hence cannot use dllexport. I don't
see this behavior on __nogc classes (unmanaged types) on Beta 1. Do you
have a small snippet of code which throws this error?
2) Managed code in assemblies can be exposed by simply declaring them
public. The user of the assembly can add a reference to the dll by using
either #using syntax, by using the /FU compiler switch to force a reference
etc.,
Thx,
--
This posting is provided "AS IS" with no warranties, and confers no
rights."Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm"
"Gustavo L. Fabro" <gu************************@hotmail.com> wrote in message
news:36*************@individual.net... Hi there!
1) __clrcall is implicit for managed types (__nogc and __gc) classes. __declspec(dllexport) does not apply to managed types. Hence, it is now disallowed.
Hmmm Let me get this straight:
You said "managed types (__nogc and __gc) classes". Don't you mean managed code?
As far as I knew (please clear up my mess, if that's the case), a __nogc keyword "Explicitly declares an unmanaged type." (http://msdn.microsoft.com/library/de...clrf__nogc.asp)
Still from the help, "Objects of this type are similar to standard C++ objects in that they are allocated from the standard C++ heap and are not subject to the restrictions of a managed object"
This is one of the restrictions (not being able to export). In that case (with the __nogc keyword), it wouldn't have the restriction. Right?
2) I am not sure I understand your question here. As long as your type is not a managed type and you don't explicitly specify __clrcall, you should be able to export it.
I should be able to export it even if It's an unmanaged type running on a managed code (because it was compiled with /clr)?
My question was for managed types. It's a design question:
Suppose I want to write a 100% C++/CLI code, using only .NET, MSIL and not a line of native code.
In this particular scenario, by the information I'm having, I cannot use __declspec(dllexport) to export a function from a DLL. Does this means DLLs do not exist on .NET Framework World? Because what would be the point of having a DLL if I couldn't acess any of its functions? :)
Thanks for the attention,
Fabro
Hi there! Thanks for the replies!
Answering backwards...
2) Managed code in assemblies can be exposed by simply declaring them
public. The user of the assembly can add a reference to the dll by using
either #using syntax, by using the /FU compiler switch to force a reference
etc.,
Great! I searched for the keywords and now things are much clearer.
1) Sorry. I meant gc classes (value and ref types (in new syntax)) have
implicit clrcall calling convention and hence cannot use dllexport. I don't
see this behavior on __nogc classes (unmanaged types) on Beta 1. Do you
have a small snippet of code which throws this error?
In fact I do! I searched my class and found the offending code!
A code like this will compile on 2003 without problems but will fail to
compile on 2005 with C3395:
Instructions:
- add a reference to System.Windows.Forms.dll (.NET 1.1.4322 on VS 2003 and
2.0.40607 on VS 2005 B1)
- compile with /clr:oldSyntax
class __declspec(dllexport) TestClass
{
public:
TestClass();
int GetDotNetMouseButton(
System::Windows::Forms::MouseButtons button
);
};
Could this be happening because I'm using a .NET type,
System::Windows::Forms::MouseButtons, on my theoretically __nogc class? As
my unmanaged class is trying to access a managed type, the compiler makes it
managed?
If this is the case (I think it is), how did this work back in VS 2003? ;-)
Thanx
--
This posting is provided "AS IS" with no warranties, and confers no
rights."Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm"
"Gustavo L. Fabro" <gu************************@hotmail.com> wrote in message
news:36*************@individual.net... Hi there! Thanks for the replies!
Answering backwards...
2) Managed code in assemblies can be exposed by simply declaring them public. The user of the assembly can add a reference to the dll by using either #using syntax, by using the /FU compiler switch to force a reference etc.,
Great! I searched for the keywords and now things are much clearer.
1) Sorry. I meant gc classes (value and ref types (in new syntax)) have implicit clrcall calling convention and hence cannot use dllexport. I don't see this behavior on __nogc classes (unmanaged types) on Beta 1. Do you have a small snippet of code which throws this error?
In fact I do! I searched my class and found the offending code! A code like this will compile on 2003 without problems but will fail to compile on 2005 with C3395:
Instructions:
- add a reference to System.Windows.Forms.dll (.NET 1.1.4322 on VS 2003 and 2.0.40607 on VS 2005 B1) - compile with /clr:oldSyntax
class __declspec(dllexport) TestClass { public:
TestClass();
int GetDotNetMouseButton( System::Windows::Forms::MouseButtons button );
};
Could this be happening because I'm using a .NET type, System::Windows::Forms::MouseButtons, on my theoretically __nogc class? As my unmanaged class is trying to access a managed type, the compiler makes it managed?
If this is the case (I think it is), how did this work back in VS 2003? ;-)
Thanx
Hi Gustavo,
Thanks for the repro. First to answer your question, we currently dont allow
a native class member function which takes an argument of a manged type if
you try to export the class or member functions. It would work if you dont
export the class. Let me try to explain why.
When you have dllexport on your class or members, you create an entry in the
import virtual table. When a call is made to that function, it goes through
the IVT. In the case of a native function, we create a thunk to convert the
native call to a MSIL. For example, if you native function took char* as an
argument, we could convert it to String which is the equivalent managed
transformation.
In your example however, the function was "managed" and thus it had a
__clrcall calling convention. We could not do the thunking in this case and
thus the call failed.
Hope it helps. I know that thunking is not very well documented yet but I
will try to find some docs and post them.
Thanks,
Kapil
Also check out the following site: http://msdn2.microsoft.com/library/eyzhw3s8.aspx
It contains some good articles on native/managed transitions.
Thanks.
--
This posting is provided "AS IS" with no warranties, and confers no
rights."Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm"
"Kapil Khosla [MSFTt]" <kk*****@online.microsoft.com> wrote in message
news:eO**************@TK2MSFTNGP15.phx.gbl...
-- This posting is provided "AS IS" with no warranties, and confers no rights."Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm"
"Gustavo L. Fabro" <gu************************@hotmail.com> wrote in message news:36*************@individual.net... Hi there! Thanks for the replies!
Answering backwards...
2) Managed code in assemblies can be exposed by simply declaring them public. The user of the assembly can add a reference to the dll by using either #using syntax, by using the /FU compiler switch to force a reference etc.,
Great! I searched for the keywords and now things are much clearer.
1) Sorry. I meant gc classes (value and ref types (in new syntax)) have implicit clrcall calling convention and hence cannot use dllexport. I don't see this behavior on __nogc classes (unmanaged types) on Beta 1. Do you have a small snippet of code which throws this error?
In fact I do! I searched my class and found the offending code! A code like this will compile on 2003 without problems but will fail to compile on 2005 with C3395:
Instructions:
- add a reference to System.Windows.Forms.dll (.NET 1.1.4322 on VS 2003 and 2.0.40607 on VS 2005 B1) - compile with /clr:oldSyntax
class __declspec(dllexport) TestClass { public:
TestClass();
int GetDotNetMouseButton( System::Windows::Forms::MouseButtons button );
};
Could this be happening because I'm using a .NET type, System::Windows::Forms::MouseButtons, on my theoretically __nogc class? As my unmanaged class is trying to access a managed type, the compiler makes it managed?
If this is the case (I think it is), how did this work back in VS 2003? ;-)
Thanx
Hi Gustavo, Thanks for the repro. First to answer your question, we currently dont allow a native class member function which takes an argument of a manged type if you try to export the class or member functions. It would work if you dont export the class. Let me try to explain why.
When you have dllexport on your class or members, you create an entry in the import virtual table. When a call is made to that function, it goes through the IVT. In the case of a native function, we create a thunk to convert the native call to a MSIL. For example, if you native function took char* as an argument, we could convert it to String which is the equivalent managed transformation.
In your example however, the function was "managed" and thus it had a __clrcall calling convention. We could not do the thunking in this case and thus the call failed. Hope it helps. I know that thunking is not very well documented yet but I will try to find some docs and post them.
Thanks, Kapil
Hi there, Hi Gustavo, Thanks for the repro. First to answer your question, we currently dont allow a native class member function which takes an argument of a manged type if you try to export the class or member functions. It would work if you dont export the class. Let me try to explain why.
When you have dllexport on your class or members, you create an entry in the import virtual table. When a call is made to that function, it goes through the IVT. In the case of a native function, we create a thunk to convert the native call to a MSIL. For example, if you native function took char* as an argument, we could convert it to String which is the equivalent managed transformation.
In your example however, the function was "managed" and thus it had a __clrcall calling convention. We could not do the thunking in this case and thus the call failed. Hope it helps. I know that thunking is not very well documented yet but I will try to find some docs and post them.
It took me a while to reply because we were at carnival here in Brazil...
;-)
Thanx for the explanation and the URL to the docs. I'll definitely read
them.
Best regards,
Fabro This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Herby |
last post by:
Hi,
I am currently reviewing what is required to convert a current MFC, COM
server application into a .NET application. The objective is to
compile ultimately to clr/safe.
So we are seeking a...
|
by: Gary Nastrasio |
last post by:
If I compile with /clr:safe, which is exactly meant by saying I can't
use "Native Types" in my code? Is a native type something such as
float, short, or int?
Thanks,
Gary
|
by: C.O.Jones |
last post by:
I've previously used version 7 and 2000.
I've recently started to learn ASP.net. I've installed
Visual Web Developer 2005 Express and this includes
SQLServer 2005 in the installation. The task...
|
by: Nick |
last post by:
I tried to use the following code in MS VS .Net 2003 VS C++
#using <mscorlib.dll>
using namespace System;
but i get fatal error C1190: managed targeted code requires '#using
<mscorlib.dll>'...
|
by: steve02a |
last post by:
I'm attempting to export data from a datagrid. I'm successful at exporting it in xls, doc, html types - but csv and pdf are giving me a headache.
The code I'm using isn't anything fancy:
...
|
by: Bart |
last post by:
Hi,
What is the benefit of using the Pure option over the Mixed one. Is there a
better performance?
We have a lot of stuff in c++ with mfc support en we want to use in our .net
apps. With...
|
by: =?Utf-8?B?d3BjbWFtZQ==?= |
last post by:
I have a small C++/CLI application which calls an unmanaged lib.
It seems like I can't use /clr:pure and link with the unmanaged lib (LNK1313
error).
The problem I have is that compiling with...
|
by: ajk |
last post by:
Hi
I am doing a C++/CLI dll that is supposed to be fully managed code. I
was wondering what exactly is the criteria for the DLL to be 100%
fully managed and usuable from C#? Do I need to compile...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |