473,887 Members | 2,286 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Custom attributes are not consistent???

I've converted a non-trivial C++ library to managed, and get the following
unhelpful linker error:

Assignment.obj : error LNK2022: metadata operation failed (80131195) : Custom
attributes are not consistent: (0x0c0001a5).
Display.obj : error LNK2022: metadata operation failed (80131195) : Custom
attributes are not consistent: (0x0c000108).
The help for LNK2022 is completely useless:

metadata operation failed (HRESULT) : error_message

The linker detected an error while merging metadata. The metadata errors must
be resolved to link successfully.

One reason for LNK2022 is when a struct exists in multiple modules with the
same name, but with conflicting definitions, and when you compile with /clr.
<<

A search for "Custom attributes are not consistent" at MS turns up *NO*
results, and google/google groups only returns a few -- none of which really
discuss the problem or it (eventual?) solution.

In this case, I've looked over the source file, and there are no mystery
structs floating around, although my searches are far from definitive as the
project is composed of hundreds of inter-related files/headers.

Has *ANYONE* figured out or would MS care to elaborate on what the "Custom
attributes are not consistent" error means and what the final hex number
means? Apparently it has some dynamic value, as similar errors have different
values.

--
Bret Pehrson
mailto:br**@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>
Nov 17 '05
16 9310
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! 每 www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 17 '05 #11
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" <br**@infowest. com> wrote in message
news:40******** *******@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" <br**@infowest. com> wrote in message
news:40******** *******@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! 每 www.microsoft.com/security
>> This posting is provided "AS IS" with no warranties, and confers
>> no rights.
>
> --
> Bret Pehrson
> mailto:br**@inf owest.com
> NOSPAM - Include this key in all e-mail correspondence
> <<38952rglkwdsl >>

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

Nov 17 '05 #12
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" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
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" <br**@infowest. com> wrote in message
news:40******** *******@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" <br**@infowest. com> wrote in message
> news:40******** *******@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! 每 www.microsoft.com/security
>>> This posting is provided "AS IS" with no warranties, and confers
>>> no rights.
>>
>> --
>> Bret Pehrson
>> mailto:br**@inf owest.com
>> NOSPAM - Include this key in all e-mail correspondence
>> <<38952rglkwdsl >>

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


Nov 17 '05 #13
Ronald Laeremans [MSFT] wrote:
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.
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.

Ronald

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
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" <br**@infowest. com> wrote in message
news:40******** *******@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" <br**@infowest. com> wrote in message
>> news:40******** *******@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! 每 www.microsoft.com/security
>>>> This posting is provided "AS IS" with no warranties, and
>>>> confers no rights.
>>>
>>> --
>>> Bret Pehrson
>>> mailto:br**@inf owest.com
>>> NOSPAM - Include this key in all e-mail correspondence
>>> <<38952rglkwdsl >>
>
> --
> Bret Pehrson
> mailto:br**@inf owest.com
> NOSPAM - Include this key in all e-mail correspondence
> <<38952rglkwdsl >>

Nov 17 '05 #14
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" <ed******@tropi csoft.com> wrote in message
news:eb******** ******@TK2MSFTN GP11.phx.gbl...
Ronald Laeremans [MSFT] wrote:
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.
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.

Ronald

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
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" <br**@infowest. com> wrote in message
> news:40******** *******@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" <br**@infowest. com> wrote in message
>>> news:40******** *******@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! 每 www.microsoft.com/security
>>>>> This posting is provided "AS IS" with no warranties, and
>>>>> confers no rights.
>>>>
>>>> --
>>>> Bret Pehrson
>>>> mailto:br**@inf owest.com
>>>> NOSPAM - Include this key in all e-mail correspondence
>>>> <<38952rglkwdsl >>
>>
>> --
>> Bret Pehrson
>> mailto:br**@inf owest.com
>> NOSPAM - Include this key in all e-mail correspondence
>> <<38952rglkwdsl >>


Nov 17 '05 #15
Ronald Laeremans [MSFT] wrote:
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).
Microsoft put out five service packs for VS6 and you have put out none for
VS .NET. Based on that it is very hard to believe that MS's policy on
service packs has not changed over the last decade. There is an obvious
critical bug with MC++ which is very well documented by MS, said to be fixed
with Whidbey, regarding mixed mode MC++ and assembly startup. There are
other serious bugs, especially with MC++ ( I reported one personal
showstopper recently for which I still have not gotten back a solution ),
and there are other bugs as this thread shows. What MS deems to be critical
is your own choice but I interpret MS's inability to get out needed service
packs for VS .NET as the usual monetary situation, meaning that you want to
be paid for fixing bugs in your own product via a new release and a new
revenue stream. Also I am sure that service packs for VS6 fixed many
problems which may not have been critical but which were highly irritating,
burdensome, and time consuming for programmers not only to encounter and
verify but to find a workaround for.

