Is .net 2.0 an overhaul of .net 1.1? in other words if you are let's say following a book written for .net 1.1 (ASP.NET 1.1/C# 1.1) then do you have to "unlearn" something which is totally different in advance versions such as 2.0 3.5?
I am reading a book by Richter "Applied .net framework programming", that's why I wanted to know some points from experienced folks.
For the most part, what you would learn in a .NET 1.1 book applies to .NET 2 (and .NET 3.5/4). The one major exception, and the reason I never recommend anybody start with .NET 1.1 now, is generics.
The handling of collections was made dramatically better in .NET 2+. Prior to .NET 2, collections were all not type safe (ie: ArrayList). After .NET 2, we had the ability to use type-safe, generic based collection classes (List<T>, so you can do List<int>, etc).
This dramatically changes how people write code (or should!). I'd strongly recommend starting with a .NET 2+ book to learn today. Learning from a .NET 1.1 book will teach you bad habits, because you'll be learning collections that have almost no purpose in current .NET code.
That being said, .NET 4 is now released, and there's no real reason not to start there, if you can...
It is a significant change from 1.1 to 2.0. 2.0 introduced generics as well as new classes to deprecate and replace functionality offered by older 1.1 classes. It would still be good to know 1.1 code and objects, because you'll still see them in the wild, but I wouldn't base my beginner's knowledge upon a 1.1 text. Keep in mind, .NET is now up to 4.0, so even starting at 2.0 would be behind the times, but not nearly as bad as 1.1.
I would find a resource that at least covered C# 3.0/.NET 3.5, and sprinkle in knowledge of 1.1 as needed.
There are a few libraries that were 'overhauled' and some that were deprecated. We are at .net 4.0 by the way.
Here is a list of changes that were blogged on MSDN
http://blogs.msdn.com/b/brada/archive/2005/11/14/breaking-changes-between-net-framework-1-1-and-2-0.aspx
.NET 2.0 introduced a lot of new functionality. Specifically for ASP.NET the inclusion of datasource controls, the provider model, sitemaps, ... were introduced.
If you want to learn ASP.NET now or will buy a book I suggest you rather look for something about 2.0 or 4.0. Preferably the latter if possible.
Since 3.5 Ajax and several related controls for that got introduced with the framework, you could add an extension to 2.0 if needed. That's a major improvement to the whole ASP.NET framework as well so be sure to check that out as well.
It's not a complete "overhaul" but there are significant changes. Much of what you learn will carry over but why not just learn the latest version?
In general, .NET 2.0 is a superset of what is implemented in .NET 1.1. A few functions in 1.1 may have changed in 2.0, and some classes may have been deprecated, but on the whole you shouldn't have to "unlearn" anything. You will have a lot of new stuff available to learn, but you can write code that compiles to the 2.0 framework using your existing 1.1 knowledge and skill set.
For the most part MS did not make that many breaking changes between 1.x and 2.0. 3.0 and 3.5 are library released that just extended the 2.0 runtime with things like LINQ, WCF, WPF and WF. 4.0 has many breaking changes does to a reorganization to support the Client Profile (the libraries avilable on a cutdown client like the Windows Phone) vs the full profile (what you would run on a server).
#Zai based on your comment I have always found the Programming C# series a great survey of what exists within C# and the .NET Framework.
If you have a 1.1 book just burn it. Why bother, go read the MSDN and learn your generics, extensions, and lambdas up front. Sorry don't burn it, recycle it, cut the binding off and put it in a printer tray.
Microsoft has always been releasing platforms which are backward compatible. Given the fact that we are already on 4.0 version of the framework, I would suggest starting with 2.0 framework as most of the books would cover the basics which almost remain the same. The exclusions would be things like Generics as mentioned above.
I wouldn't suggest directly jumping onto 3.5 or 4.0 framework as there will a learning curve involved in getting to know the specifics related to those framework.
.NET Framework 1.1 is almost seven years old. I recommend you discard your .NET 1.1 book, even though it's from a great author. Don't bother learning .NET 1.1 at all.
Even to the extent that there are parts of .NET 1.1 that have not changed in all this time, the way things aer done in .NET has changed dramatically in the intervening years. Generics, LINQ, WCF and many more things make the entire mindset very different between .NET 1.1 and .NET 4.0. A book written for .NET 1.1 will be teaching you to think the wrong way about things, and you'll be very surprised when you find other developers asking you "why did you do it that 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.
Are there a public set of specifications for a given .NET release?
In our product development, we have used large parts of Java EE since J2EE 1.3 for some of the products. Even though the platform is large, it has always been easy to find what is included in a given release. Both Java SE and Java EE are a set of specifications. Several vendors offers implementations of the specifications. This works remarkably good.
I'm now discussing with a college about a .NET solution for another product. Frankly I'm quite frustrated of how hard it is to find whats included in a given .NET release. My initial assumption was that C# + CIL is roughly Java SE and .NET Java EE. However, I can't find information about e.g. container managed transactions in .NET or if ISS is a part of .NET or not. If not, how does ISS interact with .NET? Can an alternative server be used?
Please help me in directions to a Java EE spec similar description of .NET.
It might not be easy to find a single consistent specification, but there are various resources with the information you are looking for, such as:
An overview of the .Net Framework (4.5)
Roadmap for .Net Framework (4.5)
Quick Technology Finder for the .NET Framework (a list of tech and features)
For each version of the framework, you've also got the What's new pages. This link is for version 4.5, but if you select "Other Versions" from just below the title, you'll get info about new developments previous versions of the framework.
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.
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.