dotnet clr: Using the Metadata Unmanaged API call GetParamForMethodIndex to obtain
the parameter definition token for the return value, you are told to pass 0
for
the ParamSeq value. This results in a Com error 80131130 'Record not found'.

This was called passing a MemberRef token (0x0a0000011 for example) as the
target method.

Further looking at the Param table in the assembly file, I fail to see ANY
return value
param definitions in the assembly table despite documentation that indicates
that is where the return parameter information lives in addition to the
argument parameter information.

Where does one obtain the ParameterInfo information for the return value of
a method?

This experimentation has been with Feb 2005 BETA 2 CTP version of .NET

Hi kadorken,

Thanks for your post!!

For this issue, I have writen a sample application using unmanaged C++ in
Net Framework 1.1. I can also reproduce out this problem in .Net Framework
1.1, code snippet lists below:

#include "cor.h"
#include <stdio.h>
#include <objbase.h>

int main(int argc, TCHAR* argv[])
{
IMetaDataDispenser* _IMetaDataDispenser;
IMetaDataImport* _IMetaDataImport;
IMetaDataAssemblyImport* _IMetaDataAssemblyImport;

CoInitialize( 0 );
HRESULT hr;

// go create all the interfaces
hr = CoCreateInstance(CLSID_CorMetaDataDispenser, 0,
CLSCTX_INPROC_SERVER,
IID_IMetaDataDispenser,
(LPVOID*)&_IMetaDataDispenser );

if ( FAILED(hr) )
throw "failed on IMetaDataDispenser";

wchar_t _FileName[MAX_PATH];
mbstowcs( _FileName, argv[1], lstrlen(argv[1])+1 );

hr = _IMetaDataDispenser->OpenScope(_FileName, ofRead,
IID_IMetaDataImport,
(LPUNKNOWN *)&_IMetaDataImport );

if ( FAILED(hr) )
throw "failed on IMetaDataImport";

hr = _IMetaDataDispenser->OpenScope(_FileName, ofRead,
IID_IMetaDataAssemblyImport,
(LPUNKNOWN *)&_IMetaDataAssemblyImport);
if ( FAILED(hr) )
throw "failed on IMetaDataAssemblyImport";

HCORENUM _hCorEnum = 0;
mdTypeDef _typeDefs[2048];
ULONG _countTypeDefs = sizeof(_typeDefs);

// go get all the type defs defined in the assembly
hr = _IMetaDataImport->EnumTypeDefs(&_hCorEnum,
_typeDefs,
_countTypeDefs,
&_countTypeDefs);

for (int i=0;i<_countTypeDefs;i++)
{

mdMethodDef _methodDefs[2048];

ULONG _countMethodDefs = sizeof(_methodDefs);



// go get all the methods defined on the typedef

_hCorEnum = 0;

hr = _IMetaDataImport->EnumMethods(&_hCorEnum,
_typeDefs[i],
_methodDefs,
_countMethodDefs,
&_countMethodDefs);

// now print out the methods name
wchar_t _methodName[1024];
ULONG _countMethodName = sizeof(_methodName);

for (int j=0;j<_countMethodDefs;j++)
{
wchar_t _methodName[1024];
mdParamDef returnValue=NULL;

hr = _IMetaDataImport->GetMethodProps(_methodDefs[j], 0, _methodName,
_countMethodName, &_countMethodName, 0, 0, 0, 0, 0);
wprintf(L"%s: \n", _methodName);

hr=_IMetaDataImport->GetParamForMethodIndex(_methodDefs[j], 0,
&returnValue);

if(SUCCEEDED(hr))
{
wchar_t szParamName[1024];
ULONG countParamName=sizeof(szParamName);
hr=_IMetaDataImport->GetParamProps(returnValue, &_methodDefs[j], 0,
szParamName,
countParamName, &countParamName, NULL, NULL, NULL, NULL);
if(SUCCEEDED(hr))
{
wprintf(L"\tReturnValue %s", szParamName);
}
}
printf("\n");
}

}
return 0;
}
GetParamForMethodIndex invoking always returns 0x80131130 error result.

For this issue, I have searched internal database, and find that this is
already submited as a bug request at 2005-04-28. The public link for this
bug request is:
http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackid=3
73c87ad-44f5-4f22-b59b-de4ac3ac098a

Currently, this bug request is still in active state. Our CLR team is still
doing research on this issue. I will keep track on this issue and update
you ASAP. Thanks
=============================================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Keith,

[quoted text, click to view]

GetParamForMethodIndex takes a MethodDef token as input, not a
MemberRef.


[quoted text, click to view]

A row in the Param table for return values is only needed if it has
custom attributes, marshaling or a default value. Most return values
don't, so no Param row is needed (it would just bloat the metadata).



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com

Jeffrey,

[quoted text, click to view]

Your code is working fine here (ignoring the bugs), I suspect you're
just testing it with a module where no return value has a row in the
Param table. Keep in mind that having a Param row is optional, and
quite rare for return values since they are not named. It's only
needed if the return value has custom attributes, marshaling or a
default value.

If you run your code against the assembly produced by this C# code you
should see some output for the Bar method.

using System.Runtime.InteropServices;

abstract class Test
{
public abstract void Foo();
[return:MarshalAs(UnmanagedType.BStr)]
public abstract string Bar();
}


[quoted text, click to view]

Apparently filed by the original poster of this thread. I believe the
problem in his case is that he passes in a MemberRef token, but
GetParamForMethodIndex expects a MethodDef. So the bug is in his code,
not the API.



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com

Hi Mattias,

Oh, yes, thanks for your correction!!

With adding the Marshal attribute to the return parameter, we can
succesfully invoke GetParamForMethodIndex for return parameter.

From the customer's error message, it seems you are right, maybe he passed
MemberRef instead of MemberRef for GetParamForMethodIndex api.

Currently, I still did not test this issue in .Net 2.0 beta2 framework, but
because our CLR team is doing research on this issue, I will just monitor
their researching process. Once there are any further feedback, I will
further the information here.

Again, thank you for your information.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Thanks for all responses. You are correct that I am (incorrectly) passing a
MemberRef token so that is the source of a problem. I was receving some
information back from GetMethodProps when it was passed a MemberRef leading
me to believe they could be used in addition to MethodDef tokens. However, the
information being returned was not correct (garbage in, garbage out) anyway.

Feedback on the BETA web site indicates one way to determine the return value
type of a Method/MemberRef is
"If you're after the return value type of a methodref, you'll need to obtain
the signature of the memberref via IMetadataImport::GetMemberRefProps() and
parse it."



[quoted text, click to view]