You can justify your company's policy regarding service packs for VS .NET
however if you like, but it is just that to me; a justification from a
company employee and not a fair technical assessment of the need to update
your product to make it easier for others to use it. I am sure I am not the
only programmer using VS .NET who feels that MS should put out service packs
for the product, just like they did for VS6, to fix problems and let
programmers get on with their work. Being told that a particular problem is
fixed for the next release is nice, but that does not help people working
with the current release who are producing critical software.

Ronald

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eb******** ******@TK2MSFTN GP11.phx.gbl...
Ronald Laeremans [MSFT] wrote:
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.


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.

Ronald

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
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" <br**@infowest. com> wrote in message
>> news:40******** *******@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" <br**@infowest. com> wrote in message
>>>> news:40******** *******@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! 每 www.microsoft.com/security
>>>>>> This posting is provided "AS IS" with no warranties, and
>>>>>> confers no rights.
>>>>>
>>>>> --
>>>>> Bret Pehrson
>>>>> mailto:br**@inf owest.com
>>>>> NOSPAM - Include this key in all e-mail correspondence
>>>>> <<38952rglkwdsl >>
>>>
>>> --
>>> Bret Pehrson
>>> mailto:br**@inf owest.com
>>> NOSPAM - Include this key in all e-mail correspondence
>>> <<38952rglkwdsl >>

Nov 17 '05 #16

My partner and I encountered this problem as well, and while ILDAS
worked, it didn't get us much closer to finding the solution--it looke
like the types that were causing the problem came from libc!

In the end, we discovered that some of our managed C++ project
included *.c files. Setting these files to be unmanaged (in Fil
Properties) fixed the problem
-
James Lair
-----------------------------------------------------------------------
Posted via http://www.mcse.m
-----------------------------------------------------------------------
View this thread: http://www.mcse.ms/message278801.htm

Nov 17 '05 #17

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
454
by: Doug Holland | last post by:
Often you see code where an empty interface is used to indicate something about the class that realizes it. In the .NET world this can be done with custom attributes too, so which is better: public class SomeClass : IEmptyInterface or
1
2157
by: Bret Pehrson | last post by:
I've converted a non-trivial C++ library to managed, and get the following unhelpful linker error: Assignment.obj : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0001a5). Display.obj : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c000108). The help for LNK2022 is completely useless:
3
2155
by: Edward Diener | last post by:
I understand the syntax of custom attributes, but I have no idea what they are supposed to do. Anyone care to give me a clue as to their functionality ?
1
4216
by: Tamas Demjen | last post by:
I started to experiment with VC++ 2005 Beta1. So far everything went fine, and already have a working project, but soon I realized that the compiler was ancient (not supporting half of the C++/CLI standard). So I downloaded the VC++ 2005 Tools Refresh (http://tinyurl.com/5mdq2). After that I tried to do a full rebuild, but my project wouldn't link anymore. I get the following errors: MSVCMRTD.lib(mstartup.obj) : error LNK2022: metadata...
3
3542
by: The Developer | last post by:
Hi All, I have a web application where I am adding a custom attribute to my ASP.NET text box control and changing value of that attribute at client side using JavaScript. My problem is that changed value of that custom attribute is not reflecting back at server side. Any ideas about this problem? Server side code: private void Page_Load(object sender, EventArgs e) { if (this.IsPostBack == false)
0
1048
by: Sanjay Pais | last post by:
This is an extension of an earlier post I have created a custom text box and compiled it and dropped it into my toolbox. However when I change the value of my custom property in design mode and switch between design mode to page source and back to design mode i am unable to retrieve the property value I set. Also the property setting in the html page is lost. Thsi is the error I get **********************************...
15
1938
by: Sam Kong | last post by:
Hello! I got recently intrigued with JavaScript's prototype-based object-orientation. However, I still don't understand the mechanism clearly. What's the difference between the following two? (1)
9
3147
by: wardy1975 | last post by:
Hi All, Looking for a little expert advice on a few web standards issues. I am currently trying to understand the impact of web standards for a web application I work with. I have been doing a lot of research in the areas of XHTML and WAI compliance, and am attempting to come up with a recommendation for our product in terms of standards level compliance. Ideally, I would like to be at XHTML 1.0 Strict. However, in my reading I have...
3
3207
by: Mark R. Dawson | last post by:
Hi all, I am trying to get custom attributes from a property. I can do this if I pass in the name of the property i.e. "Name" to the reflection methods, but if I pass in set_Name which is what the set piece of the Name property gets compiled to, which I am getting from the stack trace, then the attributes are not returned. For example, Class Person has a property called "Name" which has a custom attribute decorating it. Inside the set...
2
2540
by: prabhupr | last post by:
Hi Folks I was reading this article (http://www.dotnetbips.com/articles/displayarticle.aspx?id=32) on "Custom Attribute", written by Bipin. The only thing I did not understand in this article is the usage of "Custom Attribute" in real life project. Can somebody please help me understand where are these informations really helpful in Development Environment; may be a few example(s) will help me understand.
0
11173
Oralloy
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10771
jinu1996
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10877
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 Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9593
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development projectplanning, coding, testing, and deploymentwithout human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7143
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
6011
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4633
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4239
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3245
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.