Hi Kevin,

I wanted to focus this thread on costs involved, so people can draw
their conclusions before making such serious move as is to change
development platform.

As for NET, I can easily foresee - tons of reading/learning/prototyping/developing/redeveloping/frameworking involved, simillar to what we all went trough when converting FPDOS>VFP. It is huge personall and/or company endeavour undertaking that has to be done , and that is it. No questions/secrets here. You bite the bullet/ Go4It
(Provided that this is what you really need / wanna do. )

...But;

Let's go back to COSTS, because whole DECISION to undertake above
PoolAllTheTeethOut/GrowNewOnes might depend very well on that.
So let figure out if we can afford the dentist first, and even more important
CostOfLeaving afterwards :)

So we will hv

1. Initial amount (X+Y) spend on learning/adopting dev platform. (1&2 from orig. post)
2. Cost of (re)development of existing & new apps. (Average)
(7-8 major ones in my case & N+1 small ones)
3. If you don't sell but only dev./use software (my case) then you also need
to count inhouse re-implementation costs.
4. Initial MSSQL Licencing costs (+ some hardware costs)
5. MSSQL Administration/Maintenance costs.

Since I don't personally thing anybody serious wld go trough all this just in order to use SQL express or JetEngine or (hell no!) MSAccess at the back end, let's get back to above list with focus on 2,4,5 - excluding all other back ends and focusing only on MS-SQL.

Wld not analyse Oracle/SyBase & respectable others, let stick with MSSQL
at this point in analysing our hypotetical business case.

Guys I need some numbers here, this thread is not about development beauty
or HowTo or WhatToDo/NotToDo - it is all about money! :)
Let's try to figure out how much wld it cost us.


TIA Kevin / All Others



>To date, I've built about 10 .NET applications, and about half of them were VFP->.NET conversions. All but one use SQL Server/SQL Express as a back-end...one uses FoxPro tables as a back-end.
>
> 1. Time to get *comfortable* with NET.
>
>There's no one "right" answer. But in all but a few cases, it's more than 3 months. ;)
>
>I think much of it depends on the skill level of the person. If someone is a "sponge", if they can take a few hours reading and absorbing and processing magazine articles, blogs, and previous .NET solutions on the UT , they're going to pick up things faster than those who don't.
>
>I think HOW one learns .NET is as big a question as HOW LONG it takes. It's an investment as well as a cost.
>
>I also think those who have used VFP with other tools (another back-end DB, another reporting tool, XML, etc.) are at a general advantage over those who have only used VFP. That's not a blanket statement, but I think there's some truth to it.

>
>I'm not trying to be preachy (OK, not much, anyway ;), but several on this forum have given advice for many years to learn .NET before it becomes a big dot on their radar. Those who do so are at an advantage over those who don't spend time learning .NET until the requirement is staring them in the face.
>
>If the person is a PUTM member, search through all the solutions in the .NET forum of the UT. There's a ton of information up there. MSDN for VS2005 is (IMO) much better than it was for VS2003. Read CoDe magazine and get the back issues. Take a piece of your app and experiment with converting it. Again, go through the iterations as much as you can BEFORE the reality is staring you in the face.
>
>Everyone talks about learning C# (or VB.NET)...that's certainly a big part of it. But learn the capabilities of Generics and ADO.NET in VS2005 (and yes, keep a close eye on the LINQ project).
>
>Does this mean someone is going to put in some long nights? Sure. If we want to be treated with the same respect as other professions, that means investing time in one's career.
>
>2. Time to create your own, or adopt workable commercial framework (Not to someone like RickS, or BonnieB or meny respectable others, but to a regular senior level VFP person.)
>
>Some people can pick up a commercial framework and find themselves productive with it pretty quickly, and others can pick up a framework and really get bogged down. I've seen both happen.
>
>Even if you use a framework, you're still going to want to build a library of reusable components. Even the best frameworks don't do everything. The process of writing your own components will help with the learning curve.
>
>3. Time for conversion/development of typical VFP custom project. Let say, ordinary sales-invoicing application, involving standard reporting with some typical yearly/monhly/weekly/summary sales figures being derived
>from the system and presented to the user. Client/Server app deployed on LAN.
>
>It depends on how well constructed the VFP application is. One of the many phases of a conversion project is to build a technical architecture definition - if the VFP app followed decent practices, that will help. If it doesn't, it many add time to the conversion process.
>
>Your asking good, though very general questions. I'm just trying to give some food for thought, based on what I've run into. If I can think of more later, I follow up.
>
>And finally....take the feedback of those who have not built anything in .NET for what it is - feedback from those who have not built anything in .NET. There's no question that .NET has a big learning curve. For some, the learning curve can't be justified business-wise. That's fine.
>
>But remember that the statement ".NET is not ready for Fox developers" is often translated as "I/we can't justify the time for .NET's learning curve". It's important to distinguish betewen the learning curve of a tool, and the capabilities of the tool.
>
>Kevin