I must be missing something here, but when using the Localization and Messaging Editor, how do I search for a value or key? In Visual Studio in the Forms Designer, it's possible to right-click on a control and get the search key or value functionality. Where is this in the actual Localization Editor?



Thanks,

Derek

In truth we would probably still be moving over. Granted, this sealed the deal. The industry standard, especially in the area of development tools, is C# for a number of reasons, many of which not mentioned here just yet. But Microsoft internal teams are very strong proponents of C# over VB.NET. A fair portion of Visual Studio itself is written in C# (the remainder of it is written in C++), but it is geared for tools. Another major reason is that it will actually benefit the framework. If something is going to happen, it generally happens in C# first before VB.NET completely keeps up (some of your other comments elude to this point).







True, but you have to make it instead of exclusive. And to be honest, I have never gotten VB up to the level of C# even when trying. On the flip hand side, I quickly learned how to add warning exclusion tags as part of the compiler commands. I don't have the patience to try and make VB work to this extent for each project, and more importantly, and it is easy to forget and let some things slip few until you remember!







Never been an issue in this shop as the code is generally cleaner and easier to read since we have some hard and fast standards. But I get your point. Just FYI, if you look through Microsoft code you will see that this is a common standard...again, a preference and not a reason to choose one language over another.







Never done it, I just know that you can. Like I said, this is not something that I plan to deal with...soon anyway. I actually am going to mess with getting a C# app to run on Linux, to which there are a number of add-ons and compilers out there for this. I do not plan on moving to Linux, but there could be some long-term applications here, especially in the area of cost and some medical environments that demand certain platforms...so this gives us more long-term flexibility.

So, the next step: suggestions to a developer to move from VB to C#.



Two areas of interest: how to learn C# and how to migrate existing code from VB.NET to C#. I'm more interested in the second item, as I'm pretty familiar with C# (enough to get started), but I have no idea how I'd actually start using it in an existing project.

Well, this is easier said than done. It is my opinion that new development is a good place to start. So new classes, controls, etc. would be created in C# instead of VB. I do not recommend scrapping all of your VB code and starting totally over as that would be painful.



VB.NET is a good language and once it is compiled down, there are very few differences (though there are some). In our medical application, we have been writing all new development in C# for a while now and it grows really fast. We still have more VB.NET code than C#, but it is quickly evening out. Then once the release it 100% out the door, certified, released, etc. then we will start rewriting the base classes in C#.



Here is one thing that is important to keep in mind, it isn't bad to have VB.NET code within your application. For example, if you are moving an application over from Visual FoxPro to .NET...yeah, you would need to kill VFP quick as possible! However, VB.NET code is still .NET and a very powerful language, so it isn't like you are running on an antiquated platform.

Thanks Trent.

OK, so I decided to give C# a little test drive. I have a little research project I'm working on and I thought I'd just whip up a C# version.



Now the language isn't to hard, I'm picking that right up. However, I'm about to start drinking over how the editor is handling formatting.



In VB, when I type, I don't really even think about things like indenting, it just happens. When I type, it just puts where I want. So, If I type:







I get...





When I do something similar in C#...





I get...





and not...





* This is with Enable Virtual Space checked



Also, when I use code snippets, it doesn't fix the indentation! Which means I have to highlight the code and manually manage this. Very frustrating.



I've also read about how you can use Ctl K, Ctl D or Ctl K, Ctl F to format something...I'm not sure because neither do a damned thing.



So, what sort of settings might I use to enable the sort of smart formatting I'm used to with VB? I'm not really interested in having to type every single character exactly like I want it to appear. I'm building apps here, not ASCII art!

The editor is actually far better once you get used to it and get it setup.  I might recommend getting CodeRush from DevExpress.  It is horriblly irritating with VB.NET, but works very well with C#.  You can make the text editor look a lot better, change how regions looks, colors, etc.  And it makes moving to C# a lot easier.  You will have to turn off a lot of irritating junk that is enabled by default, like templates...they REALLY annoyed me.  But once you get it setup and configured to your liking, it is much better.

But before you haul off and get that, the settings you are talking about are standard .NET options.  Click on Tools -> Options and go to the Text Editor options for C#.

