Poll: Should the project upgrade to the .NET 4 framework?

Coordinator
Aug 17, 2010 at 4:42 AM
Edited Aug 17, 2010 at 3:00 PM

As of right now, the project has been using the .NET 2.0 runtime since launch. I'd like some feedback from the community on whether to upgrade to the .NET 4.0 runtime, or to keep it on the 2.0 framework. If I do not receive any feedback from the community regarding upgrading, I will be upgrading to the .NET 4 framework.

Please let me know what your thoughts are so I can make a more informed decision. Thank you!

Editor
Aug 18, 2010 at 2:28 PM

We're not yet a .NET 4 shop (getting colleagues to use .NET *period* is bad enough sometimes), so I vote no ugrade for now.

Aug 18, 2010 at 11:44 PM

No upgrade, I think it would be better to concentrate on Windows 7 functionality without .net 4 first and worry about .Net 4 later as we require backwards compatability to VS 2008 and .Net 2.0 for many of our systems at the moment.

Coordinator
Aug 19, 2010 at 12:14 AM

All of the Windows 7 specific features have already been completed for the 1.2 release. I wasn't specific earlier, but the upgrade would take place after the 1.2 release. I want to make sure any bugs that were in the 1.1 release are fixed before upgrading to the .NET 4 runtime. This would allow anyone using the 1.1 release to use 1.2 and get the bugs addressed without needing to upgrade their projects to the .NET 4 framework. I would just need to start releasing service pack updates to 1.2 to ensure any bugs found can be fixed. The 1.3 version of the project would be the start of the .NET 4.0 requirement.

Aug 19, 2010 at 12:29 PM
I vote no upgrade. Most user's PC installed .NET framwork 2.0. It is difficult to distribute those applications that based on .NET framwork 4.0. And I want to know when the new version of DOTRAS that supported windows 7 will be released.
Coordinator
Aug 19, 2010 at 2:59 PM

It's close to being completed, I'm still working on a new feature I wanted to get into the release. Hopefully within the next month or two I can get it launched in RC1, which I plan to keep it there for a month or two depending how much feedback I'm getting from bugs with the release. If a large number of bugs are identified, it'll go to RC2 and keep repeating that process until I think most of the bugs have been found.

I'm fairly confident about the launch, much more than I was with the 1.1 release. I've done a lot of testing, written a massive amount of unit tests, and written integration tests for 3 different servers. So once it goes to RC1, it should be pretty quick to go to RTW.

Aug 19, 2010 at 9:27 PM
Edited Aug 19, 2010 at 9:43 PM

I am undecided if the upgrade should be to .Net 3.5 or 4, but I do feel that you should drop support for Windows XP and .Net 2 from 1.3.

Since Windows Vista comes with .Net 3 (or is it 3.5?) out of the box, I would say that should be the minimum supported .Net Framework. We have to move on at some point in time, and now is the best time to move. I don't think the question should be if we are going to upgrade from .Net 2, it should rather be whether the upgrade is going to be .Net 3/3.5 or 4 but it has to be upgraded to take advantage of Framework improvements and then Windows XP should also be dropped in v1.3.

Why am I saying drop XP? Lets look at time frames... v1.2 won't be going RTW before Nov-Dec. Then v1.3 will start and going by the time lines of v1.2, that should ship round 2nd half 2011. By that time, you won't be able to buy XP for 2 years already and Win 7 has been on the market for 2 years already. .Net 2 would be 7 years old and .Net 3 would be turning 5, so it should rather be a question of to which Framework are we jumping. I don't think 3 should be considered, but it should rather be a choice between 3.5 and 4.

Also, if you moan about XP being dropped... we have to move along with time. v1.2 would still be available and would still support XP. RAS support in XP won't change in the future so why should this library be supporting it till dooms day?

My personal opinion is that v1.3 should have atleast these minimum requirements:
OS: Vista SP2
.Net Framework: 3.5

If you don't have that to run v1.3, then stay with v1.2 or upgrade your systems because the rest of the world has upgraded.

That is my 2c worth.

Coordinator
Aug 24, 2010 at 5:49 AM

