"vighnesh" wrote:

> Hello Everyone
>
> I am about to develop a project like Registry Mechanic using either VB.NET
> or C#.NET.
> But I dont know is it worth while in using these languages ? I mean is there
> necessary support
> provided in .NET to accomplish this task? If Provided please suggest me the
> approach.
>
> Regards
> Vighneswar
>
>
>
>

"Cor Ligthert [MVP]" wrote:

> Vignesh,
>
> There is one part that is not in VBNet while it is in C#. That is unsafe
> code which makes it you possible to do some more raw processes with the OS.
>
> Therefore I would choose for your problem probably direct C#
>
> I hope this helps,
>
> Cor
>
>
>

"rmacias" <rmacias@newsgroup.nospam> schreef in bericht
news:78F86544-109D-4089-A889-20F1D27EA1FC@microsoft.com...
> If he needs to work w/ the registry he can use the
> Microsoft.Win32.Registry
> and Microsoft.Win32.RegistryKey classes to do so.  This can be done in
> either
> VB.NET or C#.  How does direct pointer manipulation give him an advantage?
>
> "Cor Ligthert [MVP]" wrote:
>
>> Vignesh,
>>
>> There is one part that is not in VBNet while it is in C#. That is unsafe
>> code which makes it you possible to do some more raw processes with the
>> OS.
>>
>> Therefore I would choose for your problem probably direct C#
>>
>> I hope this helps,
>>
>> Cor
>>
>>
>>

"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> schreef in bericht
news:%23ebuKv2PGHA.5924@TK2MSFTNGP09.phx.gbl...
> rmacias,
>
> In my opinion is the Registry one point, however to see if the registry is
> correct you have to do investigations. That part seems for me the more
> difficult part. Not the registry itself what is straight forward both in
> C# and VB.Net
>
> Just my thought,
>
> Cor
>
> "rmacias" <rmacias@newsgroup.nospam> schreef in bericht
> news:78F86544-109D-4089-A889-20F1D27EA1FC@microsoft.com...
>> If he needs to work w/ the registry he can use the
>> Microsoft.Win32.Registry
>> and Microsoft.Win32.RegistryKey classes to do so.  This can be done in
>> either
>> VB.NET or C#.  How does direct pointer manipulation give him an
>> advantage?
>>
>> "Cor Ligthert [MVP]" wrote:
>>
>>> Vignesh,
>>>
>>> There is one part that is not in VBNet while it is in C#. That is unsafe
>>> code which makes it you possible to do some more raw processes with the
>>> OS.
>>>
>>> Therefore I would choose for your problem probably direct C#
>>>
>>> I hope this helps,
>>>
>>> Cor
>>>
>>>
>>>
>
>

"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:%23ebuKv2PGHA.5924@TK2MSFTNGP09.phx.gbl...
> rmacias,
>
> In my opinion is the Registry one point, however to see if the registry is
> correct you have to do investigations. That part seems for me the more
> difficult part. Not the registry itself what is straight forward both in
> C# and VB.Net
>
> Just my thought,
>
> Cor
>
> "rmacias" <rmacias@newsgroup.nospam> schreef in bericht
> news:78F86544-109D-4089-A889-20F1D27EA1FC@microsoft.com...
>> If he needs to work w/ the registry he can use the
>> Microsoft.Win32.Registry
>> and Microsoft.Win32.RegistryKey classes to do so.  This can be done in
>> either
>> VB.NET or C#.  How does direct pointer manipulation give him an
>> advantage?
>>
>> "Cor Ligthert [MVP]" wrote:
>>
>>> Vignesh,
>>>
>>> There is one part that is not in VBNet while it is in C#. That is unsafe
>>> code which makes it you possible to do some more raw processes with the
>>> OS.
>>>
>>> Therefore I would choose for your problem probably direct C#
>>>
>>> I hope this helps,
>>>
>>> Cor
>>>
>>>
>>>
>
>

