I am writing public .NET class library version for our online REST service and I can't decide which version of .NET to choose.
I would like to use .NET 4.0 version but such compiled class library can't be used in .NET 2.0 version?
Maybe there is statistic how many developers use .Net 2.0 version?
There's little reason not to use the latest version of the framework. Not only do you get all the latest features and whistles that speed development time, but you also get to take advantage of all the bug fixes and improvements that Microsoft has done under the hood.
The only advantage of targeting earlier versions of the framework is in a vain hope that the user won't have to download and install anything in order to use your app. But that's far from foolproof, and mostly in vain. Remember that Windows is not a .NET Framework delivery channel and you can't reliably assume that the user will have any version of the .NET Framework installed. Even if you insisted on counting on it being bundled with Windows (which you shouldn't), lots of users still haven't upgraded from Windows XP. Even if you counted on it being pushed out over Windows Update, there are significant numbers of users who either don't use Windows Update, don't use Windows Update very often, or who live out in remote areas with poor/slow Internet access and can't download all of those updates.
The moral of the story is that you're going to have to provide the appropriate version of the .NET Framework with your application anyway. And the .NET 4.0 runtime is actually significantly smaller than the previous versions, so there's little reason to target them. The team has worked really hard on that, and their efforts have really paid off. Even better, as atornblad notes, most apps can target the Client Profile version of the framework which trims out some infrequently used pieces and slims things down another ~16%.
Additionally, I strongly recommend using a setup application that handles installing the required framework for the user automatically and seamlessly. Visual Studio comes with built-in support for creating setup applications, or you could use a third-party installer utility like Inno Setup. That makes using the latest version a no-brainer.
Everyone else seems to be recommending using the latest version, so I'll buck the trend and suggest 2.0 if you don't actually need any features from later versions... if this really is a client library and you have no control over and little idea about who is going to use it.
It really does depend on who your users are likely to be, which in turn depends on what the REST service is. If it's some sort of social media thing, then I'd say it's more likely that your clients will be in environments where they can use .NET 4. If it's something which might well be used by financial institutions or other big businesses, they may well not have the option of using .NET 4, so you should consider earlier versions. This is the approach we've taken for Noda Time where we believe the library will be useful in a wide variety of situations, and we can't predict the client requirements.
Of course, if you know all your clients and know they will all be able to use .NET 4, then go with that.
The big downsides of sticking to .NET 2.0 are that you won't be able to use LINQ internally (unless you use LINQBridge or something similar, which adds another dependency for your library) and you won't be able to (cleanly) provide extension methods. If you can usefully expose more features to the client if you use a later version, you may want to provide multiple versions of the library - but obviously that's a maintenance headache.
Another consideration is whether you ought to provide a Silverlight version - which again depends on what sort of service you're providing and what sort of users you're expecting.
If you are making a REST service you should probably use 4.0.
The only time you need to consider using a legacy version is if another project should reference your compiled dll. The REST service is exposed using HTTP over internet and the client will not use the .dll directly. Or did I understand the question wrong?
It's almost always is a good idea to use the latest version, cause MS provides a lot of bugfixes and innovations in those.
If, in your system, there is a limitation for 2.0, I'm afraid you need to use that one, cause you need to "make the stuff work".
For versions approx destribution, can look on this SO answer (but it till 3.5 version)
When you do not create your library to fit in an existing legacy environment you should always use the most up to date releases.
If I don't understand you wrongly you're looking to create a .NET-based client library to work with some REST service(s) made by you too.
Perhaps you want to provide a client library which can be consumed by 2.0, 3.5 and 4.0 applications, and this is absolutely possible, and using best features of each framework version.
Maybe there're more approaches, but I'd like to suggest you three of them:
Conditional compilation-based approach. You can implement your classes using a common feature set found in legacy and newer framework versions, but take advantage of useful features present in each version. This is possible using conditional compilation and compilation symbols, since you can define specific code to be compiled depending on target framework version (check this question: Is it possible to conditionally compile to .NET Framework version?).
Symbolic links in Visual Studio 2010-based approach. You can choose to use a common feature set, keeping in mind that this is going to be the one found in the oldest version. That is you can create a project which compiles in 2.0, and others for newer versions, adding all compilable files and embedded resources as symbolic links in these Visual Studio projects. This is going to produce an assembly for any of supported framework versions. You can mix conditional compilation-based approach with this one, and you can get a great way of delivering your public assembly in various framework versions in a very reliable and easy-to-maintain way. Note whenever you add a new compiled file or resource to a project, you need to create the corresponding symbolic links for it for your other projects. Check this MSDN article if you want to learn more about linked files: http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx.
Version specific, optimized assemblies. Maybe the most time-consuming approach. It requires more effort, but if your REST service isn't a giant one, you can have room to develop an specific assembly for each framework version, and take advantage of best features and approaches of all of them.
My opinion
In my opinion, I'd take #2 approach, because it has the best of #1 and #3. If you get used with it, it's easy to maintain and it's all about discipline, and you'll have a good range of choices for your client developers.
I'd compromise and use the oldest framework that provides you (the library's author) the most bang for your buck. It's compromise that lets you develop the fastest and exposes your library to the more users. For me, that usually means 3.5 because I tend to use LINQ extensively.
It should be trivial to provide both 2.0 and 4.0 binaries, as long as you're not using any of the 4.0 specific dlls.
You can also publish your client library source code - .NET binaries are already so easy to decompile that you're not leaking out anything valuable this way.
Related
I joined a place where they have an application that is written using VS2005 and .NEt 2.0 Desktop application. Reason why they don't want to move is they are not feeling comfortable and they feel it will break a lot. I feel the opposite. There may be lot Security fixes .NET latest version it was not applied to old version. Is there a Security issue here?
I know there are breaking changes but it will take one or two months to sort it out.
Did any one faced same problem. What are the risk here not to upgrade to the latest version.
I understand .NET 4.5 has whole lot of new functionality it will improve programming experience. Since it is a maintenance application is there a benefit of upgrading to the latest version.
NET 2.0 should be secure. The mainstream support for .NET 2.0 has ended on 4/12/2011 as noted here. Right now MS offers only extended support till 4/12/2016, which includes security updates as you can see in the table at: http://support.microsoft.com/lifecycle/default.aspx?LN=en-us&x=12&y=15.
The first thing you can do is change the target platform and test it. I'd be very surprised if it didn't compile right away.
The .NET framework maintains a lot of legacy code to prevent upgrades such as this from breaking, so compilation and run are both unlikely to break, albeit you may get lots of warnings due to Obsolete implementations.
As for the security consideration, consider that one major aspect of the .NET Framework is the reverse compatibility, which means that your application is already running against the newer runtime anyway, depending on the client environment.
As for improvements to the coding environment, note that the newer coding practices require changes to the code, and thus won't simply automatically be taken advantage of, but may offer a way to go back and streamline (both in terms of performance and code readability) older sections of the code. In short, upgrading offers the chance to integrate these newer functionalities, it doesn't include them automatically.
Finally, as mentioned, support for .NET 2.0 has ended, meaning any security flaws discovered won't be patched, making your 2.0 app potentially less secure than a 4.5 one, which gets regular security updates. This is, again, subject to the client runtime, but will prevent a client from running against the possibly insecure 2.0 Runtime.
I researched the use of a condition framework to verify data instead of
if(cond) throw new SomeException();
SomeFramework.MakeSure(cond);
In the end my choice is to use either the CodeContract or CuttingEdge.Conditions frameworks.
I can not decide which framework to use. I can tell you that what I don't like about the 'CodeContract' framework is that you have to install the extra msi in order to use it and the options you need to choose; not that its bad, but it feels not natural. (And of course its still under MS research.)
What do you think?
The CodeContracts framework is part of .NET 4. So you can write code against it without having to install anything, it's just that without the rewriter component the code contracts won't have any effect at runtime. I take this inclusion in the framework as a sign that Microsoft intends to integrate code contracts more in future.
According to the stats on the CuttingEdge.Conditions CodePlex page, it's only been downloaded 4,189 times. There are some nice things about the syntax, but unless there is something specifically supported by CuttingEdge.Conditions and not by CodeContracts, you might as well stick with the version that's part of .NET.
The key features of code contracts, as far as I am concerned, are as follows:
You can set up code contracts on interfaces, to specify the expected behaviour of types implementing those interfaces.
Code contracts are inherited.
I haven't tried CuttingEdge.Conditions, but it's not obvious that it supports these two features (whereas CodeContracts does).
The main difference is that Code Contracts includes a static checker. This means your contracts will be checked at compile time for correctness.
Also, as long as you are building for .NET 4, your users don't need to install anything. The rewriter works at compile time and the rest of CC is part of .NET.
Edit: I recommend people use https://github.com/adamralph/liteguard
CuttingEdge.Conditions has been forked to become just Conditions. The original author was no longer maintaining nor uses the project: https://conditions.codeplex.com/workitem/20064
CodeContracts are not implemented in Mono. There was a GSOC project but it didn't end up with a complete solution so Conditions is your only choice if targeting Xamarin.iOS/Xamarin.Android/Xamarin.Mac platforms or just mono in general.
The library is now a portable class library and cross-platform support by default is in:
https://github.com/ghuntley/Conditions and https://www.nuget.org/packages/Conditions/
Migation of a VB6 application to .NET platform is almost like a rewrite, no matter it is VB.NET or C#. Do you think it will require more effort to do it in Java platform, when compared to .NET platform, since it is a rewrite anyway? Please share your thoughts!
No offence, but you are wrong. Porting to .Net is usually far easier than a rewrite.
Here's the official advice from Microsoft UK:
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
From a blog post by a Microsoft guy who consulted on rewrites:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large
I recommend the following two steps in this order.
Write down the reasons for migration or rewriting. What benefits will it bring? The benefits might be just to keep the development team happy - that might even be a good enough reason, I don't know. Make sure you know, and your managers/users agree.
Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. It may be rewriting, but go into it with your eyes open.
In answer to your actual question: would a complete rewrite be easier in .Net or Java? That mainly depends on which one your team knows best. It also depends a little on whether the application interacts with COM, just like SLaks says.
The effort of rewriting a VB6 app is more than just a question of which language you're targetting. VB apps often rely on COM objects and certain VB-specific library methods which may not have equivalents in Java - but may have some portability in .NET.
Unless you are willing to abandon all of the dependences of the project, you may find .NET an easier target to re-write for, especially if you need to preserve some of the behavior of the existing application which derives from libraries or other dependencies.
Another consideration will be which platform your team is most familiar with - if you have a lot of Java expertise but little or no .NET expertise, then perhaps Java is a good choice for you.
There are tools available that will migrate from VB6 to VB .Net, including the one built into Visual Studio. This tool migrates VB6 to C#. Whatever tool you use, you will still need to do a lot of manual work on the code that the tool outputs, however this is likely to be less work than a complete java rewrite.
Depending on your existing application's architecture, and how well the code is structured, you may decide it is better to completely re-design and rewrite it anyway, in which case there may not be much to choose between .Net and java.
It is important to reduce not just the total effort during migration but also the cost of maintenance after migration. Many factors drive TCO, but all things being equal I think the .NET tools, community, framework, and C# language meet or beat Java in terms of developer productivity, operational managability, and performance -- assuming your are targeting windows OS.
I do not think ease of keeping COM should be the deciding factor either. In fact, I think migrating VB6 to .NET but keeping COM when you do not have to defeats a critical purpose of doing a VB6 migration in the first place: to reduce development costs and risks by moving to a well-supported and viable platform. I will tell you why:
Most of the popular COM libraries and
controls that were used with VB6 have
not evolved in many years; many of
the smaller vendors have disappeared
or if they are still supporting their
wares, they now also offer new and
improved .NET versions.
Living with old COM after migration
means living with additional
complexity in terms of debugging,
builds, and deployment. Also beware that COM
components do not really "speak" .NET
(i.e they do not use .NET types and
conventions) so their use with .NET usually
results in added complexity in the
coding and design.
There still are a few
hold-outs and exceptions to this rule
and a .NET replacement is not the
always best choice, but in general,
migration teams will be able to find
at least one .NET replacement option
for almost every COM component they use.
Taking the time to thoughtfully
evaluate, select and upgrade to one
of those options will pay off after
the migration.
You will not want to interop anything
that is VB6 you plan to migrate. Interoping your own code will lead to a longer,
complex transition and typically
requires back-tracking and
reworking/retesting already migrated
codes. Clearly this is not the most
efficient and understandable upgrade
path.
One more point about having to do "a lot of manual work on the output". The Great Migrations product is a new, programmable migration tool. It is designed to help migration teams incrementally improve the quality of generated code and thus reduce the manual work required to complete the migration project. This includes making the translations more correct, dealing with complex multi-VBP migrations, and also automating the restructuring of VB6/COM code to use .NET components. These features are particularly helpful if the VB6 codebase is very large, changing frequently, and being significantly re-engineered and cleaned up during the migration. This is an agile migration methodology we call the tool-assisted rewrite.
Disclaimer: I work for Great Migrations.
If the application uses COM, it will be far easier to rewrite it in .Net than in Java. Otherwise, it will probably be somewhat easier to port to .Net.
For a more specific answer, please provide more details about your application.
You could also use Jabaco it is a Java Bytecode compiler and it has it's own IDE and syntax very similar to VB6 (nearly the same).
You can find more information at:
http://www.jabaco.org/
http://www.jabaco.org/board/
use a migration tool, like ArtInSoft to just migrate it to .NET.
You can migrate the VB 6 application using the in built VS migration to VB.Net. Try to see if that helps you. If you are looking at migrating VB 6 to C# then I would also recommend what ScaleOvenStove user has recommended.
I have just started working on a reusable library. This library is going to be pretty big and since it involves communicating with external devices over various communication media (such as RS232, TCP/IP, Radio etc), I am thinking about providing support of performing operations that involves communication, asynchronously.
I have read the .NET guidelines, various articles etc. Many sources refer to future developments in .NET 4.0 regarding asynchronous programming.
I have 2 options:
Forget .NET 4.0 and implement the library using best pattern/method available today.
Read, learn and play with .NET 4.0 so that my library gets benefit of up-to-date language and framework facilities.
Considering that release timeline of my library goes till mid next year (2010) and quality of library matters more than release date (Yes, I am lucky), what option would you recommend?
If you suggest option-1, is there anything I can do to make my library ".NET 4.0 friendly" (easy changes in future to use advanced parallel features)?
If you suggest option-2, how stable the current parallel features in .NET 4.0 or how much rework you expect because of working on beta platform?
You say that your library is due to be released next year - do you know what version your customers are likely to be running? .NET 4.0 will still be quite new at that point. If your customers aren't willing to run it, that rules it out.
If you can use .NET 4.0, I'd say that the PFX bits are likely to lead to much cleaner code. It's really nice. Things are still changing though... I know that there will be some changes between beta 1 and beta 2. My guess is that beta 2 will be a lot closer to the final bits though.
EDIT: Okay, so if you can use .NET 4.0, I would do so. I have a lot of faith in the PFX team, and it's a very nicely designed library. One difficulty is that while there are loads of blog posts and some documentation, there aren't "real world applications" books yet - and you'll find that some of the blog posts will be slightly out of date already. I suggest you start with the PFX team blog as well as the documentation in beta 1. Just be aware that things will change...
I would clearly go with option 1 - write your library using the idioms that work now.
As for making future transitions easy, make sure you design the public interfaces well. Use the same principles as always, i.e. keep them clean and don't expose internal implementation details.
Regarding your first point, all 3.5 or even 2.0 assemblies can be used from .NET 4.0. As of 2.0, .NET is fully backwards compatible (till 2.0 anyway).
Here's the deal: I'm in the process of planning a mid-sized business application that absolutely must support Win2k. AFAIK, official .NET support for Win2k was scrapped a while ago (IIRC, it stopped at version 2.0).
Now, I already wrote (ages ago) libraries in C++ that allow me to accomplish the end result (i.e., finish this project) just as quickly as if I was writing this application with the help of the .NET Framework -- so .NET's RAD "advantage" is almost negated.
I'm sure a lot of people here deal with business applications that need to support old OS's. So, given my library situation, what advantage(s) are there for me in using .NET over native C++ and vice versa? I'm just not sure which of the two is right for the job -- because it seems that I could use either. Then again, there's that framework support issue to deal with...
I will gladly add more information, if required.
The last .NET version that runs under Windows 2000 is .NET 2.0 SP2. It does include the features required by System.Core.dll (that is part of .NET 3.5).
The answer is YES, you can use .NET 3.5 SP1 under Windows 2000 if you're not going to use .NET 3.0 libraries (WCF, WF, WPF, CardSpace). But you have LINQ, LINQ to XML, LINQ to SQL.
The only thing you need to do is to deploy three core .NET 3.5 SP1 files:
System.Core.dll
System.Xml.Linq.dll (LINQ to XML)
System.Data.Linq.dll (LINQ to SQL)
Disadvantages of this method (read carefully):
Not sure whether it's permitted or forbidden by the EULA (end-user license agreement)
This scenario is not supported by Microsoft.
I'd look to see if Mono (mono-project) works for you. i.e. runs on win2k - if it does it would allow you to port your app to MS .NET and later OS versions should the need arise later in the project. Any .NET is going to be easier than C++ IMHO :)
The biggest difference is that you are (or your boss is) more likely to find developers to maintain your .NET code after you move on to other things.
C++ has the advantage of giving you job stability - although that might not be what you want. :)
I think, given your situtation, it boils down to what you feel more comfortable in writing. If C++ is a comfortable language for you, do that. It will help get you into the code and make it easier to finish.
I would also take care to keep the future in mind. If the Win2K requirement drops that might require you to rewrite if you wrote in C++. It might not. Just keep it in mind while you decide how to proceed.
You can develop with .NET but set the compiler options to target the .NET 2.0 framework. If the OS gets upgraded in the near (or far) future, you can upgrade your program to target the 3.5 framework. I would go this route as it allows for easier future maintenance by others.
Have you considered Delphi? You can download Turbo Delphi for free and it you can easily write code targeting Windows 2000. With Delphi, you'll get an excellent RAD (arguably better than anything you'll find in C++...unless you use C++ Builder).
Delphi creates native code, and has no runtime requirements.
Of course, the downside is if that you don't know Delphi (which is Object-Pascal) you have to familiarize yourself with a new language. However, if you know C++, you'll feel at home in Delphi in no time.