|
Why .net not appropriate for shrinkwrap sw
Here's an example of someone who tried using .net for a shrinkwrap app. Poor results due:
1. Longer download
2. Longer install time
3. Unexplained bugs identified as "known problems" by MS.
http://www.softwareceo.com/forums/showthread.php?s=&postid=3899#post3899
I guess I *will* have to stick with vb6 for a while longer.
Mr. Analogy
Wednesday, March 24, 2004
For those who don't want to bother registering for that forum, here's the message (from user RoboDale):
I have read this entire thread and I'd like to share my experiences with using .NET to develop commercial applications.
Allow me to quickly introduce myself, as this is my first post, and I am very new to the SoftwareCEO forums. I own a very small ISV with focus on personal financial analysis applications. I do not want to say more at this time about the company or our products, as we have several competitors who have been matching our new product features mere weeks after our releases.
Regarding .NET - We decided to dip our toes into .NET by releasing an updated version without new functionality of one of our less-critical applications with .NET. I, for one, was excited to use the latest development technology Microsoft had to offer and anticipated great things with the new development technology. Our customer base for this product varies widely, but is generally people who purchase the product for personal use, to install on their own computers. We wanted to gauge how our download-to-sales ratios would change after the release of the .NET version. Well, to make a long story short, downloads plummeted, sales went to zero, and user complaints went up.
From user support questions, here were the main problems we encountered:
1. Install size to large for this caliber of application. We were well-aware we would have to provide the .NET framework in the install, which the resulting trial version available for download tipped the scales at 30 MegaBytes. General users who install the software complained the file was too large to download (especially for dialup users).
2. Installation Setup takes MUCH too long. The install package for this takes anywhere from 3-10 minutes depending on the speed of the computer performing the install....and nearly all of this time is the .NET install. Our actual software product install only takes 30 seconds max. We believe this long install with .NET is the killer for the bulk of our potential customers.
3. Memory size of of our application during runtime is far too large. We have many users with only 32 - 128 Megabytes of physical memory on their computers. Our app written in .NET now takes between 22-45 MegaBytes while using the app (versus 2-8 MegaBytes with our old version). Sorry to get so technical here, but I think I needed to share this nonetheless.
4. Unexplained bugs. We encountered several mysterious bugs - mostly GUI controls / event processing stuff, but we had to cut out the functionality since we simply could not track down the cause. The problem has since been ID'd by Microsoft, and it is a "known issue".
I realize that we could help most of the issues above by further refining the program design (better memory handling, workaround the .NET bugs, using ThinStall to shorten the install package and install time), but with limited resources, I have had enough. The lesson I learned was that if you plan to go the .NET route, then plan on allocating significant resources to acheive the same overall deployment and presentation of your software products as your previous development architecture. We plan to abandon further development using .NET, and go back to our tried-and-true "Visual Basic 6.0 for the GUI, C++ for the object libraries), as this has proved the best way for us to achieve satisfactory ease of development, yet maintain solid performance. I would appreciate comments on this, and if this needs to be moved to another thread, that is ok.
-Dale
Chris Tavares
Wednesday, March 24, 2004
Stick with VB6. There is no reason to move to .Net until Microsoft releases Longhorn at which point you will probably *have to* move to .Net.
Wayne
Wednesday, March 24, 2004
Our experience has been exactly the opposite. We haven't had any problems like that. I guess that you have to plan for things before you jump in. On our end we have had zero regrets going with .NET.
JWA
Wednesday, March 24, 2004
JWA,
Is your app "shrinkwrap"?
Eric Sink
Thursday, March 25, 2004
I all comes down to your target customers. They knew most / a lot of their customers had slow machines with not much memory on dial up. So was it a good decision to release a .NET app? Probably not. For other companies with a different customer base it may make more sense. YMMV
DJ
Thursday, March 25, 2004
If you are working on the server side, I guess it wouldn't be a problem. No downloads needed.
What would bother me about using VB6, is that you are developing for a platform where the support is diminishing, and slated to go away.
Say what you want about C++, but at least we still have a support path from Microsoft.
christopher baus (www.baus.net)
Thursday, March 25, 2004
If you sell your .NET app in a box with a pressed CD the download issue goes away. You put the redistributable on the CD (like games dev's have been putting DirectX on their CD's for ever) and your installer figures out whether or not to install it.
*provided you can get ok from MS to ship the redist on your CD which from memory wasn't in the standard license
Dan G
Thursday, March 25, 2004
1. Redistributing the dotnetfx.exe redistributable is perfectly legal for people who have agreed to the EULA for VS.Net or the .Net framework SDK. (as far as I know)
2. Our app goes out on CD, and I think I have posted this before, but by the time we include all the stuff required for our app (VFP 8 runtime - 20MB, Crystal 9 runtime - 50-60MB, Windows 2000 SP3 - ?? MB, Windows XP SP1 - ?? MB) our CD image is 550MB so adding the 23MB for dotnetfx.exe was a no brainer.
3. Backlash from installing the .Net framework - none, we had more backlash when we included Win2000SP4 on the CD instead of SP3 - apparently SP4 isn't too popular in the real world? - And this is on full production servers in some of Australias biggest IT departments - the .Net framework is not an issue for big companies.
4. Contrary to number 3, and as posted in this thread already, the .Net framework is an issue for companies whose client base is home users on 28k dialup, and as suggested earlier you would be stupid to try and use the .Net framework in this environment. (In my opinion even the VB6 runtime is too much on dialup - I know I never downloaded it when I was on dialup)
Chris Ormerod
Thursday, March 25, 2004
I have tried C# for developing Windows applications.
Compared to Delphi, the controls that come with .NET are very poor and very, very buggy.
So thanks, but no thanks!
MX
Thursday, March 25, 2004
Where's our local Microsoft Evangelist when we need him. Philo, please straighten these guys out!
Wheres Philo
Thursday, March 25, 2004
We're about to release a .NET product and have found the platform fantastic. I think the mistake many are making when evaluating .NET is looking short term. If your product will take a year to develop and another year for sales to ramp up to an appreciable amount, it's probably a moot point. Users will have the runtime by then one way or another.
Similar arguments have been used to develop Win16 apps (Win95 is a hog and won't make it), Java apps (who knows what will happen w/Windows), and avoiding OOP (it's slow).
If .NET allows you to save 30% on your development costs, maybe it's worth it to your company to accept losing a few low-end customers. It all depends on your situation. If you're a market presence and people know you won't be wasting their time with your 30 Meg download, you're probably okay.
Thoughts?
Bill Carlson
Thursday, March 25, 2004
Bill wrote:
"If your product will take a year to develop and another year for sales to ramp up ... Users will have the runtime by then one way or another.
But which version of .net ? 1.0, 1.1 or the next 2 or 3 versions that will come out in the next 2 years.?
If you shoot for .net v1.0 then you'll have to test against all the other versions. If you compile based on the latest version most of your customers will NOT have it because it's a moving target.
AND.... if only 30% of your customers don't have ityou have to explain on your website "download A if you do not have .net". ".net? what's .net" my customers will be asking.
If .NET allows you to save 30% on your development costs, maybe it's worth it to your company to accept losing a few low-end customers.
"
SW dev is probably 30% of our costs so that would save a total of 10% of our costs. (BTW, I see no way that .net will ave us even 10% of dev costs).
And our margins are high. So, for every $1 we spent, we're making back $2 or so.
So.... if our revenue dropped by 10%, that's like costs going up by 20%.
Mr. Analogy
Thursday, March 25, 2004
Philo has been distracted with a full-time running commentary on the "Apprentice" rather than debunking anti-MS FUD-meisters. Can you say "Your Fired!"
Philo watches CBS
Friday, March 26, 2004
 Recent Topics
Fog Creek Home
| 
