A few questions before trying out .Net

Question

Before checking out what it's like developping in .Net, I have a few newbie questions:

1. Can a non-admin user install the .Net framework, whether the original package or any subsequent update required to run a programm? Some of our customers have locked-down XP/Vista hosts, and I'm concerned about installing/updating their computer when we upload a new release that requires updating their version of the .Net framework with the latest ServicePack

2. Is performance acceptable on regular Joe hardware (ie. doesn't require latest and greatest, power-user hardware)? Our applications are business applications that users leave open all-day, so it doesn't really matter if .Net apps take more time than their Delphi or VBClassic equivalents to start up, but is performance on par once the .Net framework is up and running?

3. If performance is clearly not as good as eg. compiled Delphi apps, are there known, reliable ways to speed things up?

4. Since I'm used to writing scripts in Python, is IronPython on par with other .Net languages, or is it more of a hobby language and I should head for VB.Net?

---

Further questions:

1. Which IDE should I use? MS' VisualStudio? SharpDevelop? Other? Why?
2. What makes Mono better than .Net for Windows desktop apps?
3. In an application, how to check if the user has the right version of the .Net framework and any needed ServicePack? I'd like to avoid having to pack the required .Net framework if it's not needed (ie. if it's not installed and the user has enough admin rights, download and install it before resuming running my app)
4. What happens if the user isn't logged with enough admin rights to install .Net and/or any needed ServicePack? Is there an obvious error message, so that non-techie users can tell what is wrong?
5. Is .Net downward-compatible, ie. can an application compiled for 2.0 run on 3.5, or are there tricky incompatibilies, so that it's recommended to install the .Net used to compile the app?

Thank you for any feedback.

Answer 1

Can a non-admin user install the .Net framework, whether the original package or any subsequent update required to run a programm?

Generally speaking, no. For development, you're definitely going to need the framework installed to use most tools, and you'll need administrative access for that. That said, there are some technical workarounds that enable you to deploy a single application without having the .NET framework on the target computer.

Is performance acceptable on regular Joe hardware (ie. doesn't require latest and greatest, power-user hardware)?

Yes, very much so.

If performance is clearly not as good as eg. compiled Delphi apps, are there known, reliable ways to speed things up?

There's plenty of introspection, profiling, and optimization tools available -- CLR Profiler, dotTrace, Reflector, et cetera. Somewhat of a moot point, since most .NET programs are on par (or better than) their counterparts, as noted above.

Since I'm used to writing scripts in Python, is IronPython on par with other .Net languages, or is it more of a hobby language and I should head for VB.Net?

Although the implementation is relatively mature and it's reached the "it just works" stage, the tools supporting IronPython aren't as robust as the other languages in the .NET family. For a beginner, you might want to try C# just to get your feet wet, since the toolsets will be well developed and you'll have lots of examples to go on. That said, I routinely use IronPython and IronRuby on production projects. Good stuff!

Answer 2

1. No. System files need modifying, and as such the framework itself can only be installed by a privileged user. Applications that run on .NET don't require special permissions to install or update though.

2. Performance of .NET applications isn't really an issue for business applications. Yes, they are on par with Delphi, VB pre .NET and Java.

3. Same as with any application: profiling and optimising. Profiling .NET applications can actually be very easy given the amount of metadata that can be (and is by default) stored in the actual executable for the profiler to use.

4. No comment really, since I havn't used any of the three much.