dilettante
MIS
A little bit on how and where Microsoft is beginning to use .Net itself.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Dog Food: Microsoft and .Net
- Thread starter dilettante
- Start date
- Status
A little bit on how and where Microsoft is beginning to use .Net itself.
TroyMcClure
Technical User
I don't know if it's just the way I read it, but it seemed like, sure, they're starting to use .Net to build internal apps as well as for some external apps--but it sounds painful. It seems too 'unnatural'--like they have to jump through all these hoops to do it.
When C++ came along I don't remember anyone having to spend billions of dollars to try and get people to use it. It just took off. That clearly is not happening with .Net. I'm not trying to start a polarizing flame war here but there's something to the fact that .Net just isn't pulling developers in from all over the place as C++ did.
T
When C++ came along I don't remember anyone having to spend billions of dollars to try and get people to use it. It just took off. That clearly is not happening with .Net. I'm not trying to start a polarizing flame war here but there's something to the fact that .Net just isn't pulling developers in from all over the place as C++ did.
T
- Thread starter
- #3
dilettante
MIS
One problem (if you consider it a problem at all) is that .Net is following in almost precisely the footsteps of Java. No surprise, since in a very real sense it's a clone of the basic concept.
The "weakness" is in Windows Forms. If you follow the discussion around this topic in current blogs by Microsoft folks and people close to Microsoft you'll see plenty on the subject. There are simply a whole lot of things that can't be done from their managed code environment yet. With time more of the Win32 APIs will be "wrapped" for more convenient use from .Net languages. Until that point you end up doing a lot of work-arounds to get at native parts of Windows... to the point where coding in C++ or even VB6 puts you ahead of the game yet.
There is also the learning curve to consider, and this is as steep in-house as in the ISV and customer communities.
There is also Avalon to consider. For many classes of applications this will probably replace WinForms. How do you justify ramping up to develop for a GUI system that may be sunsetted in 3 years?
Finally, there remains the slow uptake of the Framework out in the wild. Especially when one must ask the question which Framework? This is still a deployment burden far beyond that of the old VB runtimes, and versions have come out rather furiously to date by comparison with VB.
But .Net is getting there slowly. Even if it never becomes common outside of the server environment it will probably remain a strong competitor to Java.
I think the good news is that this slow progress within Microsoft should serve as a sanity-check for outside development organizations. It shows where we ought to be making progress with .Net and where we needn't be rushing headlong.
The "weakness" is in Windows Forms. If you follow the discussion around this topic in current blogs by Microsoft folks and people close to Microsoft you'll see plenty on the subject. There are simply a whole lot of things that can't be done from their managed code environment yet. With time more of the Win32 APIs will be "wrapped" for more convenient use from .Net languages. Until that point you end up doing a lot of work-arounds to get at native parts of Windows... to the point where coding in C++ or even VB6 puts you ahead of the game yet.
There is also the learning curve to consider, and this is as steep in-house as in the ISV and customer communities.
There is also Avalon to consider. For many classes of applications this will probably replace WinForms. How do you justify ramping up to develop for a GUI system that may be sunsetted in 3 years?
Finally, there remains the slow uptake of the Framework out in the wild. Especially when one must ask the question which Framework? This is still a deployment burden far beyond that of the old VB runtimes, and versions have come out rather furiously to date by comparison with VB.
But .Net is getting there slowly. Even if it never becomes common outside of the server environment it will probably remain a strong competitor to Java.
I think the good news is that this slow progress within Microsoft should serve as a sanity-check for outside development organizations. It shows where we ought to be making progress with .Net and where we needn't be rushing headlong.
This is very simple: product designers, as a matter of efficiency, do not use their commercial products to design other products.
Doing so would be foolish, when you control the OS.
There is nothing that should compel MS to use .NET in their new offerings. I have bashed MS before, but this idea of forcing MS to use .NET is nonsense.
- Thread starter
- #5
dilettante
MIS
I don't think it's about "forcing" at all. More a question of how much use Microsoft has made of it internally. A sort of yardstick to determine whether it is "ready for prime time" by the rest of us.
- Status
Similar threads
- Locked
- Question