"vighnesh" <vighn***@nannacomputers.com> wrote in message
news:eqt56p0PGHA.3016@tk2msftngp13.phx.gbl...
> Hello Everyone
>
> I am about to develop a project like Registry Mechanic using either VB.NET
> or C#.NET.
> But I dont know is it worth while in using these languages ? I mean is
> there necessary support
> provided in .NET to accomplish this task? If Provided please suggest me
> the approach.
>
> Regards
> Vighneswar
>
>
>

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
>> >    I have used VB since it was released and I was actually a beta
>> > tester
>> > when it was called Thunder back around 1990.  I picked up VB.NET when
>> > it
>> > was first released, and developed a few applications using it, but
>> > quickly
>> > made the transition to C#. In  the last 5 years I have came to the
>> > conclusion that it is best to know the "Three C's".  The "Three C's"
>> > are
>> > C, C++, and C#.
>>
>> I do not see many similarities between C/C++ and C#.
>
> Not even in syntax?

"Fabio" wrote:

> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> ha scritto nel
> messaggio
>
> > Could you give some samples where using 'Mid', 'Right', and 'Left' would
> > produce "trash IL"?  It's even possible to write semantically incorrect
> > code using the low-level 'String.Substring' method.
>
> this is the code of Mid()
>
> Public Shared Function Mid(ByVal str As String, ByVal Start As Integer,
> ByVal Length As Integer) As String
>       If (Start <= 0) Then
>             Throw New
> ArgumentException(Utils.GetResourceString("Argument_GTZero1", New String()
> { "Start" }))
>       End If
>       If (Length < 0) Then
>             Throw New
> ArgumentException(Utils.GetResourceString("Argument_GEZero1", New String()
> { "Length" }))
>       End If
>       If ((Length = 0) OrElse (str Is Nothing)) Then
>             Return ""
>       End If
>       Dim num1 As Integer = str.Length
>       If (Start > num1) Then
>             Return ""
>       End If
>       If ((Start + Length) > num1) Then
>             Return str.Substring((Start - 1))
>       End If
>       Return str.Substring((Start - 1), Length)
> End Function
>
>
>
> of Right
>
> Public Shared Function Right(ByVal str As String, ByVal Length As Integer)
> As String
>       If (Length < 0) Then
>             Throw New
> ArgumentException(Utils.GetResourceString("Argument_GEZero1", New String()
> { "Length" }))
>       End If
>       If ((Length = 0) OrElse (str Is Nothing)) Then
>             Return ""
>       End If
>       Dim num1 As Integer = str.Length
>       If (Length >= num1) Then
>             Return str
>       End If
>       Return str.Substring((num1 - Length), Length)
> End Function
>
>
> of Left
>
> Public Shared Function Left(ByVal str As String, ByVal Length As Integer) As
> String
>       If (Length < 0) Then
>             Throw New
> ArgumentException(Utils.GetResourceString("Argument_GEZero1", New String()
> { "Length" }))
>       End If
>       If ((Length = 0) OrElse (str Is Nothing)) Then
>             Return ""
>       End If
>       If (Length >= str.Length) Then
>             Return str
>       End If
>       Return str.Substring(0, Length)
> End Function
>
>
> It does not directly produce trash IL but produces an overload calling heavy
> wrapper functions to standard .Net code (they at least always need to call
> the string.Substring method, just processing some useless extra code).
>
>
>

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
>> > And don't talk about the difficulty of VBers in understanding c# code
>> > and
>> > vice-versa just because VB people don't know how to write .Net app.
>>
>> Well, it's actually more often C# programmers not understanding VB's
>> function/class library than VBers not understanding the classes of the
>> .NET
>> Framework.
>
> Earlier you wrote:
>
> <quote>
> I am wondering where you got the perception that 'Mid' should not be
> used!
> </quote>
>
> Isn't what you wrote above a good enough reason?
>
> Yes, Mid is in .NET. It's in an assembly specifically created for VB
> support, however - hence its name. For the maximum readability for all
> .NET programmers, I'd suggest using the more commonly known string
> manipulation libraries (ie System.String and the System.Text and
> System.Text.RegularExpressions namespaces).

