-----------------------------------------------------------

New Message on BDOTNET

-----------------------------------------------------------
From: Sitaraman
Message 8 in Discussion

Hi   would like to reiterate that my analysis was of a total academic value and not to 
poke at MS(would be the last person in the world to do tht :) )    Spelunking is a 
good idea, but you should see the overall picture and try to infer if the bug in 
question is really creating a havoc. --- Agree.  This class probably is not even known 
to a majority of .Net developers( intellisense does not show this class, no msdn 
reference, no web sites having details and normally wat u dont see, u dont use :)  ) 
and the problem has a very limited impact.  Accidentally i came across this(trying to 
find out why the VS.Net IDE gives the context as private when the constructor is 
actually a Friend. Not sure whether this bug is the reason for tht, just a 
interpretation and corelation(probably a dumb one...)).    Friend access specifier, as 
you correctly understand, and is equivalent to an internal of C#, implying that the 
member will be accessible within the assembly only.   Now, agreed that there is a 
possible Copy-Paste issue in the implementation code, but does that affect the actual 
working of the code? No, it doesnt. --- well!!!!  depends on the perspective :).  If 
someone is using the function to get the full signature of the method(), then that 
person would get affected.  Agree that very few might know about the class and 99.9% 
of .Net devs might never use the same.  But at the same time, as i mentioned,  the 
sole intention of posting this was that the problem is made known and gets corrected, 
and the code was just a proof of concept!!!   First of all, you are using MemberInfo 
to determine the problem, when it should be a MethodInfo.  ----well, to quote you 
"does that affect the actual working of the code" .  In fact i should have used a 
MethodBase and not MethodInfo,     a) so as to conform to the signature of the 
MethodToString() method b) which again is because,  it can give the info for both 
ConstructorInfo & MethodInfo objects and using a MethodInfo would have blocked out 
constructors.     Just went one level above MethodBase and used memberInfo     Even 
with that said, the MethodToString implementation does result in incorrect string 
being returned. However, to determine the scope of the method, the Attributes property 
of the MethodInfo object should be used, and that correctly indicates the method to be 
of the Assembly type. -----Agree. But my intention was to get the full signature of 
the method and thought i might as well use a method provided by MS    The idea of my 
post is to subdue any doubts that might come in the mind of a developer that might 
lead him to think that MS's own stuff is buggy and wont work.   -----Never meant to 
say that MS's own stuff is buggy.  When a software of this scale and volume is 
released, it is obvious that such mistakes will be present(just have to take a look at 
the amount of bugs in the (comparitively very small-scale)applications that I design 
myself :(  ) and I do understand that these will be( and are)  corrected as it 
evolves... Just thought that i might as well post it in the forum so that they know 
the problem exists.       We all know that Reflection is a better way to do this, but 
sometimes, doubts do creep up and get the views that are not expected from the 
community, if you know what I mean.  -----i perfectly understand!!!  would like to 
reiterate that,  this problem has a a very low impact, as i believe the classes in the 
Microsoft.VisualBasic.compilerservices is intended for internal usage by MS and not 
for the general public(absolutely no reference in MSDN/MS Site.  Even google throws up 
only four results for the keywordMicrosoft.VisualBasic.compilerservices.utils, and 
they dont have any information in it ).   At the same time,  there are quite a few 
classes in this namespace  which is worth looking at,  if one wants to understand how 
the system works internally.  For example, as explained in one of my previous posts,  
to know how the "method level static modifier" of VB.Net works,  you need to know the 
details of the StaticLocalInitFlag Class and this is available in this 
Microsoft.VisualBasic.CompilerServices namespace....   As I said, spelunking is 
good... infact, one tends to learn a lot more when spelkunking. Just needs to be 
ensured that facts/observations are put forward, everything comes up front! -----u 
bet!!! the main advantage is that when u try to get into the internals u end up 
learning a lot more than wat u originally expected to learn.  This is the reason why i 
posted the full code and disassembly so that others can not only know the existence of 
the problem, but at the same time know the reason for it(and ofcourse to quote rosh,  
"there is this sense of accomplishment"...)        regards,   sr

-----------------------------------------------------------

To stop getting this e-mail, or change how often it arrives, go to your E-mail 
Settings.
http://groups.msn.com/BDotNet/_emailsettings.msnw

Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help

For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact

If you do not want to receive future e-mail from this MSN group, or if you received 
this message by mistake, please click the "Remove" link below. On the pre-addressed 
e-mail message that opens, simply click "Send". Your e-mail address will be deleted 
from this group's mailing list.
mailto:[EMAIL PROTECTED]

Reply via email to