This project is read-only.

Does suppurt for .NET 3.5 dropped?

Dec 1, 2012 at 12:51 AM

Use of default parameters makes it impossible to compile HtmlRenderer with Visual Studio 2008. However some legacy software needs framework  version< 3.5 (Linq will not work for 3.0 ether). There is no problem to port it to 3.5 using overloads.

Dec 2, 2012 at 9:04 AM

The project by default is targeting .NET 3.5 client profile, so no, the support for 3.5 is not dropped.

Changing the targeting framework to 3.0 or 2.0 has only few compile errors that can be easily fixed if needed.

Default parameters is compiler feature that is not supported in 2008, I would advice you to upgrade your VS to 2010 or 2012.



Feb 13, 2013 at 12:38 AM
As I mentioned in the newer thread, targetting 3.5 strategically makes little sense for a Windows Forms library whose goal is to provide functionality that is missing from Windows Forms, but is present from WPF. When WPF is available to use based on requirements of the application, it makes sense to use WPF, which means using newer framework. So the corrollary of this is if you are stuck with Windows Forms, you are very likely stuck in pre-WPF land, which means 2.0. That is exactly the type of user who needs this control, and exactly the type of user who can't use it since it targets 2.0!

I am certainly not in the minority of folks to say that if I am looking at using these controls, I'm obviously likely working in Windows Forms, and therefore most likely targetting 2.0. If I'm targetting 3.0+, I'm likely using WPF, and likely not going to need or use these controls.

As such, I believe the original author had this right when he targeted 2.0 (not that there was much of a choice back in '08'/'09), and it was a strategic mistake to migrate it to 3.0 or even 3.5 given the target audience of those who would use this control. If you disagree, the proof is in these discussions. There have been two requests in just the past few posts. There will be more.

Again, I have no qualms with it using VS 2010 projects and/or solutions, but it should still target 2.0, which the vast majority of the code is compatible with. It's just stuff added recently that seems to use the newer features such as Linq.

While it may be true that it is fairly straight forward in general for somebody to migrate the code to an earlier framework, it is certainly not universally true. For example, what if the dev doesn't know Linq? Furthermore, require them to repeatedly redor their code integration each time a new version is dropped? Plus, this isn't just about one developer having to do the port. Each dev wishing to targe 2.0 will have to do it, and perhaps many times. All this time adds up, for virtally zero gain.

Since you gain little by going to 3.0/3.5 as the code-base is already massively 2.0, it should just target 2.0 and then NOBDOY has to ever "convert" it, perhaps several times as the codestream changes. In this world. if somebody wants to recompile it targetting 3.5, they can with a single project-level setting, no fuss, no muss. The reverse today is NOT true when trying to go backwards to 2.0.

The bottom line is if it is truly "easy" to port this to target 2.0, given the above logic, I believe it obviously makes the most sense to actually do so in the main stream. Over time as more features are added, more will be written in 3.5 features that are not backwards compatible, and it will further burden the target audience with having to do a port. Porting to 2.0 now nips that potential in the bud. Again, to me strategically it just doesn't make sense to continue to target anything beyond 2.0.

The bottom line is if it targets 2.0, you can still use it in 2.0, 30, 3.5, etc. But if it targets 3.5, you are screwed for 2.0 and 3.0. Since so little code in fact needs Linq or the new 3.5 features or classes, I submit that it simply makes far more sense for the main code stream to target 2.0, and be done with it, and widen the target developer audience, once and for all.

Or to look at it another way: there is zero burden placed upon users of the later framwork say 3.5 if the control targets an older framework say 2.0. The reverse is NOT true. This is why 90% of commercial component libraries sold today STILL target 2.0 (or 4.0 for totally new versions), and hardly EVER target 3.0 or 3.5. The reason is simple: it is strategilly innective to do so. 2.0 runs just fine on 3.0 or 3.5, and there are very little useful language features you can't live without with 2.0. But targetting 3.0 or 3.5 for thse minor language features drastically cuts your market. When you are talking about a Windows Form control, it undercuts it even more!

Even though this isn't commercial software, it is fundamentally designed to be used by others. As such, it should, just like commercial software, be designed for maximum target audience size. It reduces that target audience by targetting 3.5. You enlarge it by targetting 2.0. You lose zero users when going from 3.5 to 2.0, in fact you gain. However, you lose users going from 2.0 to 3.5. That is irrefutable.

Hopefully these valid arguments have caused a shift in direction. ;-)

Like I said in the other post, I'll gladly provide the code which does the transition. But I'm only going to do so if it is going to go into the main stream and the project will continue to target 2.0 for the foreseeable future, if not inperpetuity. I don't want to be in the code-integratino business and have to with every few bug fixes or new features have to reintegrate at the code level, when I'd just rather drop in the new dll. I see no reason for this library to ever go to 4.0 or beyond. As such, I see no reason for it to ever support anything beyond 2.0.

Anyway would love to hear the thoughts of others on this. Not trying to start a flame war or anything, just curious if I've overlooked something in my logic which outweighs the points I've made.

Feb 13, 2013 at 9:32 AM
Very passionate of you, I will respond in your post.