>
>> > Put it this way - it's entirely possible to use the Java-support
>> > redistributable and start using the Java API to manipulate strings too
>> > - but I wouldn't recommend that, either.
>>
>> I would not recommend it either, but what if one of the methods provided
>> there is missing in the .NET Framework?  In a J# application it would IMO
>> be
>> the natural choice to use the Java API method.  I am not sure where you
>> would draw the line between using language-specific features versus using
>> .NET Framework features.
>
> I would argue that if you're using J# you're in a world of pain to
> start with, to be honest - but I see your point. I would argue that J#
> isn't really a first class .NET language - it sits uncomfortably
> between two worlds.
>
>> Would you recommend to use '+' for string concatenation in VB.NET instead
>> of
>> '&' only for the reason other programming languages use '+' too?  Did you
>> refuse to use 'using' blocks in C# 1.* only because VB.NET didn't have an
>> equivalent syntactic construct?  Personally I don't think it makes much
>> sense to refuse using constructs, be it syntactic constructs or library
>> features, only for the reason of not having an equivalent in another
>> programming language.
>
> I think it depends on whether you count the VB functions as part of the
> language or not. The good thing about C# is that it's a relatively
> small actual language, relying on the framework itself for most of the
> functionality. As such, using all the features of the language doesn't
> make it particularly hard to read C# code from the point of view of
> users of other languages - there isn't that much to learn. If I'm
> reading VB.NET code which uses the VB functions extensively, however, I
> need to find out what each of them do.
>
>> There is no programming language which can claim to be "the only
>> programming
>> languge designed for the .NET Framework" except maybe ILASM.  Different
>> programming languages have different historical backgrounds and cultures,
>> and serve different purposes, which means that they are optimized for
>> certain scenarios.  Consequently they provide their own extensions to the
>> .NET Framework which make dealing with these scenarios easier.
>
> Sure. However, I would argue that if there are *lots* of those
> extensions, such as is the case with VB functions, and if the
> equivalent functionality is available in the "main" .NET framework
> (even if at a slight extra cost in terms of source code - terse doesn't
> mean readable), then use of those extensions should be actively
> discouraged.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too

>
> Some months ago I have talked to a good friend of mine about the solution
> taken for strings versus the solution taken for numeric types.  The
> 'String' class implements instance methods for certain operations which
> work on the object they are called on, such as 'String.Substring'.
> Mathematical operations however are implemented as shared methods of the
> 'Math' class. Why not make 'Cos' an instance method of the 'Double' class?
> This would certainly make the code more OO...

:-)

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
>> > Isn't what you wrote above a good enough reason?
>> >
>> > Yes, Mid is in .NET. It's in an assembly specifically created for VB
>> > support, however - hence its name. For the maximum readability for all
>> > .NET programmers, I'd suggest using the more commonly known string
>> > manipulation libraries (ie System.String and the System.Text and
>> > System.Text.RegularExpressions namespaces).
>>
>> Note that I don't recommend to blindly use VB's string manipuliation
>> functions instead of those in the .NET Framework's class library.  I
>> simply
>> recommend to use them when using them makes sense (features missing in
>> the
>> .NET Framework's class library) or if I consider them more high-level
>> than
>> the equivalent methods in the .NET Framework.
>
> However, you gave the impression that there's no reason not to use Mid.
> Here are my reasons:
>
> 1) It's not as OO as using a method on the String class

> > 5) Due to being less widely used than System.String, it's more likely
> >   to have bugs. This is a general point about the
> >   Microsoft.VisualBasic assembly, which isn't as widely used as the
> >   equivalents in the System.* assemblies. For instance, last time I
> >   looked hard at Asc and Chr (IIRC) there was distinctly odd behaviour
> >   in terms of which character encoding was actually used. (It depended
> >   on the first use within the app, I believe.)
>
> I didn't take a look at these particular functions.  Bugs can be everywhere.
> The 'Like' operator of VB.NET has been flawed in VB.NET 7.*, for example.
> It has been fixed in the current version.  However, this operator could have
> been widely used.  I do not think that the overall quality of
> "Microsoft.VisualBasic.dll" is lower than those of the .NET Framework class
> library.