Well, removing support for WINXP won't happen. Many large corporations take a very long time to upgrade operating systems, which dropping support for Windows XP and Windows 2003 server (still a widely used server operating system) would be crazy. Besides, supporting the build type is less work maintaining it than removing it due to all the preprocessor directives in the code. All of the WINXP specific features have been done for quite a while, and the whole build process is automated so I don't really do any work to support it. When I add new features that have WINXP specific features I have to take it into account, but it's not that big of a deal. I have to do it for the other operating systems anyway... adding support for Windows XP and Windows 2003 server is as simple as adding #if (WINXP) to the code.

The reason why I waited for .NET 4 and instead of upgrading to .NET 3.5 was due to the core runtime change. Upgrading to .NET 3.5 would still require users to have the base 2.0 framework installed on their machines, whereas the .NET 4.0 framework does not. Other than Linq there wasn't much I felt was needed out of the 3.5 framework. With code contracts being introduced to the core .NET 4 framework, I felt it would be beneficial to for users to know exactly what to expect out of my objects rather than assuming the SDK is telling the truth.

1.2 would be the last version to support the 2.0 framework. Any bugs identified post release would need to be fixed in a branch, merged into the trunk, and have a service pack to 1.2 released. 1.3 would require .NET 4 and still support all of the existing operating systems.

Aug 25, 2010 at 3:25 PM

Hi Jeff,

I would say that it would be good to upgrade to .net 4.0. I am developing using visual studio 2010. I couldn't use DotRas because the project started off with .net.2.0. Please if you could just release a beta version i would really apprieciate it. :)

 

 

Coordinator
Aug 26, 2010 at 6:01 PM
Edited Aug 26, 2010 at 6:01 PM

You can still use the project in a .NET 4 application... one of my test WinForms apps I use for testing during development is configured this way. I believe the target machines would need both .NET 4.0 and .NET 2.0 installed for the application to run (this has not been confirmed).

Aug 27, 2010 at 3:54 AM

Hi Jeff, I got the issue sorted out. Yeah it is working  in .net 4.0 for version 1.2. But for some unknown reason, while using 1.1, I couldn't compile it. Now everything is working fine. Thanks for all the hard work. You are the man. For those who are using 3G modem and having problem like me. You need to set the entry options for the phone book. After that everything should be ok and by the way Rasentrytype.direct does not work in windows 7, but works on win xp. Correct me if I am wrong. :) 

Dim entry As RasEntry = RasEntry.CreateDialUpEntry(EntryName, Phone, RasDevice.GetDeviceByName(mo("Model").ToString(), RasDeviceType

.Modem))  

 

 

'entry.EntryType = RasEntryType.Direct ' for windows xp

entry.Options =
RasEntryOptions.RemoteDefaultGateway Or_ 

 

 

 

RasEntryOptions.ModemLights Or _

RasEntryOptions.SecureLocalFiles Or _

RasEntryOptions.RequirePap Or _

RasEntryOptions.PreviewUserPassword Or _ 

RasEntryOptions.ShowDialingProgress Or_

 RasEntryOptions.RequireChap Or _ 

RasEntryOptions.RequireMSChap2

AllUserPhoneBook.Entries.Add(entry)

Coordinator
Aug 27, 2010 at 4:17 AM

Yeah, the Direct enum value is actually removed from the WIN2K8 and WIN7 build types. If you're using the earlier build types the enum value is available, but does not work. I'll add some stuff to the documentation for the enum indicating the value won't work on those operating systems.

Sep 4, 2010 at 11:13 PM

From a developer's standpoint it would be nice to have .Net 4.0 support, but some clients won't like it to download and install a new .Net Framework though.

I already had issues where my users didn't want to download and install .Net 3.5 simply because 200MB Framework was too big to download.
.Net 4.0 is only 50MB, but I think you'll still lose some of your old clients due to them being to stubborn to upgrade.

I would give priority of keeping Windows XP & .Net 2.0 support over going to .Net 4.0!

Well done with everything that you've already accomplished with your framework!
I have quite few users (300 of them at least) who really appreciates the application that I wrote, with DotRas playing an integral part in it, since its saving them money and effort of buying Internet cap.

