Custom attributes are not consistent???

**Yan-Hong Huang[MSFT]** · Nov 17 '05, 01:28 PM

RE: Custom attributes are not consistent???

Hello Bret,

Thanks for posting in the group.

Based on my understanding, the problem is: You are migrating an old C++
library project to managed C++ project. However, when you build the
project, you got several error LNK2022: metadata operation failed
(80131195) link error. Please let me know if I have misunderstood the
problem.

I searched in our database immediately when I saw your post. Unluckily, the
hits are small. And it seems that there were no similar report before. So
we can't tell exactly where the problem may reside now.

In order to troubleshoot the problem, could you please provide us a small
repro sample? We will look into it and reply with detailed information
here. You can reach me by removing online from my email address here.

I understand that C++ library is not trivial. Perhaps it is hard for you to
isolate the problem or create a repro sample. If so, I suggest you contact
our PSS (product support service) to have one support engineer specially
help you on it. If you need help on contacting PSS, please feel free to
post here and I will post back with detailed information.

If you have any more concerns on it, please feel free to post here. Thanks
very much and look forward to your response.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

**Bret Pehrson** · Nov 17 '05, 01:29 PM

Re: Custom attributes are not consistent???

Hmmm...

(I'm presuming that you work for/at Microsoft, or have internal contact w/ MS.)

Could you contact the compiler group and have them document the metadata
"Custom
attributes are not consistent" error?

Thanks

"Yan-Hong Huang[MSFT]" wrote:[color=blue]
>
> Hello Bret,
>
> Thanks for posting in the group.
>
> Based on my understanding, the problem is: You are migrating an old C++
> library project to managed C++ project. However, when you build the
> project, you got several error LNK2022: metadata operation failed
> (80131195) link error. Please let me know if I have misunderstood the
> problem.
>
> I searched in our database immediately when I saw your post. Unluckily, the
> hits are small. And it seems that there were no similar report before. So
> we can't tell exactly where the problem may reside now.
>
> In order to troubleshoot the problem, could you please provide us a small
> repro sample? We will look into it and reply with detailed information
> here. You can reach me by removing online from my email address here.
>
> I understand that C++ library is not trivial. Perhaps it is hard for you to
> isolate the problem or create a repro sample. If so, I suggest you contact
> our PSS (product support service) to have one support engineer specially
> help you on it. If you need help on contacting PSS, please feel free to
> post here and I will post back with detailed information.
>
> If you have any more concerns on it, please feel free to post here. Thanks
> very much and look forward to your response.
>
> Best regards,
> Yanhong Huang
> Microsoft Community Support
>
> Get Secure! ¨C www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no rights.[/color]

--
Bret Pehrson
mailto:bret@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>

**Ronald Laeremans [MSFT]** · Nov 17 '05, 01:29 PM

Re: Custom attributes are not consistent???

In the Whidbey release the linker will give better diagnostics.

For now the way to diagnose this is using ildasm to dump the metadata of the
..obj files to text and then search for the tokens (the hex numbers mentioned
in the error messages). Usually this is a source error where 2 translation
units define a type in a different way.

Ronald Laeremans
Visual C++ team

"Bret Pehrson" <bret@infowest. com> wrote in message
news:40056621.1 15089FF@infowes t.com...[color=blue]
> Hmmm...
>
> (I'm presuming that you work for/at Microsoft, or have internal contact w/[/color]
MS.)[color=blue]
>
> Could you contact the compiler group and have them document the metadata
> "Custom
> attributes are not consistent" error?
>
> Thanks
>
> "Yan-Hong Huang[MSFT]" wrote:[color=green]
> >
> > Hello Bret,
> >
> > Thanks for posting in the group.
> >
> > Based on my understanding, the problem is: You are migrating an old C++
> > library project to managed C++ project. However, when you build the
> > project, you got several error LNK2022: metadata operation failed
> > (80131195) link error. Please let me know if I have misunderstood the
> > problem.
> >
> > I searched in our database immediately when I saw your post. Unluckily,[/color][/color]
the[color=blue][color=green]
> > hits are small. And it seems that there were no similar report before.[/color][/color]
So[color=blue][color=green]
> > we can't tell exactly where the problem may reside now.
> >
> > In order to troubleshoot the problem, could you please provide us a[/color][/color]
small[color=blue][color=green]
> > repro sample? We will look into it and reply with detailed information
> > here. You can reach me by removing online from my email address here.
> >
> > I understand that C++ library is not trivial. Perhaps it is hard for you[/color][/color]
to[color=blue][color=green]
> > isolate the problem or create a repro sample. If so, I suggest you[/color][/color]
contact[color=blue][color=green]
> > our PSS (product support service) to have one support engineer specially
> > help you on it. If you need help on contacting PSS, please feel free to
> > post here and I will post back with detailed information.
> >
> > If you have any more concerns on it, please feel free to post here.[/color][/color]
Thanks[color=blue][color=green]
> > very much and look forward to your response.
> >
> > Best regards,
> > Yanhong Huang
> > Microsoft Community Support
> >
> > Get Secure! ¨C www.microsoft.com/security
> > This posting is provided "AS IS" with no warranties, and confers no[/color][/color]
rights.[color=blue]
>
> --
> Bret Pehrson
> mailto:bret@inf owest.com
> NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>[/color]

**Bret Pehrson** · Nov 17 '05, 01:29 PM

Re: Custom attributes are not consistent???

Ronald -- thanks for the reply. (Please note, none of my comments are meant as
a personal attack on you.)
[color=blue]
> In the Whidbey release the linker will give better diagnostics.[/color]

I still stand by my previous post where I say it will be at least the 4th
release of the product before it is truly usable in a commercial environment.
[color=blue]
> For now the way to diagnose this is using ildasm to dump the metadata of the
> .obj files to text and then search for the tokens (the hex numbers mentioned
> in the error messages). Usually this is a source error where 2 translation
> units define a type in a different way.[/color]

Thanks for defining the mystery error. I was *finally* able to find the source
of the problem and resolve it using the technique you describe -- thanks. My
comments follow for the purpose of actually documenting the procedure:

First, ILDASM is a mixed-mode application meaning that it has a GUI-mode and
console-mode interface.

When running in GUI mode, you *CANNOT* process .obj files (the only files that
are documented are .exe and .dll). This means that you must use the tool from
the command line (with the appropriate vars set through vsvars32.bat or by
running "Visual Studio .NET 2003 Command Prompt" from the VS.NET start menu
tools group).

When processing .obj files from the command line, YOU MUST REDIRECT THE OUTPUT
TO A FILE or else you will get no results - BUG! BUG! Additionally, you must
use the /text option to force output to the console. So, it boils down to:

ildasm your_source_fil e.obj /text /out=output.txt

The file output.txt is then created -- open it up and then search for the token
in question (the last hex number of the "Custom attributes are not consistent"
error. (NOTE: the output token identifiers *DO NOT* prefix hex numbers w/ the
traditional 0x -- so take this into account when searching for the token.)
This will locate the custom attribute of the token that is causing the error.
Once you know the token, it should be relatively easy to locate the actual
source of the problem.

So, presuming the following errors:

Assignment.obj : error LNK2022: metadata operation failed (80131195) : Custom
attributes are not consistent: (0x0c0001a5).

The steps would be:

ildasm Assignment.obj /text /out=assignment. txt

Search assignment.txt for "0c0001a5". It should find some custom attribute,
look up a few lines and locate the offending type. Armed with that, you can go
back to your source files and determine why the type (class/struct) is being
defined differently in the different source files.

NOTE TO MICROSOFT: Fix this stupid diagnostic! At the *BARE MINIMUM*, the
offending TYPE and ATTRIBUTE should be displayed *BY NAME* -- hex tokens in
diagnostics went out w/ Lattice C compilers and powdered wigs, they have
*ABSOLUTELY NO BUSINESS IN A 7TH-PLUS GENERATION PRODUCT*

[color=blue]
>
> Ronald Laeremans
> Visual C++ team
>
> "Bret Pehrson" <bret@infowest. com> wrote in message
> news:40056621.1 15089FF@infowes t.com...[color=green]
> > Hmmm...
> >
> > (I'm presuming that you work for/at Microsoft, or have internal contact w/[/color]
> MS.)[color=green]
> >
> > Could you contact the compiler group and have them document the metadata
> > "Custom
> > attributes are not consistent" error?
> >
> > Thanks
> >
> > "Yan-Hong Huang[MSFT]" wrote:[color=darkred]
> > >
> > > Hello Bret,
> > >
> > > Thanks for posting in the group.
> > >
> > > Based on my understanding, the problem is: You are migrating an old C++
> > > library project to managed C++ project. However, when you build the
> > > project, you got several error LNK2022: metadata operation failed
> > > (80131195) link error. Please let me know if I have misunderstood the
> > > problem.
> > >
> > > I searched in our database immediately when I saw your post. Unluckily,[/color][/color]
> the[color=green][color=darkred]
> > > hits are small. And it seems that there were no similar report before.[/color][/color]
> So[color=green][color=darkred]
> > > we can't tell exactly where the problem may reside now.
> > >
> > > In order to troubleshoot the problem, could you please provide us a[/color][/color]
> small[color=green][color=darkred]
> > > repro sample? We will look into it and reply with detailed information
> > > here. You can reach me by removing online from my email address here.
> > >
> > > I understand that C++ library is not trivial. Perhaps it is hard for you[/color][/color]
> to[color=green][color=darkred]
> > > isolate the problem or create a repro sample. If so, I suggest you[/color][/color]
> contact[color=green][color=darkred]
> > > our PSS (product support service) to have one support engineer specially
> > > help you on it. If you need help on contacting PSS, please feel free to
> > > post here and I will post back with detailed information.
> > >
> > > If you have any more concerns on it, please feel free to post here.[/color][/color]
> Thanks[color=green][color=darkred]
> > > very much and look forward to your response.
> > >
> > > Best regards,
> > > Yanhong Huang
> > > Microsoft Community Support
> > >
> > > Get Secure! ¨C www.microsoft.com/security
> > > This posting is provided "AS IS" with no warranties, and confers no[/color][/color]
> rights.[color=green]
> >
> > --
> > Bret Pehrson
> > mailto:bret@inf owest.com
> > NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>[/color][/color]

--
Bret Pehrson
mailto:bret@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>

**Yan-Hong Huang[MSFT]** · Nov 17 '05, 01:29 PM

Re: Custom attributes are not consistent???

Hello Bret,

Thanks very much for your feedback and sharing your experience in how to
isolate the problem in the community. I am glad that Ronald's suggestion
help resolve the problem.

We will redirect your feedback to the product team. We are looking at
continual improvement, and it's this kind of feedback that let's us know
what things you're trying to do, that we haven't yet exposed for you.

If there is any any other feedback on our product, you can go to

http://register.microsoft.com/mswish/suggestion.asp?&SD=GN&LN=EN-US&gssnb=1

to submit it.

For the usage of ildsam.exe, we can see it from MSDN:
Option Description
/output:filename Creates an output file with the specified filename, rather
than displaying the results in a dialog box.
/text Displays the results to the console window, rather than in a dialog
box or as an output file.
/? Displays the command syntax and options for the tool.

So the command string that you used is correct.

Thanks again for participating the community.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

**Bret Pehrson** · Nov 17 '05, 01:29 PM

Re: Custom attributes are not consistent???

> So the command string that you used is correct.

Right, but my point was that if you omit the /output=filename flag, you get
*NO* output (other than the header) to the console. That is a bug.

Thanks for the follow-up. I'll be glad to see these fixes in your product,
although I'd *much* rather have a service pack rather than wait for the next
point release.

"Yan-Hong Huang[MSFT]" wrote:[color=blue]
>
> Hello Bret,
>
> Thanks very much for your feedback and sharing your experience in how to
> isolate the problem in the community. I am glad that Ronald's suggestion
> help resolve the problem.
>
> We will redirect your feedback to the product team. We are looking at
> continual improvement, and it's this kind of feedback that let's us know
> what things you're trying to do, that we haven't yet exposed for you.
>
> If there is any any other feedback on our product, you can go to
> http://register.microsoft.com/mswish...=EN-US&gssnb=1
> to submit it.
>
> For the usage of ildsam.exe, we can see it from MSDN:
> Option Description
> /output:filename Creates an output file with the specified filename, rather
> than displaying the results in a dialog box.
> /text Displays the results to the console window, rather than in a dialog
> box or as an output file.
> /? Displays the command syntax and options for the tool.
>
> So the command string that you used is correct.
>
> Thanks again for participating the community.
>
> Best regards,
> Yanhong Huang
> Microsoft Community Support
>
> Get Secure! ¨C www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no rights.[/color]

--
Bret Pehrson
mailto:bret@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>

**Yan-Hong Huang[MSFT]** · Nov 17 '05, 01:30 PM

Re: Custom attributes are not consistent???

Hi Bret,
[color=blue]
>Right, but my point was that if you omit the /output=filename flag, you get
>*NO* output (other than the header) to the console. That is a bug.[/color]

Got it. I will repro it on my side and report to product group.

Thanks very much for participating the community. If there is any we can do
for you, please feel free to post new messages in the group.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

**Ronald Laeremans [MSFT]** · Nov 17 '05, 01:30 PM

Re: Custom attributes are not consistent???

Hi Bret,

I agree that the linker error you get in the VC 7.1 release is very far from
ideal. You are seeing some growing pains of fitting a separate compilation
model language like C++ into the CLR environment. We knew this issue going
into the release of VC 7.1, but the code base we had worked with compiling
to IJW internally and from the early adopters we got most feedback from
didn't have a large number of occurrences of this issue, so we traded
improving this off for other priority fixes. Subsequent experience both
internally and externally has shown it to be quite prevalent though. We have
been working on getting a KB out on this. I'll check on the status of that.

I am also sorry for my _very_ terse explanation on how to use ildasm and I
am glad you still were able to figure it out. We'll make sure your comments
on ildasm get to the author of that tool.

Ronald

"Bret Pehrson" <bret@infowest. com> wrote in message
news:4005DAE9.B 931DDF8@infowes t.com...[color=blue]
> Ronald -- thanks for the reply. (Please note, none of my comments are[/color]
meant as[color=blue]
> a personal attack on you.)
>[color=green]
> > In the Whidbey release the linker will give better diagnostics.[/color]
>
> I still stand by my previous post where I say it will be at least the 4th
> release of the product before it is truly usable in a commercial[/color]
environment.[color=blue]
>[color=green]
> > For now the way to diagnose this is using ildasm to dump the metadata of[/color][/color]
the[color=blue][color=green]
> > .obj files to text and then search for the tokens (the hex numbers[/color][/color]
mentioned[color=blue][color=green]
> > in the error messages). Usually this is a source error where 2[/color][/color]
translation[color=blue][color=green]
> > units define a type in a different way.[/color]
>
> Thanks for defining the mystery error. I was *finally* able to find the[/color]
source[color=blue]
> of the problem and resolve it using the technique you describe -- thanks.[/color]
My[color=blue]
> comments follow for the purpose of actually documenting the procedure:
>
> First, ILDASM is a mixed-mode application meaning that it has a GUI-mode[/color]
and[color=blue]
> console-mode interface.
>
> When running in GUI mode, you *CANNOT* process .obj files (the only files[/color]
that[color=blue]
> are documented are .exe and .dll). This means that you must use the tool[/color]
from[color=blue]
> the command line (with the appropriate vars set through vsvars32.bat or by
> running "Visual Studio .NET 2003 Command Prompt" from the VS.NET start[/color]
menu[color=blue]
> tools group).
>
> When processing .obj files from the command line, YOU MUST REDIRECT THE[/color]
OUTPUT[color=blue]
> TO A FILE or else you will get no results - BUG! BUG! Additionally, you[/color]
must[color=blue]
> use the /text option to force output to the console. So, it boils down[/color]
to:[color=blue]
>
> ildasm your_source_fil e.obj /text /out=output.txt
>
> The file output.txt is then created -- open it up and then search for the[/color]
token[color=blue]
> in question (the last hex number of the "Custom attributes are not[/color]
consistent"[color=blue]
> error. (NOTE: the output token identifiers *DO NOT* prefix hex numbers w/[/color]
the[color=blue]
> traditional 0x -- so take this into account when searching for the token.)
> This will locate the custom attribute of the token that is causing the[/color]
error.[color=blue]
> Once you know the token, it should be relatively easy to locate the actual
> source of the problem.
>
> So, presuming the following errors:
>
> Assignment.obj : error LNK2022: metadata operation failed (80131195) :[/color]
Custom[color=blue]
> attributes are not consistent: (0x0c0001a5).
>
> The steps would be:
>
> ildasm Assignment.obj /text /out=assignment. txt
>
> Search assignment.txt for "0c0001a5". It should find some custom[/color]
attribute,[color=blue]
> look up a few lines and locate the offending type. Armed with that, you[/color]
can go[color=blue]
> back to your source files and determine why the type (class/struct) is[/color]
being[color=blue]
> defined differently in the different source files.
>
> NOTE TO MICROSOFT: Fix this stupid diagnostic! At the *BARE MINIMUM*,[/color]
the[color=blue]
> offending TYPE and ATTRIBUTE should be displayed *BY NAME* -- hex tokens[/color]
in[color=blue]
> diagnostics went out w/ Lattice C compilers and powdered wigs, they have
> *ABSOLUTELY NO BUSINESS IN A 7TH-PLUS GENERATION PRODUCT*
>
>[color=green]
> >
> > Ronald Laeremans
> > Visual C++ team
> >
> > "Bret Pehrson" <bret@infowest. com> wrote in message
> > news:40056621.1 15089FF@infowes t.com...[color=darkred]
> > > Hmmm...
> > >
> > > (I'm presuming that you work for/at Microsoft, or have internal[/color][/color][/color]
contact w/[color=blue][color=green]
> > MS.)[color=darkred]
> > >
> > > Could you contact the compiler group and have them document the[/color][/color][/color]
metadata[color=blue][color=green][color=darkred]
> > > "Custom
> > > attributes are not consistent" error?
> > >
> > > Thanks
> > >
> > > "Yan-Hong Huang[MSFT]" wrote:
> > > >
> > > > Hello Bret,
> > > >
> > > > Thanks for posting in the group.
> > > >
> > > > Based on my understanding, the problem is: You are migrating an old[/color][/color][/color]
C++[color=blue][color=green][color=darkred]
> > > > library project to managed C++ project. However, when you build the
> > > > project, you got several error LNK2022: metadata operation failed
> > > > (80131195) link error. Please let me know if I have misunderstood[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > problem.
> > > >
> > > > I searched in our database immediately when I saw your post.[/color][/color][/color]
Unluckily,[color=blue][color=green]
> > the[color=darkred]
> > > > hits are small. And it seems that there were no similar report[/color][/color][/color]
before.[color=blue][color=green]
> > So[color=darkred]
> > > > we can't tell exactly where the problem may reside now.
> > > >
> > > > In order to troubleshoot the problem, could you please provide us a[/color]
> > small[color=darkred]
> > > > repro sample? We will look into it and reply with detailed[/color][/color][/color]
information[color=blue][color=green][color=darkred]
> > > > here. You can reach me by removing online from my email address[/color][/color][/color]
here.[color=blue][color=green][color=darkred]
> > > >
> > > > I understand that C++ library is not trivial. Perhaps it is hard for[/color][/color][/color]
you[color=blue][color=green]
> > to[color=darkred]
> > > > isolate the problem or create a repro sample. If so, I suggest you[/color]
> > contact[color=darkred]
> > > > our PSS (product support service) to have one support engineer[/color][/color][/color]
specially[color=blue][color=green][color=darkred]
> > > > help you on it. If you need help on contacting PSS, please feel free[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > > post here and I will post back with detailed information.
> > > >
> > > > If you have any more concerns on it, please feel free to post here.[/color]
> > Thanks[color=darkred]
> > > > very much and look forward to your response.
> > > >
> > > > Best regards,
> > > > Yanhong Huang
> > > > Microsoft Community Support
> > > >
> > > > Get Secure! ¨C www.microsoft.com/security
> > > > This posting is provided "AS IS" with no warranties, and confers no[/color]
> > rights.[color=darkred]
> > >
> > > --
> > > Bret Pehrson
> > > mailto:bret@inf owest.com
> > > NOSPAM - Include this key in all e-mail correspondence[/color][/color][/color]
<<38952rglkwdsl >>[color=blue]
>
> --
> Bret Pehrson
> mailto:bret@inf owest.com
> NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>[/color]

**Bret Pehrson** · Nov 17 '05, 01:30 PM

Re: Custom attributes are not consistent???

Ronald -- thanks for the response & comments. I (as well as others) appreciate
the insight that you provide on the reasons for the issues, as well as a
commitment to clarify/resolve/fix the issue.

I've got to tell you, I'm *very* impressed w/ the response that I've been
getting to my issues from Microsoft. I've been out of the newsgroup community
for the past couple of years, but before I left, typical MS response to just
about any issue was: "That is a known issue and will be fixed in a future
release. <end>". It is readily apparent that you all have made a concerted
commitment to better handle issues, questions, and comments through the
newsgroups, and it is greatly appreciated.

Bret

"Ronald Laeremans [MSFT]" wrote:[color=blue]
>
> Hi Bret,
>
> I agree that the linker error you get in the VC 7.1 release is very far from
> ideal. You are seeing some growing pains of fitting a separate compilation
> model language like C++ into the CLR environment. We knew this issue going
> into the release of VC 7.1, but the code base we had worked with compiling
> to IJW internally and from the early adopters we got most feedback from
> didn't have a large number of occurrences of this issue, so we traded
> improving this off for other priority fixes. Subsequent experience both
> internally and externally has shown it to be quite prevalent though. We have
> been working on getting a KB out on this. I'll check on the status of that.
>
> I am also sorry for my _very_ terse explanation on how to use ildasm and I
> am glad you still were able to figure it out. We'll make sure your comments
> on ildasm get to the author of that tool.
>
> Ronald
>
> "Bret Pehrson" <bret@infowest. com> wrote in message
> news:4005DAE9.B 931DDF8@infowes t.com...[color=green]
> > Ronald -- thanks for the reply. (Please note, none of my comments are[/color]
> meant as[color=green]
> > a personal attack on you.)
> >[color=darkred]
> > > In the Whidbey release the linker will give better diagnostics.[/color]
> >
> > I still stand by my previous post where I say it will be at least the 4th
> > release of the product before it is truly usable in a commercial[/color]
> environment.[color=green]
> >[color=darkred]
> > > For now the way to diagnose this is using ildasm to dump the metadata of[/color][/color]
> the[color=green][color=darkred]
> > > .obj files to text and then search for the tokens (the hex numbers[/color][/color]
> mentioned[color=green][color=darkred]
> > > in the error messages). Usually this is a source error where 2[/color][/color]
> translation[color=green][color=darkred]
> > > units define a type in a different way.[/color]
> >
> > Thanks for defining the mystery error. I was *finally* able to find the[/color]
> source[color=green]
> > of the problem and resolve it using the technique you describe -- thanks.[/color]
> My[color=green]
> > comments follow for the purpose of actually documenting the procedure:
> >
> > First, ILDASM is a mixed-mode application meaning that it has a GUI-mode[/color]
> and[color=green]
> > console-mode interface.
> >
> > When running in GUI mode, you *CANNOT* process .obj files (the only files[/color]
> that[color=green]
> > are documented are .exe and .dll). This means that you must use the tool[/color]
> from[color=green]
> > the command line (with the appropriate vars set through vsvars32.bat or by
> > running "Visual Studio .NET 2003 Command Prompt" from the VS.NET start[/color]
> menu[color=green]
> > tools group).
> >
> > When processing .obj files from the command line, YOU MUST REDIRECT THE[/color]
> OUTPUT[color=green]
> > TO A FILE or else you will get no results - BUG! BUG! Additionally, you[/color]
> must[color=green]
> > use the /text option to force output to the console. So, it boils down[/color]
> to:[color=green]
> >
> > ildasm your_source_fil e.obj /text /out=output.txt
> >
> > The file output.txt is then created -- open it up and then search for the[/color]
> token[color=green]
> > in question (the last hex number of the "Custom attributes are not[/color]
> consistent"[color=green]
> > error. (NOTE: the output token identifiers *DO NOT* prefix hex numbers w/[/color]
> the[color=green]
> > traditional 0x -- so take this into account when searching for the token.)
> > This will locate the custom attribute of the token that is causing the[/color]
> error.[color=green]
> > Once you know the token, it should be relatively easy to locate the actual
> > source of the problem.
> >
> > So, presuming the following errors:
> >
> > Assignment.obj : error LNK2022: metadata operation failed (80131195) :[/color]
> Custom[color=green]
> > attributes are not consistent: (0x0c0001a5).
> >
> > The steps would be:
> >
> > ildasm Assignment.obj /text /out=assignment. txt
> >
> > Search assignment.txt for "0c0001a5". It should find some custom[/color]
> attribute,[color=green]
> > look up a few lines and locate the offending type. Armed with that, you[/color]
> can go[color=green]
> > back to your source files and determine why the type (class/struct) is[/color]
> being[color=green]
> > defined differently in the different source files.
> >
> > NOTE TO MICROSOFT: Fix this stupid diagnostic! At the *BARE MINIMUM*,[/color]
> the[color=green]
> > offending TYPE and ATTRIBUTE should be displayed *BY NAME* -- hex tokens[/color]
> in[color=green]
> > diagnostics went out w/ Lattice C compilers and powdered wigs, they have
> > *ABSOLUTELY NO BUSINESS IN A 7TH-PLUS GENERATION PRODUCT*
> >
> >[color=darkred]
> > >
> > > Ronald Laeremans
> > > Visual C++ team
> > >
> > > "Bret Pehrson" <bret@infowest. com> wrote in message
> > > news:40056621.1 15089FF@infowes t.com...
> > > > Hmmm...
> > > >
> > > > (I'm presuming that you work for/at Microsoft, or have internal[/color][/color]
> contact w/[color=green][color=darkred]
> > > MS.)
> > > >
> > > > Could you contact the compiler group and have them document the[/color][/color]
> metadata[color=green][color=darkred]
> > > > "Custom
> > > > attributes are not consistent" error?
> > > >
> > > > Thanks
> > > >
> > > > "Yan-Hong Huang[MSFT]" wrote:
> > > > >
> > > > > Hello Bret,
> > > > >
> > > > > Thanks for posting in the group.
> > > > >
> > > > > Based on my understanding, the problem is: You are migrating an old[/color][/color]
> C++[color=green][color=darkred]
> > > > > library project to managed C++ project. However, when you build the
> > > > > project, you got several error LNK2022: metadata operation failed
> > > > > (80131195) link error. Please let me know if I have misunderstood[/color][/color]
> the[color=green][color=darkred]
> > > > > problem.
> > > > >
> > > > > I searched in our database immediately when I saw your post.[/color][/color]
> Unluckily,[color=green][color=darkred]
> > > the
> > > > > hits are small. And it seems that there were no similar report[/color][/color]
> before.[color=green][color=darkred]
> > > So
> > > > > we can't tell exactly where the problem may reside now.
> > > > >
> > > > > In order to troubleshoot the problem, could you please provide us a
> > > small
> > > > > repro sample? We will look into it and reply with detailed[/color][/color]
> information[color=green][color=darkred]
> > > > > here. You can reach me by removing online from my email address[/color][/color]
> here.[color=green][color=darkred]
> > > > >
> > > > > I understand that C++ library is not trivial. Perhaps it is hard for[/color][/color]
> you[color=green][color=darkred]
> > > to
> > > > > isolate the problem or create a repro sample. If so, I suggest you
> > > contact
> > > > > our PSS (product support service) to have one support engineer[/color][/color]
> specially[color=green][color=darkred]
> > > > > help you on it. If you need help on contacting PSS, please feel free[/color][/color]
> to[color=green][color=darkred]
> > > > > post here and I will post back with detailed information.
> > > > >
> > > > > If you have any more concerns on it, please feel free to post here.
> > > Thanks
> > > > > very much and look forward to your response.
> > > > >
> > > > > Best regards,
> > > > > Yanhong Huang
> > > > > Microsoft Community Support
> > > > >
> > > > > Get Secure! ¨C www.microsoft.com/security
> > > > > This posting is provided "AS IS" with no warranties, and confers no
> > > rights.
> > > >
> > > > --
> > > > Bret Pehrson
> > > > mailto:bret@inf owest.com
> > > > NOSPAM - Include this key in all e-mail correspondence[/color][/color]
> <<38952rglkwdsl >>[color=green]
> >
> > --
> > Bret Pehrson
> > mailto:bret@inf owest.com
> > NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>[/color][/color]

--
Bret Pehrson
mailto:bret@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>

**Yan-Hong Huang[MSFT]** · Nov 17 '05, 01:30 PM

Re: Custom attributes are not consistent???

Hi Bret,

Thanks very much for your positive feedback. Ronald and I are all glad to
know that you are satisfied with the service here. We are here to support
you at your convenience.

Thanks again for participating the community.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

**Edward Diener** · Nov 17 '05, 01:31 PM

Re: Custom attributes are not consistent???

Bret Pehrson wrote:[color=blue]
> Ronald -- thanks for the response & comments. I (as well as others)
> appreciate the insight that you provide on the reasons for the
> issues, as well as a commitment to clarify/resolve/fix the issue.
>
> I've got to tell you, I'm *very* impressed w/ the response that I've
> been getting to my issues from Microsoft. I've been out of the
> newsgroup community for the past couple of years, but before I left,
> typical MS response to just about any issue was: "That is a known
> issue and will be fixed in a future release. <end>". It is readily
> apparent that you all have made a concerted commitment to better
> handle issues, questions, and comments through the newsgroups, and it
> is greatly appreciated.[/color]

The response from MS in these NGs is in inverse proportion to the service
packs put out for VS Studio .NET, which so far has been 0 . While I too
appreciate the response to reported problems and bugs by MS, I don't
appreciate at all the fact that MS seems to think that end users must
persevere with these problems and onerous workarounds for years at a time
until they come up with a new release, and no doubt new bugs. I would much
rather see service packs which actually fixed some of the problems which are
reported and acknowledge, making it easier to program without having to
memorize all the bugs to be a successful MC++ or C# programmer.
[color=blue]
>
> Bret
>
> "Ronald Laeremans [MSFT]" wrote:[color=green]
>>
>> Hi Bret,
>>
>> I agree that the linker error you get in the VC 7.1 release is very
>> far from ideal. You are seeing some growing pains of fitting a
>> separate compilation model language like C++ into the CLR
>> environment. We knew this issue going into the release of VC 7.1,
>> but the code base we had worked with compiling to IJW internally and
>> from the early adopters we got most feedback from didn't have a
>> large number of occurrences of this issue, so we traded improving
>> this off for other priority fixes. Subsequent experience both
>> internally and externally has shown it to be quite prevalent though.
>> We have been working on getting a KB out on this. I'll check on the
>> status of that.
>>
>> I am also sorry for my _very_ terse explanation on how to use ildasm
>> and I am glad you still were able to figure it out. We'll make sure
>> your comments on ildasm get to the author of that tool.
>>
>> Ronald
>>
>> "Bret Pehrson" <bret@infowest. com> wrote in message
>> news:4005DAE9.B 931DDF8@infowes t.com...[color=darkred]
>>> Ronald -- thanks for the reply. (Please note, none of my comments
>>> are meant as a personal attack on you.)
>>>
>>>> In the Whidbey release the linker will give better diagnostics.
>>>
>>> I still stand by my previous post where I say it will be at least
>>> the 4th release of the product before it is truly usable in a
>>> commercial environment.
>>>
>>>> For now the way to diagnose this is using ildasm to dump the
>>>> metadata of the .obj files to text and then search for the tokens
>>>> (the hex numbers mentioned in the error messages). Usually this is
>>>> a source error where 2 translation units define a type in a
>>>> different way.
>>>
>>> Thanks for defining the mystery error. I was *finally* able to
>>> find the source of the problem and resolve it using the technique
>>> you describe -- thanks. My comments follow for the purpose of
>>> actually documenting the procedure:
>>>
>>> First, ILDASM is a mixed-mode application meaning that it has a
>>> GUI-mode and console-mode interface.
>>>
>>> When running in GUI mode, you *CANNOT* process .obj files (the only
>>> files that are documented are .exe and .dll). This means that you
>>> must use the tool from the command line (with the appropriate vars
>>> set through vsvars32.bat or by running "Visual Studio .NET 2003
>>> Command Prompt" from the VS.NET start menu tools group).
>>>
>>> When processing .obj files from the command line, YOU MUST REDIRECT
>>> THE OUTPUT TO A FILE or else you will get no results - BUG! BUG!
>>> Additionally, you must use the /text option to force output to the
>>> console. So, it boils down to:
>>>
>>> ildasm your_source_fil e.obj /text /out=output.txt
>>>
>>> The file output.txt is then created -- open it up and then search
>>> for the token in question (the last hex number of the "Custom
>>> attributes are not consistent" error. (NOTE: the output token
>>> identifiers *DO NOT* prefix hex numbers w/ the traditional 0x -- so
>>> take this into account when searching for the token.) This will
>>> locate the custom attribute of the token that is causing the error.
>>> Once you know the token, it should be relatively easy to locate the
>>> actual source of the problem.
>>>
>>> So, presuming the following errors:
>>>
>>> Assignment.obj : error LNK2022: metadata operation failed
>>> (80131195) : Custom attributes are not consistent: (0x0c0001a5).
>>>
>>> The steps would be:
>>>
>>> ildasm Assignment.obj /text /out=assignment. txt
>>>
>>> Search assignment.txt for "0c0001a5". It should find some custom
>>> attribute, look up a few lines and locate the offending type.
>>> Armed with that, you can go back to your source files and determine
>>> why the type (class/struct) is being defined differently in the
>>> different source files.
>>>
>>> NOTE TO MICROSOFT: Fix this stupid diagnostic! At the *BARE
>>> MINIMUM*, the offending TYPE and ATTRIBUTE should be displayed *BY
>>> NAME* -- hex tokens in diagnostics went out w/ Lattice C compilers
>>> and powdered wigs, they have *ABSOLUTELY NO BUSINESS IN A 7TH-PLUS
>>> GENERATION PRODUCT*
>>>
>>>
>>>>
>>>> Ronald Laeremans
>>>> Visual C++ team
>>>>
>>>> "Bret Pehrson" <bret@infowest. com> wrote in message
>>>> news:40056621.1 15089FF@infowes t.com...
>>>>> Hmmm...
>>>>>
>>>>> (I'm presuming that you work for/at Microsoft, or have internal
>>>>> contact w/ MS.)
>>>>>
>>>>> Could you contact the compiler group and have them document the
>>>>> metadata "Custom
>>>>> attributes are not consistent" error?
>>>>>
>>>>> Thanks
>>>>>
>>>>> "Yan-Hong Huang[MSFT]" wrote:
>>>>>>
>>>>>> Hello Bret,
>>>>>>
>>>>>> Thanks for posting in the group.
>>>>>>
>>>>>> Based on my understanding, the problem is: You are migrating an
>>>>>> old C++ library project to managed C++ project. However, when
>>>>>> you build the project, you got several error LNK2022: metadata
>>>>>> operation failed (80131195) link error. Please let me know if I
>>>>>> have misunderstood the problem.
>>>>>>
>>>>>> I searched in our database immediately when I saw your post.
>>>>>> Unluckily, the hits are small. And it seems that there were no
>>>>>> similar report before. So we can't tell exactly where the
>>>>>> problem may reside now.
>>>>>>
>>>>>> In order to troubleshoot the problem, could you please provide
>>>>>> us a small repro sample? We will look into it and reply with
>>>>>> detailed information here. You can reach me by removing online
>>>>>> from my email address here.
>>>>>>
>>>>>> I understand that C++ library is not trivial. Perhaps it is hard
>>>>>> for you to isolate the problem or create a repro sample. If so,
>>>>>> I suggest you contact our PSS (product support service) to have
>>>>>> one support engineer specially help you on it. If you need help
>>>>>> on contacting PSS, please feel free to post here and I will post
>>>>>> back with detailed information.
>>>>>>
>>>>>> If you have any more concerns on it, please feel free to post
>>>>>> here. Thanks very much and look forward to your response.
>>>>>>
>>>>>> Best regards,
>>>>>> Yanhong Huang
>>>>>> Microsoft Community Support
>>>>>>
>>>>>> Get Secure! ¨C www.microsoft.com/security
>>>>>> This posting is provided "AS IS" with no warranties, and confers
>>>>>> no rights.
>>>>>
>>>>> --
>>>>> Bret Pehrson
>>>>> mailto:bret@inf owest.com
>>>>> NOSPAM - Include this key in all e-mail correspondence
>>>>> <<38952rglkwdsl >>
>>>
>>> --
>>> Bret Pehrson
>>> mailto:bret@inf owest.com
>>> NOSPAM - Include this key in all e-mail correspondence
>>> <<38952rglkwdsl >>[/color][/color][/color]

**Ronald Laeremans [MSFT]** · Nov 17 '05, 01:31 PM

Re: Custom attributes are not consistent???

This specific issue would not be a service pack level fix. It requires a
quite substantive change. And it strictly isn't a bug rather than a (very
useful) feature that is missing. One of the problems with service packs is
the level of expectation that many customers have on them is significantly
higher than what we can realistically do in a service pack. The timing of
them is of course another issue.

Ronald

"Edward Diener" <eddielee@tropi csoft.com> wrote in message
news:%23HwNpm33 DHA.2656@tk2msf tngp13.phx.gbl. ..[color=blue]
> Bret Pehrson wrote:[color=green]
> > Ronald -- thanks for the response & comments. I (as well as others)
> > appreciate the insight that you provide on the reasons for the
> > issues, as well as a commitment to clarify/resolve/fix the issue.
> >
> > I've got to tell you, I'm *very* impressed w/ the response that I've
> > been getting to my issues from Microsoft. I've been out of the
> > newsgroup community for the past couple of years, but before I left,
> > typical MS response to just about any issue was: "That is a known
> > issue and will be fixed in a future release. <end>". It is readily
> > apparent that you all have made a concerted commitment to better
> > handle issues, questions, and comments through the newsgroups, and it
> > is greatly appreciated.[/color]
>
> The response from MS in these NGs is in inverse proportion to the service
> packs put out for VS Studio .NET, which so far has been 0 . While I too
> appreciate the response to reported problems and bugs by MS, I don't
> appreciate at all the fact that MS seems to think that end users must
> persevere with these problems and onerous workarounds for years at a time
> until they come up with a new release, and no doubt new bugs. I would much
> rather see service packs which actually fixed some of the problems which[/color]
are[color=blue]
> reported and acknowledge, making it easier to program without having to
> memorize all the bugs to be a successful MC++ or C# programmer.
>[color=green]
> >
> > Bret
> >
> > "Ronald Laeremans [MSFT]" wrote:[color=darkred]
> >>
> >> Hi Bret,
> >>
> >> I agree that the linker error you get in the VC 7.1 release is very
> >> far from ideal. You are seeing some growing pains of fitting a
> >> separate compilation model language like C++ into the CLR
> >> environment. We knew this issue going into the release of VC 7.1,
> >> but the code base we had worked with compiling to IJW internally and
> >> from the early adopters we got most feedback from didn't have a
> >> large number of occurrences of this issue, so we traded improving
> >> this off for other priority fixes. Subsequent experience both
> >> internally and externally has shown it to be quite prevalent though.
> >> We have been working on getting a KB out on this. I'll check on the
> >> status of that.
> >>
> >> I am also sorry for my _very_ terse explanation on how to use ildasm
> >> and I am glad you still were able to figure it out. We'll make sure
> >> your comments on ildasm get to the author of that tool.
> >>
> >> Ronald
> >>
> >> "Bret Pehrson" <bret@infowest. com> wrote in message
> >> news:4005DAE9.B 931DDF8@infowes t.com...
> >>> Ronald -- thanks for the reply. (Please note, none of my comments
> >>> are meant as a personal attack on you.)
> >>>
> >>>> In the Whidbey release the linker will give better diagnostics.
> >>>
> >>> I still stand by my previous post where I say it will be at least
> >>> the 4th release of the product before it is truly usable in a
> >>> commercial environment.
> >>>
> >>>> For now the way to diagnose this is using ildasm to dump the
> >>>> metadata of the .obj files to text and then search for the tokens
> >>>> (the hex numbers mentioned in the error messages). Usually this is
> >>>> a source error where 2 translation units define a type in a
> >>>> different way.
> >>>
> >>> Thanks for defining the mystery error. I was *finally* able to
> >>> find the source of the problem and resolve it using the technique
> >>> you describe -- thanks. My comments follow for the purpose of
> >>> actually documenting the procedure:
> >>>
> >>> First, ILDASM is a mixed-mode application meaning that it has a
> >>> GUI-mode and console-mode interface.
> >>>
> >>> When running in GUI mode, you *CANNOT* process .obj files (the only
> >>> files that are documented are .exe and .dll). This means that you
> >>> must use the tool from the command line (with the appropriate vars
> >>> set through vsvars32.bat or by running "Visual Studio .NET 2003
> >>> Command Prompt" from the VS.NET start menu tools group).
> >>>
> >>> When processing .obj files from the command line, YOU MUST REDIRECT
> >>> THE OUTPUT TO A FILE or else you will get no results - BUG! BUG!
> >>> Additionally, you must use the /text option to force output to the
> >>> console. So, it boils down to:
> >>>
> >>> ildasm your_source_fil e.obj /text /out=output.txt
> >>>
> >>> The file output.txt is then created -- open it up and then search
> >>> for the token in question (the last hex number of the "Custom
> >>> attributes are not consistent" error. (NOTE: the output token
> >>> identifiers *DO NOT* prefix hex numbers w/ the traditional 0x -- so
> >>> take this into account when searching for the token.) This will
> >>> locate the custom attribute of the token that is causing the error.
> >>> Once you know the token, it should be relatively easy to locate the
> >>> actual source of the problem.
> >>>
> >>> So, presuming the following errors:
> >>>
> >>> Assignment.obj : error LNK2022: metadata operation failed
> >>> (80131195) : Custom attributes are not consistent: (0x0c0001a5).
> >>>
> >>> The steps would be:
> >>>
> >>> ildasm Assignment.obj /text /out=assignment. txt
> >>>
> >>> Search assignment.txt for "0c0001a5". It should find some custom
> >>> attribute, look up a few lines and locate the offending type.
> >>> Armed with that, you can go back to your source files and determine
> >>> why the type (class/struct) is being defined differently in the
> >>> different source files.
> >>>
> >>> NOTE TO MICROSOFT: Fix this stupid diagnostic! At the *BARE
> >>> MINIMUM*, the offending TYPE and ATTRIBUTE should be displayed *BY
> >>> NAME* -- hex tokens in diagnostics went out w/ Lattice C compilers
> >>> and powdered wigs, they have *ABSOLUTELY NO BUSINESS IN A 7TH-PLUS
> >>> GENERATION PRODUCT*
> >>>
> >>>
> >>>>
> >>>> Ronald Laeremans
> >>>> Visual C++ team
> >>>>
> >>>> "Bret Pehrson" <bret@infowest. com> wrote in message
> >>>> news:40056621.1 15089FF@infowes t.com...
> >>>>> Hmmm...
> >>>>>
> >>>>> (I'm presuming that you work for/at Microsoft, or have internal
> >>>>> contact w/ MS.)
> >>>>>
> >>>>> Could you contact the compiler group and have them document the
> >>>>> metadata "Custom
> >>>>> attributes are not consistent" error?
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> "Yan-Hong Huang[MSFT]" wrote:
> >>>>>>
> >>>>>> Hello Bret,
> >>>>>>
> >>>>>> Thanks for posting in the group.
> >>>>>>
> >>>>>> Based on my understanding, the problem is: You are migrating an
> >>>>>> old C++ library project to managed C++ project. However, when
> >>>>>> you build the project, you got several error LNK2022: metadata
> >>>>>> operation failed (80131195) link error. Please let me know if I
> >>>>>> have misunderstood the problem.
> >>>>>>
> >>>>>> I searched in our database immediately when I saw your post.
> >>>>>> Unluckily, the hits are small. And it seems that there were no
> >>>>>> similar report before. So we can't tell exactly where the
> >>>>>> problem may reside now.
> >>>>>>
> >>>>>> In order to troubleshoot the problem, could you please provide
> >>>>>> us a small repro sample? We will look into it and reply with
> >>>>>> detailed information here. You can reach me by removing online
> >>>>>> from my email address here.
> >>>>>>
> >>>>>> I understand that C++ library is not trivial. Perhaps it is hard
> >>>>>> for you to isolate the problem or create a repro sample. If so,
> >>>>>> I suggest you contact our PSS (product support service) to have
> >>>>>> one support engineer specially help you on it. If you need help
> >>>>>> on contacting PSS, please feel free to post here and I will post
> >>>>>> back with detailed information.
> >>>>>>
> >>>>>> If you have any more concerns on it, please feel free to post
> >>>>>> here. Thanks very much and look forward to your response.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Yanhong Huang
> >>>>>> Microsoft Community Support
> >>>>>>
> >>>>>> Get Secure! ¨C www.microsoft.com/security
> >>>>>> This posting is provided "AS IS" with no warranties, and confers
> >>>>>> no rights.
> >>>>>
> >>>>> --
> >>>>> Bret Pehrson
> >>>>> mailto:bret@inf owest.com
> >>>>> NOSPAM - Include this key in all e-mail correspondence
> >>>>> <<38952rglkwdsl >>
> >>>
> >>> --
> >>> Bret Pehrson
> >>> mailto:bret@inf owest.com
> >>> NOSPAM - Include this key in all e-mail correspondence
> >>> <<38952rglkwdsl >>[/color][/color]
>
>[/color]

**Edward Diener** · Nov 17 '05, 01:31 PM

Re: Custom attributes are not consistent???

Ronald Laeremans [MSFT] wrote:[color=blue]
> This specific issue would not be a service pack level fix. It
> requires a quite substantive change. And it strictly isn't a bug
> rather than a (very useful) feature that is missing. One of the
> problems with service packs is the level of expectation that many
> customers have on them is significantly higher than what we can
> realistically do in a service pack. The timing of them is of course
> another issue.[/color]

You're excuses for not putting out a service pack are too transparent for
anyone of intelligence, and certainly doesn't fool this one. Nor will I
waste time trying to argue against your feeble spin.

If MS doesn't want to put out service packs anymore for Visual Studio, that
is their business, but it is not a proper way to support current customers
who must use your product, to consistently tell them that a bug has been
fixed for the next release of Visual Studio while they are looking for
reasonable solutions on this release. Your help, and that of other employees
of MS, in finding workarounds and solutions to current bugs is appreciated
on these NGs, but MS's new policy of not fixing bugs for the current release
can not endear your company to its customers.
[color=blue]
>
> Ronald
>
> "Edward Diener" <eddielee@tropi csoft.com> wrote in message
> news:%23HwNpm33 DHA.2656@tk2msf tngp13.phx.gbl. ..[color=green]
>> Bret Pehrson wrote:[color=darkred]
>>> Ronald -- thanks for the response & comments. I (as well as others)
>>> appreciate the insight that you provide on the reasons for the
>>> issues, as well as a commitment to clarify/resolve/fix the issue.
>>>
>>> I've got to tell you, I'm *very* impressed w/ the response that I've
>>> been getting to my issues from Microsoft. I've been out of the
>>> newsgroup community for the past couple of years, but before I left,
>>> typical MS response to just about any issue was: "That is a known
>>> issue and will be fixed in a future release. <end>". It is readily
>>> apparent that you all have made a concerted commitment to better
>>> handle issues, questions, and comments through the newsgroups, and
>>> it is greatly appreciated.[/color]
>>
>> The response from MS in these NGs is in inverse proportion to the
>> service packs put out for VS Studio .NET, which so far has been 0 .
>> While I too appreciate the response to reported problems and bugs by
>> MS, I don't appreciate at all the fact that MS seems to think that
>> end users must persevere with these problems and onerous workarounds
>> for years at a time until they come up with a new release, and no
>> doubt new bugs. I would much rather see service packs which actually
>> fixed some of the problems which are reported and acknowledge,
>> making it easier to program without having to memorize all the bugs
>> to be a successful MC++ or C# programmer.
>>[color=darkred]
>>>
>>> Bret
>>>
>>> "Ronald Laeremans [MSFT]" wrote:
>>>>
>>>> Hi Bret,
>>>>
>>>> I agree that the linker error you get in the VC 7.1 release is very
>>>> far from ideal. You are seeing some growing pains of fitting a
>>>> separate compilation model language like C++ into the CLR
>>>> environment. We knew this issue going into the release of VC 7.1,
>>>> but the code base we had worked with compiling to IJW internally
>>>> and from the early adopters we got most feedback from didn't have a
>>>> large number of occurrences of this issue, so we traded improving
>>>> this off for other priority fixes. Subsequent experience both
>>>> internally and externally has shown it to be quite prevalent
>>>> though. We have been working on getting a KB out on this. I'll
>>>> check on the status of that.
>>>>
>>>> I am also sorry for my _very_ terse explanation on how to use
>>>> ildasm and I am glad you still were able to figure it out. We'll
>>>> make sure your comments on ildasm get to the author of that tool.
>>>>
>>>> Ronald
>>>>
>>>> "Bret Pehrson" <bret@infowest. com> wrote in message
>>>> news:4005DAE9.B 931DDF8@infowes t.com...
>>>>> Ronald -- thanks for the reply. (Please note, none of my comments
>>>>> are meant as a personal attack on you.)
>>>>>
>>>>>> In the Whidbey release the linker will give better diagnostics.
>>>>>
>>>>> I still stand by my previous post where I say it will be at least
>>>>> the 4th release of the product before it is truly usable in a
>>>>> commercial environment.
>>>>>
>>>>>> For now the way to diagnose this is using ildasm to dump the
>>>>>> metadata of the .obj files to text and then search for the tokens
>>>>>> (the hex numbers mentioned in the error messages). Usually this
>>>>>> is a source error where 2 translation units define a type in a
>>>>>> different way.
>>>>>
>>>>> Thanks for defining the mystery error. I was *finally* able to
>>>>> find the source of the problem and resolve it using the technique
>>>>> you describe -- thanks. My comments follow for the purpose of
>>>>> actually documenting the procedure:
>>>>>
>>>>> First, ILDASM is a mixed-mode application meaning that it has a
>>>>> GUI-mode and console-mode interface.
>>>>>
>>>>> When running in GUI mode, you *CANNOT* process .obj files (the
>>>>> only files that are documented are .exe and .dll). This means
>>>>> that you must use the tool from the command line (with the
>>>>> appropriate vars set through vsvars32.bat or by running "Visual
>>>>> Studio .NET 2003 Command Prompt" from the VS.NET start menu tools
>>>>> group).
>>>>>
>>>>> When processing .obj files from the command line, YOU MUST
>>>>> REDIRECT THE OUTPUT TO A FILE or else you will get no results -
>>>>> BUG! BUG! Additionally, you must use the /text option to force
>>>>> output to the console. So, it boils down to:
>>>>>
>>>>> ildasm your_source_fil e.obj /text /out=output.txt
>>>>>
>>>>> The file output.txt is then created -- open it up and then search
>>>>> for the token in question (the last hex number of the "Custom
>>>>> attributes are not consistent" error. (NOTE: the output token
>>>>> identifiers *DO NOT* prefix hex numbers w/ the traditional 0x --
>>>>> so take this into account when searching for the token.) This will
>>>>> locate the custom attribute of the token that is causing the
>>>>> error. Once you know the token, it should be relatively easy to
>>>>> locate the actual source of the problem.
>>>>>
>>>>> So, presuming the following errors:
>>>>>
>>>>> Assignment.obj : error LNK2022: metadata operation failed
>>>>> (80131195) : Custom attributes are not consistent: (0x0c0001a5).
>>>>>
>>>>> The steps would be:
>>>>>
>>>>> ildasm Assignment.obj /text /out=assignment. txt
>>>>>
>>>>> Search assignment.txt for "0c0001a5". It should find some custom
>>>>> attribute, look up a few lines and locate the offending type.
>>>>> Armed with that, you can go back to your source files and
>>>>> determine why the type (class/struct) is being defined
>>>>> differently in the different source files.
>>>>>
>>>>> NOTE TO MICROSOFT: Fix this stupid diagnostic! At the *BARE
>>>>> MINIMUM*, the offending TYPE and ATTRIBUTE should be displayed *BY
>>>>> NAME* -- hex tokens in diagnostics went out w/ Lattice C compilers
>>>>> and powdered wigs, they have *ABSOLUTELY NO BUSINESS IN A 7TH-PLUS
>>>>> GENERATION PRODUCT*
>>>>>
>>>>>
>>>>>>
>>>>>> Ronald Laeremans
>>>>>> Visual C++ team
>>>>>>
>>>>>> "Bret Pehrson" <bret@infowest. com> wrote in message
>>>>>> news:40056621.1 15089FF@infowes t.com...
>>>>>>> Hmmm...
>>>>>>>
>>>>>>> (I'm presuming that you work for/at Microsoft, or have internal
>>>>>>> contact w/ MS.)
>>>>>>>
>>>>>>> Could you contact the compiler group and have them document the
>>>>>>> metadata "Custom
>>>>>>> attributes are not consistent" error?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> "Yan-Hong Huang[MSFT]" wrote:
>>>>>>>>
>>>>>>>> Hello Bret,
>>>>>>>>
>>>>>>>> Thanks for posting in the group.
>>>>>>>>
>>>>>>>> Based on my understanding, the problem is: You are migrating an
>>>>>>>> old C++ library project to managed C++ project. However, when
>>>>>>>> you build the project, you got several error LNK2022: metadata
>>>>>>>> operation failed (80131195) link error. Please let me know if I
>>>>>>>> have misunderstood the problem.
>>>>>>>>
>>>>>>>> I searched in our database immediately when I saw your post.
>>>>>>>> Unluckily, the hits are small. And it seems that there were no
>>>>>>>> similar report before. So we can't tell exactly where the
>>>>>>>> problem may reside now.
>>>>>>>>
>>>>>>>> In order to troubleshoot the problem, could you please provide
>>>>>>>> us a small repro sample? We will look into it and reply with
>>>>>>>> detailed information here. You can reach me by removing online
>>>>>>>> from my email address here.
>>>>>>>>
>>>>>>>> I understand that C++ library is not trivial. Perhaps it is
>>>>>>>> hard for you to isolate the problem or create a repro sample.
>>>>>>>> If so, I suggest you contact our PSS (product support service)
>>>>>>>> to have one support engineer specially help you on it. If you
>>>>>>>> need help on contacting PSS, please feel free to post here and
>>>>>>>> I will post back with detailed information.
>>>>>>>>
>>>>>>>> If you have any more concerns on it, please feel free to post
>>>>>>>> here. Thanks very much and look forward to your response.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Yanhong Huang
>>>>>>>> Microsoft Community Support
>>>>>>>>
>>>>>>>> Get Secure! ¨C www.microsoft.com/security
>>>>>>>> This posting is provided "AS IS" with no warranties, and
>>>>>>>> confers no rights.
>>>>>>>
>>>>>>> --
>>>>>>> Bret Pehrson
>>>>>>> mailto:bret@inf owest.com
>>>>>>> NOSPAM - Include this key in all e-mail correspondence
>>>>>>> <<38952rglkwdsl >>
>>>>>
>>>>> --
>>>>> Bret Pehrson
>>>>> mailto:bret@inf owest.com
>>>>> NOSPAM - Include this key in all e-mail correspondence
>>>>> <<38952rglkwdsl >>[/color][/color][/color]

**Ronald Laeremans [MSFT]** · Nov 17 '05, 01:31 PM

Re: Custom attributes are not consistent???

Hi Edward,

Our policy on service packs has not changed over the last decade. The only
time Visual C++ has ever done what you are asking for is with the VC 4.x
subscription releases that contained not just critical bug fixes, but also
non critical bug fixes new features or 'issue fixes' that we were able to do
in a limited timeframe.

All other times the SP policy for VC and other components of Visual Studio
has been fixing critical bugs in the product.

As for VS 2002, I feel very strongly that we made the right call by focusing
on the VS 2003 release instead of on the SP for VS 2002 so that we could
deliver at least 2 orders of magnitude more improvements (both bug fixes,
addressing larger issues and doing new features) on a short timeline and
make that product available at a trivial cost (of $29 for the upgrade
offer).

Ronald

"Edward Diener" <eddielee@tropi csoft.com> wrote in message
news:ebPgTAJ4DH A.2380@TK2MSFTN GP11.phx.gbl...[color=blue]
> Ronald Laeremans [MSFT] wrote:[color=green]
> > This specific issue would not be a service pack level fix. It
> > requires a quite substantive change. And it strictly isn't a bug
> > rather than a (very useful) feature that is missing. One of the
> > problems with service packs is the level of expectation that many
> > customers have on them is significantly higher than what we can
> > realistically do in a service pack. The timing of them is of course
> > another issue.[/color]
>
> You're excuses for not putting out a service pack are too transparent for
> anyone of intelligence, and certainly doesn't fool this one. Nor will I
> waste time trying to argue against your feeble spin.
>
> If MS doesn't want to put out service packs anymore for Visual Studio,[/color]
that[color=blue]
> is their business, but it is not a proper way to support current customers
> who must use your product, to consistently tell them that a bug has been
> fixed for the next release of Visual Studio while they are looking for
> reasonable solutions on this release. Your help, and that of other[/color]
employees[color=blue]
> of MS, in finding workarounds and solutions to current bugs is appreciated
> on these NGs, but MS's new policy of not fixing bugs for the current[/color]
release[color=blue]
> can not endear your company to its customers.
>[color=green]
> >
> > Ronald
> >
> > "Edward Diener" <eddielee@tropi csoft.com> wrote in message
> > news:%23HwNpm33 DHA.2656@tk2msf tngp13.phx.gbl. ..[color=darkred]
> >> Bret Pehrson wrote:
> >>> Ronald -- thanks for the response & comments. I (as well as others)
> >>> appreciate the insight that you provide on the reasons for the
> >>> issues, as well as a commitment to clarify/resolve/fix the issue.
> >>>
> >>> I've got to tell you, I'm *very* impressed w/ the response that I've
> >>> been getting to my issues from Microsoft. I've been out of the
> >>> newsgroup community for the past couple of years, but before I left,
> >>> typical MS response to just about any issue was: "That is a known
> >>> issue and will be fixed in a future release. <end>". It is readily
> >>> apparent that you all have made a concerted commitment to better
> >>> handle issues, questions, and comments through the newsgroups, and
> >>> it is greatly appreciated.
> >>
> >> The response from MS in these NGs is in inverse proportion to the
> >> service packs put out for VS Studio .NET, which so far has been 0 .
> >> While I too appreciate the response to reported problems and bugs by
> >> MS, I don't appreciate at all the fact that MS seems to think that
> >> end users must persevere with these problems and onerous workarounds
> >> for years at a time until they come up with a new release, and no
> >> doubt new bugs. I would much rather see service packs which actually
> >> fixed some of the problems which are reported and acknowledge,
> >> making it easier to program without having to memorize all the bugs
> >> to be a successful MC++ or C# programmer.
> >>
> >>>
> >>> Bret
> >>>
> >>> "Ronald Laeremans [MSFT]" wrote:
> >>>>
> >>>> Hi Bret,
> >>>>
> >>>> I agree that the linker error you get in the VC 7.1 release is very
> >>>> far from ideal. You are seeing some growing pains of fitting a
> >>>> separate compilation model language like C++ into the CLR
> >>>> environment. We knew this issue going into the release of VC 7.1,
> >>>> but the code base we had worked with compiling to IJW internally
> >>>> and from the early adopters we got most feedback from didn't have a
> >>>> large number of occurrences of this issue, so we traded improving
> >>>> this off for other priority fixes. Subsequent experience both
> >>>> internally and externally has shown it to be quite prevalent
> >>>> though. We have been working on getting a KB out on this. I'll
> >>>> check on the status of that.
> >>>>
> >>>> I am also sorry for my _very_ terse explanation on how to use
> >>>> ildasm and I am glad you still were able to figure it out. We'll
> >>>> make sure your comments on ildasm get to the author of that tool.
> >>>>
> >>>> Ronald
> >>>>
> >>>> "Bret Pehrson" <bret@infowest. com> wrote in message
> >>>> news:4005DAE9.B 931DDF8@infowes t.com...
> >>>>> Ronald -- thanks for the reply. (Please note, none of my comments
> >>>>> are meant as a personal attack on you.)
> >>>>>
> >>>>>> In the Whidbey release the linker will give better diagnostics.
> >>>>>
> >>>>> I still stand by my previous post where I say it will be at least
> >>>>> the 4th release of the product before it is truly usable in a
> >>>>> commercial environment.
> >>>>>
> >>>>>> For now the way to diagnose this is using ildasm to dump the
> >>>>>> metadata of the .obj files to text and then search for the tokens
> >>>>>> (the hex numbers mentioned in the error messages). Usually this
> >>>>>> is a source error where 2 translation units define a type in a
> >>>>>> different way.
> >>>>>
> >>>>> Thanks for defining the mystery error. I was *finally* able to
> >>>>> find the source of the problem and resolve it using the technique
> >>>>> you describe -- thanks. My comments follow for the purpose of
> >>>>> actually documenting the procedure:
> >>>>>
> >>>>> First, ILDASM is a mixed-mode application meaning that it has a
> >>>>> GUI-mode and console-mode interface.
> >>>>>
> >>>>> When running in GUI mode, you *CANNOT* process .obj files (the
> >>>>> only files that are documented are .exe and .dll). This means
> >>>>> that you must use the tool from the command line (with the
> >>>>> appropriate vars set through vsvars32.bat or by running "Visual
> >>>>> Studio .NET 2003 Command Prompt" from the VS.NET start menu tools
> >>>>> group).
> >>>>>
> >>>>> When processing .obj files from the command line, YOU MUST
> >>>>> REDIRECT THE OUTPUT TO A FILE or else you will get no results -
> >>>>> BUG! BUG! Additionally, you must use the /text option to force
> >>>>> output to the console. So, it boils down to:
> >>>>>
> >>>>> ildasm your_source_fil e.obj /text /out=output.txt
> >>>>>
> >>>>> The file output.txt is then created -- open it up and then search
> >>>>> for the token in question (the last hex number of the "Custom
> >>>>> attributes are not consistent" error. (NOTE: the output token
> >>>>> identifiers *DO NOT* prefix hex numbers w/ the traditional 0x --
> >>>>> so take this into account when searching for the token.) This will
> >>>>> locate the custom attribute of the token that is causing the
> >>>>> error. Once you know the token, it should be relatively easy to
> >>>>> locate the actual source of the problem.
> >>>>>
> >>>>> So, presuming the following errors:
> >>>>>
> >>>>> Assignment.obj : error LNK2022: metadata operation failed
> >>>>> (80131195) : Custom attributes are not consistent: (0x0c0001a5).
> >>>>>
> >>>>> The steps would be:
> >>>>>
> >>>>> ildasm Assignment.obj /text /out=assignment. txt
> >>>>>
> >>>>> Search assignment.txt for "0c0001a5". It should find some custom
> >>>>> attribute, look up a few lines and locate the offending type.
> >>>>> Armed with that, you can go back to your source files and
> >>>>> determine why the type (class/struct) is being defined
> >>>>> differently in the different source files.
> >>>>>
> >>>>> NOTE TO MICROSOFT: Fix this stupid diagnostic! At the *BARE
> >>>>> MINIMUM*, the offending TYPE and ATTRIBUTE should be displayed *BY
> >>>>> NAME* -- hex tokens in diagnostics went out w/ Lattice C compilers
> >>>>> and powdered wigs, they have *ABSOLUTELY NO BUSINESS IN A 7TH-PLUS
> >>>>> GENERATION PRODUCT*
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Ronald Laeremans
> >>>>>> Visual C++ team
> >>>>>>
> >>>>>> "Bret Pehrson" <bret@infowest. com> wrote in message
> >>>>>> news:40056621.1 15089FF@infowes t.com...
> >>>>>>> Hmmm...
> >>>>>>>
> >>>>>>> (I'm presuming that you work for/at Microsoft, or have internal
> >>>>>>> contact w/ MS.)
> >>>>>>>
> >>>>>>> Could you contact the compiler group and have them document the
> >>>>>>> metadata "Custom
> >>>>>>> attributes are not consistent" error?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> "Yan-Hong Huang[MSFT]" wrote:
> >>>>>>>>
> >>>>>>>> Hello Bret,
> >>>>>>>>
> >>>>>>>> Thanks for posting in the group.
> >>>>>>>>
> >>>>>>>> Based on my understanding, the problem is: You are migrating an
> >>>>>>>> old C++ library project to managed C++ project. However, when
> >>>>>>>> you build the project, you got several error LNK2022: metadata
> >>>>>>>> operation failed (80131195) link error. Please let me know if I
> >>>>>>>> have misunderstood the problem.
> >>>>>>>>
> >>>>>>>> I searched in our database immediately when I saw your post.
> >>>>>>>> Unluckily, the hits are small. And it seems that there were no
> >>>>>>>> similar report before. So we can't tell exactly where the
> >>>>>>>> problem may reside now.
> >>>>>>>>
> >>>>>>>> In order to troubleshoot the problem, could you please provide
> >>>>>>>> us a small repro sample? We will look into it and reply with
> >>>>>>>> detailed information here. You can reach me by removing online
> >>>>>>>> from my email address here.
> >>>>>>>>
> >>>>>>>> I understand that C++ library is not trivial. Perhaps it is
> >>>>>>>> hard for you to isolate the problem or create a repro sample.
> >>>>>>>> If so, I suggest you contact our PSS (product support service)
> >>>>>>>> to have one support engineer specially help you on it. If you
> >>>>>>>> need help on contacting PSS, please feel free to post here and
> >>>>>>>> I will post back with detailed information.
> >>>>>>>>
> >>>>>>>> If you have any more concerns on it, please feel free to post
> >>>>>>>> here. Thanks very much and look forward to your response.
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>> Yanhong Huang
> >>>>>>>> Microsoft Community Support
> >>>>>>>>
> >>>>>>>> Get Secure! ¨C www.microsoft.com/security
> >>>>>>>> This posting is provided "AS IS" with no warranties, and
> >>>>>>>> confers no rights.
> >>>>>>>
> >>>>>>> --
> >>>>>>> Bret Pehrson
> >>>>>>> mailto:bret@inf owest.com
> >>>>>>> NOSPAM - Include this key in all e-mail correspondence
> >>>>>>> <<38952rglkwdsl >>
> >>>>>
> >>>>> --
> >>>>> Bret Pehrson
> >>>>> mailto:bret@inf owest.com
> >>>>> NOSPAM - Include this key in all e-mail correspondence
> >>>>> <<38952rglkwdsl >>[/color][/color]
>
>[/color]

Custom attributes are not consistent???

Custom attributes are not consistent???

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment