.Net vs Native development argument
-
We're having a slight argument at work and I'm hoping you can resolve it one way or the other... (The app in question is squarely aimed at corporate environments, so home user type settings aren't relevant.) I'm saying that developing our new product in .Net will be faster and easier - the framework includes things that I'm currently having to implement myself, so I pretty much have double the amount to do compared to using .Net (and I'm running the risk of introducing bugs) The other side of the argument is based around there aren't that many .Net desktop applications and so a .Net app would be harder to market than a Win32 native app. Since this app is driving me a little mad, could someone tell me - are .Net apps harder to market? Do companies prefer to install Native apps over .Net apps? Do sysadmins dislike/have a hard time installing the framework in a corporate environment?
-
We're having a slight argument at work and I'm hoping you can resolve it one way or the other... (The app in question is squarely aimed at corporate environments, so home user type settings aren't relevant.) I'm saying that developing our new product in .Net will be faster and easier - the framework includes things that I'm currently having to implement myself, so I pretty much have double the amount to do compared to using .Net (and I'm running the risk of introducing bugs) The other side of the argument is based around there aren't that many .Net desktop applications and so a .Net app would be harder to market than a Win32 native app. Since this app is driving me a little mad, could someone tell me - are .Net apps harder to market? Do companies prefer to install Native apps over .Net apps? Do sysadmins dislike/have a hard time installing the framework in a corporate environment?
In my personal experience and professional experience as Director of Technology and chief architect at our company, sysadmins dislike doing anything that keeps them from playing solitaire or hiding out in some room playing Xbox. It doesn't matter if they have to install a native app or the .NET Framework + a managed app. The way to market this is the ability of a correctly written .NET application to not require installation. Yes, the .NET Framework and any service packs (.NET 1.0 will have SP3 and .NET 1.1 will have SP1 shortly) are a little bloated, but nothing typical IT solutions can't push out to machines (it is a Windows Installer package when you pass /c /t:path options to the installer executable). The managed application could sit on a share somewhere that all users can use, though IT will also have to push out a code group (if necessary) so that CAS (code access security) is granted the appropriate permissions to run certain code. That, too, is easy. One that app is out there, they never really have to worry about it again. If there's update to be installed, they can simply drop the new assemblies on top the old ones. Through publisher policy assemblies and/or .config assembly settings, even old assemblies can use new assembly versions that they weren't linked against. Assemblies can also be deployed like this over the Internet or an intranet. This is all known as touchless deployment. The IT folk don't have to worry about pushing out updates to an application; when written correctly, the .NET applications will update automatically through Fusion (the assembly bindiner portion of the CLR). .NET 2.0 will make this process even easier (and not require a 24/7 connection to check for updates) with ClickOnce technology. The only major downside is that managed apps can require quite a bit of memory. If you use a lot of types (our flagship app uses almost every assembly of the BCL plus a few other third-party assemblies), it will use quite a bit of memory. A well-written app isn't so bad, though. Another downside (sort of) is that it can be slow to start up since types must be JIT compiled. Once they are compiled to native code, however, the native code is cached and executes about as fast as native calls (stalk walks and the sheer depth of some execution stacks may degrade performance a little more than purely native code). If IT doesn't mind, assemblies can be pre-JIT'd into the GAC using ngen.exe, but that would require some sort of installation. So, depending on how your application
-
In my personal experience and professional experience as Director of Technology and chief architect at our company, sysadmins dislike doing anything that keeps them from playing solitaire or hiding out in some room playing Xbox. It doesn't matter if they have to install a native app or the .NET Framework + a managed app. The way to market this is the ability of a correctly written .NET application to not require installation. Yes, the .NET Framework and any service packs (.NET 1.0 will have SP3 and .NET 1.1 will have SP1 shortly) are a little bloated, but nothing typical IT solutions can't push out to machines (it is a Windows Installer package when you pass /c /t:path options to the installer executable). The managed application could sit on a share somewhere that all users can use, though IT will also have to push out a code group (if necessary) so that CAS (code access security) is granted the appropriate permissions to run certain code. That, too, is easy. One that app is out there, they never really have to worry about it again. If there's update to be installed, they can simply drop the new assemblies on top the old ones. Through publisher policy assemblies and/or .config assembly settings, even old assemblies can use new assembly versions that they weren't linked against. Assemblies can also be deployed like this over the Internet or an intranet. This is all known as touchless deployment. The IT folk don't have to worry about pushing out updates to an application; when written correctly, the .NET applications will update automatically through Fusion (the assembly bindiner portion of the CLR). .NET 2.0 will make this process even easier (and not require a 24/7 connection to check for updates) with ClickOnce technology. The only major downside is that managed apps can require quite a bit of memory. If you use a lot of types (our flagship app uses almost every assembly of the BCL plus a few other third-party assemblies), it will use quite a bit of memory. A well-written app isn't so bad, though. Another downside (sort of) is that it can be slow to start up since types must be JIT compiled. Once they are compiled to native code, however, the native code is cached and executes about as fast as native calls (stalk walks and the sheer depth of some execution stacks may degrade performance a little more than purely native code). If IT doesn't mind, assemblies can be pre-JIT'd into the GAC using ngen.exe, but that would require some sort of installation. So, depending on how your application