>> > 2) There's a direct equivalent in String.Substring
>>
>> It's not a direct equivalent.  For example, I use 'Mid' if I want to make
>> use of its special 'Nothing' reference handling capability.
>
> Whereas I'd deal with that explicitly in code, as I believe that's
> clearer - I suspect that far from everyone knows that special case.
>
> (It's also not directly equivalent in terms of its "basing" of 1 rather
> than 0. Again, as the rest of the .NET framework is essentially
> 0-based, that seems like an inconsistency to me. Yes, it's consistent
> with VB6, but I'd hope to move towards a more .NET-centric code base
> and away from a VB6-centric code base.)
>
>> > 3) Users of other languages are more likely to understand Substring
>>
>> Well, IIRC there are more developers on the world who are able to
>> understand
>> 'Mid' than 'String.Substring', I assume.  Remember the popularity of
>> VB6 --
>> all .NET languages together do not have such a huge number of users.
>
> That will change, over time however. If you care more about readability
> for VB6 developers than for other .NET developers, that's your choice
> though. I think it's a reasonable objection for me to make at the same
> time.
>
>> > 4) The Microsoft.VisualBasic assembly may not be entirely implemented
>> >   in other CLR implementations, whereas System.String certainly will
>> >   be
>>
>> This may apply to any library.  I agree with you that it's more likely
>> that
>> 'System.String' is implemented, but I'd consider a VB.NET implementation
>> without support of "Microsoft.VisualBasic.dll" as an imcomplete solution.
>
> Well, it would still be a perfectly good ECMA library implementation.
> There's a reason why it's *Microsoft*.VisualBasic...
>
>> > 5) Due to being less widely used than System.String, it's more likely
>> >   to have bugs. This is a general point about the
>> >   Microsoft.VisualBasic assembly, which isn't as widely used as the
>> >   equivalents in the System.* assemblies. For instance, last time I
>> >   looked hard at Asc and Chr (IIRC) there was distinctly odd behaviour
>> >   in terms of which character encoding was actually used. (It depended
>> >   on the first use within the app, I believe.)
>>
>> I didn't take a look at these particular functions.  Bugs can be
>> everywhere.
>> The 'Like' operator of VB.NET has been flawed in VB.NET 7.*, for example.
>> It has been fixed in the current version.  However, this operator could
>> have
>> been widely used.  I do not think that the overall quality of
>> "Microsoft.VisualBasic.dll" is lower than those of the .NET Framework
>> class
>> library.
>
> Maybe I happened to be unlucky then. It makes sense to me, however,
> that the most used code tends to be the most reliable, because bugs are
> more likely to get found in the wild and then fixed.
>
>> > 6) It's less efficient as it's performing all the checks that Substring
>> >   performs before calling Substring.
>>
>> Well, sometimes I want this checks to be performed instead of putting
>> them
>> into my code.
>
> But they're already performed - in String.Substring! String.Substring
> will check whether or not you've given it an invalid length, but if you
> call Mid instead of Substring, the check gets made twice.
>
> Jon
>

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
>> What do you think there are more. MS Office + VB6 + VB.Net users or
>> developers who use Java or C or  C++ or  Javascript or  Java or another
>> program in this language category?
>
> We're not talking about people who are developing in MS Office or VB6
> though - we're talking about VB.NET users.
>
> As I said before:
> <quote>
> If you care more about readability for VB6 developers than for other
> .NET developers, that's your choice though. I think it's a reasonable
> objection for me to make at the same time.
> </quote>

> "Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
> >> What do you think there are more. MS Office + VB6 + VB.Net users or
> >> developers who use Java or C or  C++ or  Javascript or  Java or another
> >> program in this language category?
> >
> > We're not talking about people who are developing in MS Office or VB6
> > though - we're talking about VB.NET users.
> >
> > As I said before:
> > <quote>
> > If you care more about readability for VB6 developers than for other
> > .NET developers, that's your choice though. I think it's a reasonable
> > objection for me to make at the same time.
> > </quote>
>
> When writing code in VB.NET, readability for VB.NET developers has top
> priority.  If I'd like to write code readable for "all" .NET developers I'd
> choose ILASM :-).

> --
>
> Free .Net Reporting Tool - http://www.neodatatype.net
>
>
>