All of the frustrations you mentioned can be fixed here.  You might add a frustration or two while figuring it out also

LOL...the Ctrl K+D is something I use a lot...a whole lot.  The ONLY reason it will not work is if there is an error within the syntax...or you have your formatting setup to do just what you mentioned. 

I am not generally a big fan of too many tools, but CodeRush from DevExpress is really a nice Add-In for VS and makes formatting code, snippets, etc. really nice.  You can move methods around between regions, change declaration types, etc. with inline editor tools (if turned on) through this add-on.  Check it out, it really is nice for C#.  I will tell you this, however, if you leave it on for VB.NET....well...prepare for a few cuss words to pop out of your mouth.

I've done some more test driving, this time on another machine. All the weird stuff I previously posed about isn't happening here. So, I must have something weird setup on the first machine. In any case....



I'm liking it!



My brain still wants to put types after the variable when declaring them and I'm kind of bummed you can't declare/initialize in one step:











But mostly I'm liking it. Amazing how much some IDE niceties were causing pain (when it wasn't indenting correctly on first machine, especially when using code snippets).



I really like how constructors are handled, were you can identify other constructors to run:











I also found a cool site that compares VB to C# side by side. Very quick way to look up how to do something in the "other" language.



http://www.harding.edu/fmccown/vbnet_csharp_comparison.html



Thanks for the info and encouragement! I'm looking forward to the new 1.7 release and to doing more in C#!

Truthfully once I got used to it I liked C# better anyway on this. In truth it is actually more readable and still requires less typing because some of the editor features (i.e. the tab after "new" command, etc.).



Anyway, glad you are enjoying it...I have "drank the Kool-aid" so to speak. In fact, my first .NET was actually C# before we went into main development and moved to VB.NET...glad to be back!

Ohhh...tab after new...nice Yeah that makes it way more palatable. Thanks for the tip!

Yeah...and it will ALWAYS bring up the right object and include any required namespacing, etc. Me likey!

A year ago when I was getting into .NET I knew I should go with VB.NET since coming from a VFP environment the majority suggested VB.NET instead of C#, so far I love the whole .NET and specially when comparing the VS IDE with the VFP IDE I am more than happy I made the jump, still I am getting to know VB and will wait for a new small project to start working on C#, also I want to see all the new improvement to both languages coming in the new VS2010 before getting too deep .



Thanks both for sharing those experiences.

Edhy Rijo

I have to say I'm happy that I started with VB. Keeping the language sort of close limited what I was learning, which was a ton. There was all the OOP features, the .NET framework and the SF framework.



Now that I'm much more comfy with .NET OOP, and the frameworks, the jump to C# has been pretty easy. Now, when I go back to vb, there seem to be a lot of extra semi-colons!



The latest thing I'm not liking about C# (though I mostly like it better now) is the switch statement. This is somewhat analogous to the select/case statement but it is more limited. Here is something I do often in VB that is not possible in C#:







This is not possible in C#. The case elements must be resolvable at compile time. Thus they can use variables of strings of primitive types, strings or other primitive types. Oh well.

Unless you are dynamically changing the panel names, then this is totally possible. You would just entry it as a string:

Well, I'm not dynamically changing the panel names, I just really hate things like this as constants. So what you suggest is exactly what I was attempting to avoid. What does happen a lot during development is that I might change the name of the control (in this case the panel page) and in VB the automatic refactoring just handles it (the case statement is updated). With this (string contants) I'd have to remember to go fix it. Likely I wouldn't remember and I'd have to track down the bug. Hopefully they'll update this soon in C# (as they've stated that VB and C# will be equivalent languages, with features being introduced in both at the same time...not sure it applies to this but a guy can hope). Oh well. At this point I mostly prefer to work in C#, but I'm more convinced now that which language you choose is really just a preference (except for the stupid compile all the time thing with vb). Thanks for the info.

Well, when you are in the middle of development and changing names, OK. But if you go back in after this is working and start changing names then that is like playing Russian Roulette. The very same argument could be made for any single piece of code that has a string key, dictionary, etc. So while you may refactor your code while developing it you would also still recall this needs to be modified. But if you are changing "keys" after this code is already working, then you obviously would have a good reason, but this really should be a moot point. But that is just my point of view.