Tell us your .NET troubles

Uncategorized 1 Minute

Chris Sells is a developer here and is working on one of the .NET teams and he's looking for developers to tell him what sucks about .NET. "In this case, I’d like to know what “pain points” you experience when configuring, deploying and maintaining distributed .NET applications."

Another human you can talk to here.

Advertisement

Published by Robert Scoble

I help entrepreneurs build their technology business' story, help with getting ready for investors, with other launch plans, and many other strategic things that can help your new startup. Call to talk: +1-425-205-1921 (text first).

Published

4 thoughts on “Tell us your .NET troubles”

  1. lack of good obfuscation tools suck – even after obfuscation thr .NET code is too easy to decode – so intellectual property is not preserved so goodcas in Java or in native (non-managed) code.

    Like

  2. lack of good obfuscation tools suck – even after obfuscation thr .NET code is too easy to decode – so intellectual property is not preserved so goodcas in Java or in native (non-managed) code.

    Like

  3. 1) TabPages can’t be disabled and the appearance of the tabs themselves can’t be changed (to make it look like it’s been disabled for example). This is basic stuff. Incidentally, the docs in 2005 mistakenly say that you can set the Enabled property in several places.
    2) DataBinding – It’s better, but still lacks some basics. If a textbox is bound to a varchar(20) in an ADO.NET DataTable, why does it let you type in more than 20 characters? If you bind it to an integer, why can you type in letters? I understand that you can used masked textboxes, but come on…
    3) I won’t go too much into data access/manipulation because it looks like LINQ will go a very, very long way. However… If I have access to my data source during development and during deployment, wouldn’t it be great if the information for making DataTables strongly typed coud be pulled dynamically from the data store cached instead of being in a static XML file that breaks things when the data structure changes? Once the design was firmed up, I could have the option of creating and using static XML. The only thing that really “should” break when the data schema changes are the select statements that explicitly name colmns that no longer exist.
    4) Wouldn’t WITH {} blocks be nice in C#?
    WITH this.tabControl1.Pages[“tabPage1”]
    {
    .BackColor = Color.Red
    .ForeColor = Color.White
    etc…
    }
    Maybe a personal preference, but easier to type, read and understand for me than
    TabPage tabP1 =this.tabControl1.Pages[“tabPage1”]
    tabP1.BackColor = Color.Red
    tabP1.ForeColor = Color.White
    etc…
    5) Better control over the appearance of disabled controls such as giving us .DisabledBackColor and .DisabledForeColor properties.

    Like

  4. 1) TabPages can’t be disabled and the appearance of the tabs themselves can’t be changed (to make it look like it’s been disabled for example). This is basic stuff. Incidentally, the docs in 2005 mistakenly say that you can set the Enabled property in several places.
    2) DataBinding – It’s better, but still lacks some basics. If a textbox is bound to a varchar(20) in an ADO.NET DataTable, why does it let you type in more than 20 characters? If you bind it to an integer, why can you type in letters? I understand that you can used masked textboxes, but come on…
    3) I won’t go too much into data access/manipulation because it looks like LINQ will go a very, very long way. However… If I have access to my data source during development and during deployment, wouldn’t it be great if the information for making DataTables strongly typed coud be pulled dynamically from the data store cached instead of being in a static XML file that breaks things when the data structure changes? Once the design was firmed up, I could have the option of creating and using static XML. The only thing that really “should” break when the data schema changes are the select statements that explicitly name colmns that no longer exist.
    4) Wouldn’t WITH {} blocks be nice in C#?
    WITH this.tabControl1.Pages[“tabPage1”]
    {
    .BackColor = Color.Red
    .ForeColor = Color.White
    etc…
    }
    Maybe a personal preference, but easier to type, read and understand for me than
    TabPage tabP1 =this.tabControl1.Pages[“tabPage1”]
    tabP1.BackColor = Color.Red
    tabP1.ForeColor = Color.White
    etc…
    5) Better control over the appearance of disabled controls such as giving us .DisabledBackColor and .DisabledForeColor properties.

    Like

Comments are closed.