"Jon Skeet [C# MVP]" <sk***@pobox.com> schreef in bericht
news:MPG.1e74b2657cf127a898ced5@msnews.microsoft.com...
> Herfried K. Wagner [MVP] <hirf-spam-me-here@gmx.at> wrote:
>> "Brooke" <tbroo***@hotmail.com> schrieb:
>> >    I have used VB since it was released and I was actually a beta
>> > tester
>> > when it was called Thunder back around 1990.  I picked up VB.NET when
>> > it
>> > was first released, and developed a few applications using it, but
>> > quickly
>> > made the transition to C#. In  the last 5 years I have came to the
>> > conclusion that it is best to know the "Three C's".  The "Three C's"
>> > are
>> > C, C++, and C#.
>>
>> I do not see many similarities between C/C++ and C#.
>
> Not even in syntax? I'm perfectly well aware that the majority of
> differences between VB.NET and C# are just in syntactical - but coming
> from a C/C++/Java background I was able to pretty much immediately read
> a lot of C# code, whereas it takes me a lot longer to read VB.NET with
> its fairly significantly different syntax. It's a case of familiarity,
> that's all.
>
>> So learning C# won't make one more familiar with C/C++. While I think
>> that C/C++ still have a place in low-level development, I don't think
>> that a legacy syntax which is optimized for easy input through
>> ancient devices should have its place in modern, high-level
>> application development (user mode applications).
>
> Some of us like terse syntax for reasons other than easy input.
>
>> >If you plan on just writing code for Windows then either language will
>> >work. But if you want to be a develop for other operating systems (UNIX,
>> >LINUX, Embedded, Firmware, etc) then C# is the way to go.
>>
>> I have to disagree.  Both, the VB.NET and the C# compiler emit IL, so it
>> should not really matter which of the two programming languages one is
>> using
>> for platform independent development.
>
> I think Brooke's point here is that if you're going to work in Unix,
> Linux etc, you may well end up writing non-.NET code - in which case,
> C# is a better starting point as it's *closer* to C/C++/Java than
> VB.NET is.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too

"Fabio" wrote:

> "Carlos J. Quintero [VB MVP]" <carlosq@NOSPAMsogecable.com> ha scritto nel
> messaggio
>
> > I think that most VB6 programmers know that it VB6 uses COM (ActiveX), but
> > I always get stunned when some VB6 developer asks me what regsvr32.exe
> > is... ;-)
>
> I think you get the point :)
> They will still try to do a regsrv32 my.net.dll when the .Net app won't
> run...
> I see that they already do this with system windows dll and they shout "Here
> it is! The app doesn't work becouse the regsrv32 tell that gdi32.dll cannot
> be registered! I got gdi32.dll corrupted!"
> ;)
>
> --
>
> Free .Net Reporting Tool - http://www.neodatatype.net
>
>
>

"rmacias" <rmacias@newsgroup.nospam> escribió en el mensaje
news:9D7B4D2C-1E75-4AEB-B995-A0978A93CE28@microsoft.com...
> And it's always amuzing to see "VB6" code compiled with the VB.NET
> compiler.
> Like making Win32 API calls for functions that are already in the .NET
> Framework. :)

"Carlos J. Quintero [VB MVP]" wrote:

> Well, that's another story, and there are two explanations for it, IMO:
>
> - It can take a lot of time to know about all the classes and methods that
> there are in the class libraries of the .NET Framework. It is a matter of
> size, not a matter of not understanding the .NET concepts. The same happens
> when you use .NET 2.0: it can be that there are now a managed way of doing
> things that did not exist in .NET 1.x...
>
> - Also, if you are migrating from VB6 to VB.NET, rather than writting a new
> app from scratch, I suppose that the first priority of people is to get 0
> build errors, the second is to make the app actually work as before without
> bugs, then adjust the performance, etc. and the last one is to change the
> code to fit better in the .NET way. That would explain also that you see
> Win32 API calls when they are no longer required.
>
> --
>
> Best regards,
>
> Carlos J. Quintero
>
> MZ-Tools: Productivity add-ins for Visual Studio
> You can code, design and document much faster:
> http://www.mztools.com
>
>
> "rmacias" <rmacias@newsgroup.nospam> escribió en el mensaje
> news:9D7B4D2C-1E75-4AEB-B995-A0978A93CE28@microsoft.com...
> > And it's always amuzing to see "VB6" code compiled with the VB.NET
> > compiler.
> > Like making Win32 API calls for functions that are already in the .NET
> > Framework. :)
>
>
>