Sep 19, 2010 at 11:51 AM

Yeah, I bet the new dynamic stuff in .Net 4 would make a lot of the interop code much cleaner.  I would vote yes for v1.3.  (obviously keep 1.2 alive for those forced to stay on .Net 2).

Coordinator
Sep 19, 2010 at 4:11 PM

Well the biggest reason for the interop code being written the way it is, was to allow for testing and mocking the interop calls. Without mocking, those sections would call the operating system on the build machine making unit testing much harder. I have some functional integration tests that do call actual servers during the build process, but I try to keep those tests to a minimum due to their complexity. If I pulled all the unit testing pieces out, it would be pretty basic stuff (which it was very basic for quite some time).

Sep 19, 2010 at 9:46 PM
Edited Sep 19, 2010 at 9:47 PM

OK, interesting.  I was just making a more general point about how much nicer interop can be in .Net 4 using dynamic types.  I'm not sure how much impact it would have on the unit tests though.  Thanks for the insight.

Coordinator
Sep 20, 2010 at 2:56 PM

Interesting concept, but I don't know what it'd do. For structs that contain pointers I have to change the packing alignment for support of 64-bit processors, and the size of the structure during runtime changes with each assembly. The size of the struct being passed into the API call does change how the call interacts with the struct, I'd have to play around with dynamic types to see what effect they'd have on the interop code.

If I can find a way to more easily perform the functions of the RasHelper class while keeping the testability intact, I'd definitely be all for it.

Coordinator
Oct 25, 2010 at 6:44 AM

Bump

Nov 16, 2010 at 9:13 PM

Yes, of course. And keep Backward compatibility, if possible. It`s very important for developers and projects.

 

Coordinator
Nov 16, 2010 at 10:05 PM

The only backward compatibility for .NET 2.0-3.5 would be previous releases. I currently have no plans to remove them from the download list, so they will be available for download when needed. I do branch between releases, so there is the possibility of fixing bugs by pushing out service pack releases to the 1.2 release.

1.3 and later versions would require the .NET 4 framework on the target machines.

Nov 25, 2010 at 3:04 AM

Hi guys,

Just to let you all know. If you have project that you need to deploy through the web,  .NET 4.0 installation files is a full 70Meg, as dotras is unable to use .Net 4.0 client profile. The pro of .Net 2.0 is that its installation file is smaller. I just found out when I need to deploy it.

 

 

 

Coordinator
Jan 16, 2011 at 7:45 PM

Bump

Mar 15, 2011 at 3:55 PM

+1 Vote for .NET 4

We are starting a new project that is only going to support .NET 4 and up and we would very much like to use this project.

Coordinator
Mar 15, 2011 at 5:10 PM

Feel free to grab the source code from the releases tab for the current stable release, you should be able to change the target runtime to 4.0 if you want to use it and do not want to wait.

Apr 27, 2011 at 8:32 PM

It would be nice if you can keep a version for .NET 2.0 atleast for a while. I have a project that won't migrate to 4.0 for some time.

Coordinator
Apr 29, 2011 at 10:44 PM

I had an idea earlier today... I'm going to investigate if I can compile both a .NET 2.0 and a .NET 4.0 version. I don't need anything specific out of the 4.0 framework, but this would at least allow the project to use only the 4.0 runtime on a target machine. Not sure if this is possible yet, but hopefully I can make it happen. From what I saw earlier in the project files, switching the TargetRuntimeVersion from "v2.0" to "v4.0" should effectively change which runtime the project is being compiled for. If used in conjunction with my build.proj file, it very well could be possible to compile both with no additional maintenance necessary.

May 24, 2011 at 10:29 AM

We are still using Windows XP with Visual Studio 2008, so please keep supporting .NET 2.0 framework.

Coordinator
May 30, 2011 at 3:09 AM

Well I worked out how to get both runtimes supported simultaneously by the project using the same codebase so no extra maintenance was required. I can't make use of any .NET 4 specific features, but at least the runtime is now natively supported by the project once built by the make.bat file. So this is really no longer a concern.