I recently started maintaining a .Net 1.1 project and would like to
convert it to .Net 3.5.
Any tips to share on reducing code by making use of new features?
As a first attempt, I would like to convert a bunch of static helper functions.
Update: The main reason why I am converting is to learn new features like static classes, LINQ etc. Just for my own use at least for now.
I would suggest starting by migrating to .NET 2.0 features, first.
My first step would be to slowly refactor to move all the collections to generic collections. This will help tremendously, and ease the migration into the .NET 3.5 features, especially with LINQ. It should also have a nice impact on your performance, since any collections of value types will perform better.
Be wary in this of converting HashTables to Dictionary<T,U>, since the behavior is different in some cases, but otherwise, ArrayList->List<T>, etc are easy, useful conversions.
After that, moving helpers to static classes, and potentially extension methods, would be a good next step to consider. This can make the code more readable.
You can use static classes (C# 2.0 feature) to rewrite old helper functions.
If you can swing it, the easiest way I've found to do this is using Visual Studio 2008 and ReSharper. ReSharper will show you, via some kindly visible notation, where you can improve your code. Then it will show you a keyboard shortcut Alt+Enter to "fix" your code.
ReSharper also has a feature called "Cleanup Code" that will will do some of the refactoring for you.
Why convert at all, .Net 1.1 is fully compatible with .Net 3.5, so you should not find any breaking changes when you migrate. If you need to refactor an area because it has problems or you wish to extend it somehow then I would consider migrating to use newer features, but otherwise why touch it and risk breaking it?
Edit As this is a learning excercise rather than changing production code I'd revise my views somewhat; this is probably a good way to learn new approaches. I'd certainly look at LINQ. In places where the old code was iterating through lists or manipulating XML or data from a DB see if you can re-write using LINQ instead.
If you want to start by "convert[ing] a bunch of static helper functions", then you'll want to check out extension methods.
It's likely that you can use them to make your code simpler and more readable.
Related
The generic Func<> and Action<> delegates from later versions of .NET are very appealing, and it's been demonstrated in many places that these can easily be recreated in code targeting .NET 2.0, such as here.
From the perspective of a library targeting .NET 2.0 however, which may be consumed by applications built against any higher version of .NET, how does this stack up. Is implementing this "compatibility layer" within the library absolutely a recipe for conflict (both in terms of private and public interface), or are there ways to make this work independent of the target framework that the consuming application builds against?
If this is a non-starter, would it be better to either:
A) Define an identical set of parametrized delegates with different names? or..
B) Stick strictly with .NET 2.0 convention, and define new delegate types as I need them?
The plain truth is that Func<> and Action<> are a good idea. They make your code much easier to read and they avoid a shocking amount of messy boilerplate delegate declarations. That's why you want to use them.
So you have this really appealing programming style you want to use, it's a standard technique that is now used almost universally instead of the old way, but you can't use it because you are targeting a legacy version of the framework. What should you do?
You have three choices:
Use the programming style that was in common use before the feature
Add the feature to your own code in spirit but with non-conflicting names
Add the feature to your own code with the "real" names but in your own namespace
Using the old programming style gives up all the benefits that we have come to appreciate from the feature. That's a big sacrifice. But maybe all your co-developers are used to this style of programming.
Using the feature with non-conflicting names seems sensible enough. People will be able to read the code and benefit from the features, but no-one will be confused that they appear to be something that they're not. When you are finally ready to upgrade, you'll have to patch up the names. Luckily Ctrl+R, Ctrl+R makes doing that very easy.
Using the feature with the same names as the standard feature means your code can target an older version but appear to be using newer features. Seems like a win/win. But this could cause confusion and you have to be careful that your types aren't exposed to other unknowing assemblies, possibly causing source level compilation problems. So you have to be careful and be perfectly clear about what is happening. But it can work effectively.
You have to pick whatever approach makes sense in your situation depending on your needs. There is no one right answer for everybody, only trade-offs.
I know there are some nice new features in C# 4.0 but I can't, for the life of me, think of a compelling reason for either upgrading existing projects or for switching to new projects.
I've seen some posts where people have said that if their hosting service didn't provide .Net 4 that they'd find another provider as .Net 4 was pinicle to their direction <?>.
Now my boss is trying to get me to agree to switch all our production environments to C# 4 and to do it now.
So the question is has anyone either began using, or converted a project to, C# 4 for a compelling reason? Was there a feature that you just had to have that would make your life so much easier?
There are some cool new features in C# 4.0:
Dynamic member lookup
Covariant and contravariant generic type parameters
Optional ref Keyword when using COM
Optional parameters and named arguments
Indexed properties
In his release blog post Scott Guthrie goes into detail about the features of .NET 4 in general. Another great resource is a white paper at http://www.asp.net/learn/whitepapers/aspnet4. However, I'd doubt you are going to need one / any of these new features right away. As Scott Hanselman blogged:
there's a lot of stuff that's new and
added in .NET 4, but not in that
"overwhelming-I-need-to-relearn-everything"
way.
Whether or not you should upgrade is therefore dependent on a variety of other factors. Some reasons that spring to mind:
Standardizing your development environment on a single platform VS2010 over VS2008.
Size of the .NET Framework is substantially reduced
Speed improvements if you are a Visual Studio Tools for Office developer
An open dialogue with your manager seems appropriate to understand his reasoning for the upgrade. I'd argue that because it's shiny isn't a compelling reason.
As a reference this dated Stack Overflow question "Why not upgrade to the latest .net framework" provides the inverse to your question.
Quite frankly System.Collections.Concurrent has made developing multi-threaded applications a breeze.
The new and improved System.Linq.Expressions makes writing dynamically compiled code seem like child's play.
The new named parameters feature means I can have big constructors and not get confused as to what each parameter is. Immutable objects are just that much easier.
Surprisingly not mentioned:
PLINQ
Task Parallel Library
Is your question specific to C# 4.0, or .NET 4.0?
In C# 4.0 there are only a couple of really nice new features. Covariance/contravariance is not useful all the time, but when you run into a need for it, it can really save a lot of pain. Optional method parameters can reduce a lot of ugly method overrides, and make certain method calls a lot cleaner. If you're using COM or IronPython or any of a few similar frameworks, the dynamic keyword can also be a real lifesaver.
.NET 4.0 in general has a ton of really interesting features across a variety of frameworks. Foreign Key support in Linq to Entities, for example, is making life a lot easier for us. A lot of people are really excited about POCO support. They also added support for some of the LINQ methods (e.g. Distinct) that were previously missing from the Entity Framework.
So it will really all boil down to which frameworks you're using and how you're using them, and how expensive it will be for you to make the switch.
First, what is compelling to me may mean nothing to you. Having said that, I would upgrade Visual Studio if budget allows. In fact, personally I think there is a huge career risk in staying with a company that doesn't keep your tools up to date. You will fall behind in your knowledge of the field without access to the latest tools.
As for converting all your projects just to convert them it seems like folly to me. Putting aside all the extra work distribution (and upgrading the machines to have .NET 4), you have to consider the chance that you will have something go wrong. (And if you are like me some things must be called from 3rd party programs using .NET 3.5 making them unable to convert.)
My first rule would be that nothing is converted unless you are working on it anyway. But I would seriously look to convert anything that could use improvement from either parallel code, or COM interop.
I do have a compelling project that was converted. I had a long running web method being called. In the version that exists now, I return from the method without knowing the results. Instead I gave the user a way to check later. By moving to a parallel foreach loop this works much better and I can let the user know if there were any errors.
The same project is also being converted to use RIA services which have greatly improved and reducing the amount of my own code.
I upgraded for the same reason everyone else did.
...so I can put it on my resume :)
If you're starting a new project today, it's probably best to start it on 4.0, since down the road you will have to migrate it at some point anyways (assuming it stays around long enough, older versions of .net will simply stop being supported).
C# 4 implies other things.. depending on your project... WCF 4, WPF 4, ASP.NET 4, MVC 2, Entity Framework 2, etc.. So don't just look at C# as the reason to change, you also have to look at the whole stack. If there's still nothing compelling, then staying where you're at is probably a wise choice.
If you're doing WPF / Silverlight, I would definitely recommend upgrading to Visual Studio 2010 (I know, you can write .NET 4.0 code without an IDE, but that's an edge case if ever there were one).
The multi monitor support is nifty but buggy. I spend a lot of time trying to get windows to refresh.
In terms of language, the COM interop (as #Gvs mentioned) is also vastly improved with the dynamic datatype and optional parameters.
UPDATE: Multiple monitor support is pretty rock solid with VS 2010 SP1.
If you can get your boss to pop for the $10,000+ Visual Studio Ultimate Edition, IntelliTrace is a compelling reason to upgrade your environment and justification enough the for investment.
COM integration is much easier with the dynamic datatype, and optional parameters.
For me there are two things:
optional arguments -- because I am sick of polluting classes with X versions of the same method (overloading)
dynamic keyword -- because the expressiveness of generics in C# is a joke, this way I can at least "write what I mean" without hoops, of course with execution speed penalty
The more compact the code (i.e. if you express the idea without addition "oh, how to avoid limitation Y of the language"), the better, because the code is much easier to maintain and it is harder to make a stupid (or worse) mistake.
There are no compelling stability or security reasons to switch. Shouldn't that be your boss's concern?
What's the fastest way to convert an existing Vb6.0 win-based application into a c# win-based?
The core language is so different, that I would have to say start from scratch, and copy only the complicated code bits. If you start from scratch you won't have to deal with all the VB6 problems, while utilizing all the C# power.
VB6 has no real classes or OOP, which makes very different from C#. Also, there is very little control on the event manager (SubClassing).
So, start from zero, copy the UI layout, and think about how would I implement this in C# in the first place, it will make your life easier.
I think the fastest would be to convert it to VB.net. Check the following question for this answer
VB6 to VB.net conversion
ans then converting it to c#. But I feel converting manually will be the better option as you can re engineer the application and may be make it simpler.
Converting the code from Visual Basic 6 to C# should best be done using an automated migration tool, like ArtinSoft's Visual Basic Upgrade Companion, which supports migration to C#.There are several reasons for this suggestion, aside from my experience with the tool.
First, even if you migrate from VB6 to VB.NET there are several language specific features in VB.NET that will not translate directly to C#. So even if you're using a VB.NET to C# converter you'll have to handle these special cases (or find a tool that handles them for you). These can include optional parameters, AddressOf functions, Visual Basic Compiler assisted operations, like Information.Err(), and Unstructure Error Handling to Structured Error Handling using Try / Catch statements. Another thing to consider is that the VB.NET compiler is limited to showing only 100 compilation errors, and compilation errors can be quite common when migrating. When moving to C#'s the compiler and other code analysis tools like ReSharper can give you a better picture of the challenge ahead, and help you detect common compilation error patterns.
Second, by migrating directly to the target language you can focus on using the features available for that language from the start, no intermediate steps. Otherwise, you'll basically end up doing two migrations when you could have focused on just one.
Third, as renick stated even though migration tools can produce hundreds or thousands of issues, most of these have relatively easy solutions. Some of them can be fixed using a find & replace function. Commercial solutions have the added advantage that they support the migration of third-party UI controls to .NET equivalents.
Also a migration can be much faster than a rewrite, you still have to write code but only for the areas where there are issues.
Granted there are applications for which a migration is not an option, but for those that fit the use case for a migration, it's a very effective means of switching platforms. You shouldn't discount the option right off the bat.
Total rewrite. MS has some migration assistance, but I believe it's VB.Net only. But why look at porting, surely you'd be better off now rewriting the app, and just interop if you have any legacy parts that you need to keep alive. And only migrate the best bits. Use this as a chance to truly improve the application.
If you need it quickly; then don't go hand cranking it - you'll miss stuff out and tear your hair out!
I investigated this product a couple of years back and I felt this product was the best. it converts from VB6 to C#. They have a free trial too.
Try ArtInSoft. This company will migrate your VB 6 code directly to C#.
I am upgrading a Windows Client application that was earlier .NET 1.1. The previous developer handwrote many solutions that can be done automatically with the newer versions of .NET. Since I am relatively fresh to .NET and do not have the complete overview of the features I am asking here.
What is the most notable classes and syntax features provided in later .NET versions that is likely to swap out handwritten code with features from the library?
Biggest changes off the top of my head:
Use generic collections instead of ArrayList, Hashtable etc.
For C# 3.5, use LINQ instead of manually filtering/projecting
Use generic delegates instead of having to declare your own all the time
Use anonymous methods instead of creating a one line method used to create a delegate in one place
Use BackgroundWorker for WinForms background tasks
Generics is the most wide-reaching change in my view.
Personally, I would leave any 1.1 code that works fine when compiled with 2.0/3.5. Unless you have the time, anything you rewrite you'll have to test again, and you still may introduce new bugs that your testing can't find.
Things that I'd look to use for future versions though, would be generics and LINQ. Generics with .NET 2, and LINQ with .NET 3.5.
LINQ was a big leap. Might be possible to use that in some places (e.g. XML code). Also, generics may reduce the need for some classes.
Also be aware of and test for possible impact of breaking changes between the versions of the framework. A google search should reveal the top issues.
I have a VB5 (non .net) project that I would like to upgrade to a c# project. Has anyone have any suggestions on methods or free tools that are avalible to help me with this.
Thanks
Brad
You are better off with a straight rewrite.
What I would suggest is first convert the project to VB6. It'll be much easier to go forward from there. There are a number of tools to help you do this. There is VBMigration Partner and there is vbto. I've not tried either so YMMV.
If costs are a constraint you could try this: there is a wizard in Visual Studio that will attempt to upgrade VB6 to VB.NET. It's not 100% accurate and you WILL have to write code for things VB.NET does not support such as control arrays, etc. Once the code is in VB.NET you can use a tool like SharpDevelop to convert the VB.NET to C#. It'll be a bit tedious but i suppose all roads, no matter how convoluted, lead to Rome.
In case you were able to migrate it to VB6 you can use the code advisor to see how you can fix your project to be compatible to vb.net, then you can migrate to vb.net, in case it success, you can use this tool to convert it to c# or the Reflector.
I give it a chance of 1x10^(-100)% to work.
Good luck.
If you're about to convert VB5 to .NET (whether it's C# or even VB.NET) the fastest way is to restart from 0 your implementation so you can take full advantage of .NET Framework classes. I don't know if there are tools to do this conversion automatically.
It's rarely a good idea to do a strict conversion from one language to another, particularly when they are as different as VB5 and C#.
Theoretically, you could convert VB5 to VB6 and then VB6 to VB.NET and then VB.NET to C#, but that just sounds crazy to me as I type it.
C# is so much more powerful than VB5 that you wouldn't want to covert the code anyway. After all, it likely has a poor design due to VB's weak OO capabilities.
I'd instead recommend re-implementing the functionality you need in C# (or whatever other language you want to use).
I know there exist a conversion tools, not sure though if there are some for vb5.
However, i'd recommend performing a redesign of the project, taking advantage of the .net features unavaiable in vb5. Specially it would be good redesigning for a OO language.
Migrating VB5 to C# just to have .NET is never a good reason. I would prefer to have a good look at the assumptions and design decisions I made in the VB5 version, rethink them all, add new ideas, sketch the UI and improve it to look closer to a modern one.
Then it's a new project, I wouldn't even call it a rewrite, because so much would have changed.
I've migrated a small 1-tier VB6 application to C# and I will never do it again.
There are applications out there that do a rather good job migrating from VB6 to VB.Net.
//Magnus
I’ve done it in the past but don’t recommend it. Getting the project to work correctly after the ‘auto-migration’ was not worth the effort. I ended up rewriting the program and was better off because of it.
Having done this myself I talk about the issues involved here.
Basically as ocdecio you are looking at least a partial rewrite. You will likely need to refactor your forms to move as much code out of them as possible. You will also need to refactor any VB6 specific features to work behind a interface that you can reimplement in .NET. Notably the Graphics commands, and the Printer functions. Migration Tools are usually worthless for any serious project.